Product Backlog items estimation - How to avoid estimations in hours when there is no team velocity and team is new?

by DarkKnightSM   Last Updated August 28, 2019 15:05 PM - source

This is the case:

  • A new team which consists of 6 people. They are a new team so there is no velocity that can be used for further sprint planning.

A problem: - The project manager wants to know when the project will be finished. We have the US stacked in the product backlog and now we need to estimate them.

I want to estimate them in story points and to track the team's performance throughout the sprints and then we can have a clear picture when the team will finish to project.

The project manager wants to estimate in days/hours these US. I believe that's not a good idea.



Answers 3


The project manager wants to know when the project will be finished. We have the user stories stacked in the product backlog and now we need to estimate them.

The project is going to be finished when one of two things happens. One, all of the work is finished and there's nothing else left in the Product Backlog. Two, based on demonstration and/or delivery of working software, doing more work will not add sufficient value to warrant the cost of executing another Sprint.

Using Story Points and Velocity is not for management to plan on when a project is going to be done. They aren't for anyone outside of the team. These concepts exist to help a team plan their next Sprint, to provide a reasonable sanity check that they are forecasting the completion of an appropriate amount of work and committing to an appropriate Sprint Goal. They aren't good or useful for long term forecasting - maybe you can get out as far as an extra Sprint or two. This is because they are highly unstable - as the team gets better, the baseline for a Story Point will change and evolve. It's why you can't even look back on more than a few Sprints to compute Velocity.

My advice is to not try to mix Agile Software Development and traditional project management methodologies. Embrace empiricism, adaptability, flexibility, and the responsiveness to a changing environment. Focus on value delivery and knowing when the costs will exceed the potential remaining value.

Thomas Owens
Thomas Owens
August 28, 2019 16:08 PM

Even at the point where you are now at (product backlog is filled, team is assembled, but no sprint has been conducted so far), you can give some indication of how long the project will take to complete, under the assumption that there will be no changes to the backlog.

  1. You start with estimating the entire backlog, either in storypoints or in "ideal manhours".
  2. After that, you ask the team to plan a couple of sprints, based on their gut-feeling of how much work from the top of the backlog they can complete in each of those sprints. This is meant as an exercise in getting an idea what velocity the team thinks is achievable and after adding up the estimates of the stories, the plans can be discarded.
  3. Based on the lowest, highest and average 'estimated velocity', you can calculate an interval for how many sprints it would take to finish the complete backlog.
    For example, if you have 1000 points on the backlog and can burn between 50 and 100 points each sprint, with an average of 80 points, then the estimated duration would be between 10 and 20 sprints with 13 sprint being the most likely.
    You present this interval to the project manager as

    Based on our current understanding of the project, our estimations of the work and the assumption that there will be no changes to the backlog, we think the project will take between X and Y sprints, with the most likely outcome at Z sprints. After we have complete a couple of sprints, the results may change.

By presenting an interval for the estimated project duration, you are giving a clear signal how much uncertainty there is in when the project will finish. Stating your assumptions (especially the assumption that the backlog won't change, which everybody with some sense should know will be invalidated) also helps there.

Bart van Ingen Schenau
Bart van Ingen Schenau
August 29, 2019 07:54 AM

Our world is full of uncertainty.

Developing a software or managing a project -- name it as you want -- is in the end only a collective endeavour to transform uncertainty into a certainty:

  • Starting uncertainty: can be about told and yet untold expectations/desires, about team dynamics and abilities, about customer interactions, about technical challenges, about time needed, and so on.
  • Ending certainty: is a happy user in front of a (hopefully) great product). Although this end can be the start of the next episode.

We all have to cope with this uncertainty. Different people do it in a different way. There's no bad or good: it all depends on one own's experience and practice.

Stick to your own way

If you're more comfortable with story points, stick to your approach. Don't try to adopt a different way of thinking if your current mental model works well. Working with ideal days or even real days would require a very different mind-set.

With a team estimating the story points and a history of velocity, you'll usually get a reliable base to predict future outcomes. To transform story points in duration. Nevertheless, it's only a probable estimate based on averages and collective experience. It's not a cristal bowl either.

Your specific challenge

In your specific case, you have a new team and no velocity history.

But you have your personal experience:

  • If you have seen hundreds of stories estimated in your previous team, you can correlate the story points of your new team with the average story points you were used to in the past.
  • You have no velocity, so you have no other choice than comparing the velocity you could expect from the new team to the average velocity you've experience in the past. This is the tricky point because you don't know how the team dynamics will work out and the size and skills could be different. But have a try and do not be too optimistic.

Fortunately, you're not alone either. Every team member has his/her own experience both in story point estimate and velocity and comparing previous team with today's team. So you can make this a collective exercise: after having "calibrated" the team with story-pointing the stories, try to collectively assess the velocity that you can hope for. Maybe not a single number but a range in order to keep in mind that it's only an estimate.

Based on this you can make a first guess: take the total number of story points, divide by velocity. Use the number of sprints (or better the range) and add a couple of iterations to cope with missing stories that you'll inevitably discover. And here you have a first time horizon to discuss with your project manager. It's a team duration. You can convert it in workload, by multiplying by 6 and number of work hours per work day.

Never disclose predictions without the assumptions

In every interaction related to the predicted time horizon, always recall your assumptions (i.e. no significant increase in stories) and remind the potential unreliability of the exercise. You should also insist that you do not firmly commit to these numbers but that you propose to reevaluate your prediction once you have some more reliable velocity figures.

Christophe
Christophe
September 21, 2019 12:32 PM

Related Questions


are technical user stories allowed in scrum

Updated August 06, 2015 14:02 PM


Bad apple in the team?

Updated February 27, 2018 21:05 PM