Agile Tip #4 – Plan Using Velocity

Tip #4:   Use velocity when planning iterations.

Before you plan an iteration it’s critical that your team understands its velocity.  A team’s velocity is the number of story points that it can complete in a single iteration.  Put even more simply, your team’s velocity is how many story points it completed in the last iteration.  It’s not how many points the team planned to complete.  It’s how many were actually completed based on the acceptance criteria defined by the product owner.  This is commonly known as yesterday’s weather.  It will take a few iterations before the team will truly understand its velocity, but over time, the team will settle into a common understanding of how many story points it can commit to in a single iteration.

In MSF Agile 5.0 you can use the Product Planning workbook to track your team’s velocity.  In the screenshot shown below the team completed 13 story points in iteration 1, 14 story points in iteration 2, and 10 story points in iteration 3.   In this example, the team’s velocity is 10 story points… it’s not 12.3 (the average), and it’s not 14 (the max).  It’s 10 – the number of story points completed in iteration 3.  As the team enters the planning meeting for iteration 4 it should know and understand its velocity so it can have a healthy conversation with the product owner about how many points it can commit to in the next iteration.  There are good likely reasons why the team completed fewer points in iteration 3 than iteration 2.  Was someone on the team on vacation?  Did the team over commit and not complete a story?  Those reasons should be known by the team and should have been surfaced during the team’s retrospective.

As the planning meeting begins, the product owner and the team start to discuss and select stories to include in the next iteration.  If the top four stories on the product backlog have story points values of 3, the team will know that if they commit to ALL those stories they’ll be committing to more work (12 points) than they completed in the last iteration.   If the take only 3 of those stories, they’ll be committing to less work (9 point).  In either case, this might okay, but by using the team’s velocity the team and the product owner can have a healthy conversation about what the right stories are for the next iteration. 

Using velocity when planning iterations will help your product owner to do better release planning, it will help the team make stronger a commitment, and it will lead to healthier communication with everyone involved.   For more on this topic I’d recommend reading Mike Cohn’s book Agile Estimating and Planning.

Comments

• Anonymous
  October 11, 2010
  At first the term velocity seems complex but once it's broken down as you have done here it makes complete sense.  Thanks for the simple description.