Scrum for Team System version 2.2 was recently released. The most significant new project management report is the Velocity Report.
The velocity report tracks the historical "burn rate" for a team in such a manner to allow for truly accurate release planning.
Throughout this post I'll use the term "Story Points" as the Unit of velocity, however everything is equally applicable if your team uses Ideal Days instead.
What does it show?
The Velocity Report gives four essential pieces of information across specific time periods. These time periods may be either the entire project as a whole (to date), or one of the releases of the project to date. If you select the project as a whole (to date) - the report will also indicate which Sprints came from which release.
If you have multiple teams defined for your project you may also view the report for all teams or for any combination of your teams (including individual teams)
For any given time period selected you can view:
- Actual Story Points burned for each of the Sprints
- Average Velocity across this time period
- Average of the three sprints across this time period with the lowest velocity
- Average of the three sprints across this time period with the highest velocity
How do I use it?
The most common use for Velocity in Agile Project is in Release Planning. Release planning is simply the act of determining what functionality you're going to be able to deliver in what time frame across your project. Obviously you want this data to be as accurate as possible. The greatest accuracy is gained by basing this Velocity figure on observable historical data.
However, human beings are imperfect, if you simply take a single figure for your Velocity your release planning is likely to be in-accurate. Using the three averages from the Velocity Report will produce far more accurate results.
Think first of your backlog in the order in which it will be built (which should be pretty normal for most Scrum teams) - then cumulatively add up the estimates against each of your PBI's.
Then take each of the average scores and multiply them across the number of Sprints you have remaining in your project or release. This will give you your best, average and worst case scores for the amount of PBI's you can burn down across the scope of your project or release.
Think of these three scores as dividing up the PBI's in your Product Backlog into 4 zones.
Zone A) - This is the zone above your lowest average velocity.
Zone B) - This is the zone between your lowest average velocity and your overall average velocity
Zone C) - This is the area between your overall average velocity and your highest average velocity
Zone D) - This is the area below your highest average velocity
Then you can evaluate your release plan using the following system.
PBI's in Zone (A) you're almost guaranteed to get.
PBI's in Zone (B) you're very likely to get.
PBI's in Zone (C) you'll conceivably get, but it's not likely.
PBI's in Zone (D) you're guaranteed not to get.
Match those predictions with what you know about what you need for this release or the project as a whole. Ensure that the PBI's in Zone (C) are only in the "nice to have category" and that you're not expecting to get anything in Zone (D) - this really is the Zone of things we're not going to get. Re-prioritise your PBI's until the essential components of your release is solely in Zone (A) and Zone (B).