1

I'm a software QA that has limited knowledge of the agile methodology due to my sparse time with Agile teams in the past. Currently I'm exploring using Story points for my team instead of estimated hours.

One question I can't wrap my head around is, how do we estimate the no. of story points to commit for the next sprint? I've read that one way we can do that is by getting the average velocity. Is that right? And if it is, what is the frequency of calculating the average velocity?

Example:

Sprint duration: 2 weeks

Past sprints:
Sprint 1 = 40 completed story points
Sprint 2 = 50 completed story points
Sprint 3 = 70 completed story points

Let's assume Sprint 4 has a rough estimate of 53 story points to commit based on the average ((40+50+70)/3).

How do we then do the estimation for Sprint 5 and onwards? Surely if we keep on doing a calculation of averaging wouldn't the value converge?

Improve this question
2

3 Answers 3

Reset to default
4

One commonly advised way to estimate how many story points to pick up in a sprint is like this:

  • For the first sprint, keep adding stories to the sprint until states that they have enough work that they think they can just about finish in the timespan of the sprint.
  • For the following sprints, use the average velocity of the previous (3 to 5, if you have that many) sprints, to have an idea of how much the team can realistically achieve based on their past performance. This average is not a hard number to plan against, but mostly a guideline of what is realistic.

It is expected that the average velocity will start to stabilize after some sprints. This is a good thing, because it will make the team more predictable in how much they can achieve in a sprint and on a larger timeframe.

If there is a significant change to the team (new members added, members leaving) or the environment in which the team works, then it can be misleading to keep referring to velocity measures from before the change and you should seriously consider treating them as a new team on a new (but somewhat similar) project.

Improve this answer
1
  • 1
    The only thing that I'd add is if you make a significant change to the team or the environment they are working in (tools, technology, organizational changes that impact the team, etc.), you probably want to fall back to the first bullet.
    – Thomas Owens ♦
    Sep 20, 2017 at 12:01
1

Go for the lowest possible estimate. If you can pick 40 points, 50 points or 70 points, the 40 should be your choice. You look good if you bring points into the sprint, bad if you have to take them out. And if you're only 3 sprints in @ 2 weeks per, you're more likely to be underestimating than overestimating. Team morale always takes a hit too if you're consistently bogging the team members down with an unrealistic set of story points, and the sprint plan becomes meaningless.

Underpromise and overdeliver should be your slogan.

Improve this answer
0

I agree that velocity should stabilise so as you see that happening you can stop including the first couple of sprints and just use an average of the stabilised values.

Also, I always find that in the first couple of timeboxes suffer badly when things like branching, deploy and environments are handled by external teams.

Improve this answer

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.