Predicting the team's Velocity: yesterday's weather method

September 25, 2008 by Przemysław Bielicki

Picture courtesy of aloriel@flickr

"How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".

If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.

Velocity
In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint - see Measures of size article. This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

What will be the weather today?
If you had to answer such question the best one would be that the weather today will be the same (or very similar) as yesterday (I assume you are not weather professional and you can only guess). The same is with Velocity and the amount of work you can predict doing in the upcoming Sprint. How much can you deliver? The same amount (or very similar) as in the previous Sprint - simple. You should take into account only the yesterday's weather i.e. only the last Sprint. Note that the yesterday's weather is one but not the only method to predict team's Velocity.

Let's consider the following example. Development team is composed of Mike, Martha, Paul, Josh and Julia. They worked on the project we are estimating following numbers of days (Sprint length is four weeks):

They delivered software worth 25 story points (sp) i.e. the team's current Velocity is 25. They claim that story for 3 sp is 80% done but this story is not DONE from the user's perspective. This story is not and cannot be taken into the final sum of delivered software - therefore we still have 25 sp instead of 28 sp.

To summarize - the team delivered software worth 25 story points in 70 work days.

How many story points we can deliver next Sprint?
If everybody in the team is available exactly the same amount of time in the project in the upcoming Sprint you can assume that the Velocity will be about 25. Depending on the team's experience in Scrum and their estimation skills it can vary i.e. if the Velocity of the beginner team will be 20 or 30 in the next Sprint it's still OK. The Velocity usually stabilizes after few Sprints (but it can still fluctuate slightly - you will probably never have the same results in two subsequent Sprints) but even if we consider experienced Scrum team we can expect that the Velocity in the next Sprint can be slightly lower or higher than 25.

If the team members will not be available in the next Sprint the same amount of time because of many reasons, or the Sprint itself will be shorter (e.g. because of some national holidays) you should verify planned Velocity.

The following example is based on techniques used in a real project that was developed be me and my teammates at Intel. Of course, names and numbers are not real.
The first thing to do is to sum team members' availability in the next Sprint. In four weeks we have 20 work days but there is one day of national holiday, therefore we have 19 work days. I also assume that team members can spend their 20% of time on developing some fresh stuff, learning, researching new technologies, etc. I will subtract 20% of time available for each time member separately. Let's take a look at the following table:

If the team delivered software worth 25 story points during 70 work days it means that they can commit to ~21 story points during 58 work days in the next Sprint (58/70 * 25 = ~21). So, predicted Velocity is about 21 story points.

Commitment
I assume that you have prioritized backlog of stories you have to deliver. I also assume that you know that you have to deliver them ordered by priority. This way you can start picking the stories until you collect about 21 story points in this example. It is really important to say about word - we are still in the estimation level, we don't know the accuracy of our estimates. That's why teams should commit to deliver about N story points.

What if the granularity does not allow you to hit exactly 21 story points? In this case you should take one smaller user story that is not at the top of your current backlog (still close to the top priorities ones) or exceed planned Velocity if and only if the team feels that can deliver selected stories. It is also pretty natural that the team can commit to 20 or 19 story points if they feel 21, 22 or 23 will be too much. Team is the most important here and they have the strongest deciding voice. At any rate the Velocity will be verified in four weeks i.e. at the end of next Sprint.

Wrap up
I hope this post helps you, I explained what Velocity is and how useful it is. I also hope you will be now able to answer the question "How much software will you deliver in the next Sprints?". Use the force which is Velocity in this particular example.

If you need more detailed information about agile estimation, planning, Velocity and all similar topics you should read Mike Cohn's book: Agile Estimating and Planning. It is brilliant and written with a very accessible language.

If you have some comments, want to ask some questions, something is not clear then comments section is all yours.

Resources
You may find following links valuable:

• http://agilesoftwaredevelopment.com/blog/jeremy/velocity-measuring-and-p...
• http://agilesoftwaredevelopment.com/blog/cspag/team-velocity-more-sum-it...
• http://agilesoftwaredevelopment.com/blog/jeremy/productivity
• http://agilesoftwaredevelopment.com/2006/12/measures-of-size

Permalink