Migrating a Scrum Team to Story Point-based Estimation
Hello,
I currently have 2 teams who have are working with Scrum, and one team is using Development Days for estimation. The challenge here is that the team breaks every story down to multiple sub-tasks which can be executed by various engineers. This is also because this team has quite heavily back-end oriented services i.e. the outcome is quite technical with mostly technical outputs.
We know our capacity in dev days, but it's quite challenging to track velocity without using Story points. At the same time, our example cannot fit Story Point because it's too complex to use simply stories for the engineers, because it doesn't provide sufficient clarity for a story (e.g. what "Exactly" we need to do to achieve the intended outcome).
Under the circumstances, how do we transition to Story-point based estimation? We know it's hard, but it's probably for the best.
Any ideas/suggestions?
Regards,
We know our capacity in dev days, but it's quite challenging to track velocity without using Story points.
Why?
In addition to Ian Mitchell's question about why you're finding it challenging to track velocity without Story Points, I'd ask a more fundamental question: Why do you want to migrate to Story Points? What problems are talking about Development Days or Development Hours (either real or ideal) causing the team?
Is velocity required by management? If not, why estimate it? You can ask the developers "how many PBIs can you fit into this Sprint to deliver an increment?"
what do you expect to gain with Story points ?
The only reason for you to use story points and velocity is to help your team pull the right amount of PBIs to the sprint backlog each sprint. It should never be used externally, especially to measure productivity or compare with other teams.
@Harley Dangan, even using Story Points does not guarantee that a team will pull in the right amount of PBIs for each Sprint. Story Points are estimates and estimates are guesses based upon the information you available. Over time you will start to become more knowledgeable about the space you work so your estimates will start to change and become better. But that still does not guarantee success at forming your Sprint Backlog.
@Mohammed Manna, you stated
We know our capacity in dev days, but it's quite challenging to track velocity without using Story points. At the same time, our example cannot fit Story Point because it's too complex to use simply stories for the engineers, because it doesn't provide sufficient clarity for a story (e.g. what "Exactly" we need to do to achieve the intended outcome).
Have you looked at tracking your velocity in terms of throughput? Use a trailing indicator of how much work is actually accomplished instead of a leading indicator of how much you guess can be done? That might be easier to equate to your dev days capacity.
As to the work being "too complex to use simply stories", why do you say that? I have worked with a number of teams that "breaks every story down to multiple sub-tasks which can be executed by various engineers" and whose products are "heavily back-end oriented services" that are "quite technical with mostly technical outputs." They utilized User Stories. The trick is how you define the User. For an API, the User might be another program that is calling your API. A User could be another application or a medical device. There is nothing that says a User Story has to be created from the aspect of a humanoid that breaths, has fingers and interacts with an graphical interface. Do a search with your favorite search engine for "technical user stories". You will find many articles with suggestions on how to do them and others that will try to say why they are bad to use. I have had success using technical story formats with some of my teams. But I have also had success with teams where we abandoned the user story format and used a technique similar to Feature-Driven Development. Mike Cohen has a fairly short but good description on it. (https://www.mountaingoatsoftware.com/blog/not-everything-needs-to-be-a-…).