1

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 user stories 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 user stories. I believe that's not a good idea.

7
  • How Big is a Story Point? "Each User Story can be measured in relative effort to other stories, not in absolute time estimates. Over time the team will become adept at estimating stories for the product and will be able to make a reasonably good prediction of what can be committed to a sprint and be completed." Aug 28, 2019 at 15:11
  • Why You Should Not Estimate in Hours or Days: "So what does Scrum mean for management? According to Scrum, coming up with an accurate estimate for the amount of time which it will take to complete a complex software project is doomed to failure. The best that you can do is to improve your estimate of Team Velocity from Sprint to Sprint ..." Aug 28, 2019 at 15:15
  • "... What this means is that management cannot accurately estimate the business value of a project until a project begins. Each Sprint, everyone will have a clearer idea of how much work can be done in future Sprints. Each Sprint, management will have a clearer idea of the amount of business value which can be delivered from the project." Aug 28, 2019 at 15:16
  • I am not sure if you are aware of it, but we have a sister site dedicated to project management questions: Project Management. Aug 29, 2019 at 7:55
  • 3
    Possible duplicate of How to respond when you are asked for an estimate?
    – Doc Brown
    Aug 29, 2019 at 15:38

3 Answers 3

2

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.

2
  • I agree, but that's the ''fight'' between Agile Software Development and project management. They want to know when the project will be finished, and I want to focus on the team and delivering incrementally and iteratively. Aug 29, 2019 at 6:48
  • @DarkKnightSM You can't plan and predict original and creative work, like engineering design. The best you can do is timebox it. If there's a need-by date, you are going to need to possibly reduce scope or quality in order to meet it. Otherwise, you can continuously deliver scope and a specified quality and the work is done when it's done.
    – Thomas Owens
    Aug 29, 2019 at 9:22
0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.