Projecting Velocity

In Scrum, Velocity is the term applied to how much work (or weighted points of work) is completed during a given Sprint. The Velocity metric can be used to evaluate a variety of items including whether the team is selected an appropriate amount of work for a Sprint, how much work to select for a future Sprint, and as a way of comparing increases in productivity in a team over time.

However, the Velocity number itself has no special meaning outside the team. That is, if my team has a Velocity of 12 and yours has a Velocity of 20, that doesn't mean you are roughly 50% more productive than me. The weights we assign to the same item might differ so the total number of points itself is not important as a measure of comparison.

But it can be exceedingly useful for a team that is using Scrum and trying to decide how much work to select for a Sprint. Say a team initially selects 20 points of work for the upcoming Sprint. They begin work and things go well initially. Later on, problems occur for a variety of reasons and items in the Sprint don't get completed properly. At the end of the Sprint, the Team reviews the Sprint and sees that only 15 points of work was actually completed. We would say that their Velocity is roughly 15 points at this time.

During the planning meeting for the next Sprint, the Team could use this information to guage how much work to select. They could decide that the problems that occurred were one-of-a-kind and elect to do 20 points of work again. The smarter team would realize that things happen during a Sprint and they may very well happen again - people get sick, technology doesn't work out as expected, things take longer than expected and so on. So they may decide to take 15 or 16 points of work for the next Sprint.

Of course, the work performed in each Sprint differs and the same Team might be able to do 15 points of work one time, 18 points another time, and 16 points after that. As time proceeds, a weighted average of the last 3-5 Sprints can be created to drive the decision as to how much work to select.

Velocity also has the nice benefit of allowing the Product Owner to devise a rough Release Plan for the project. That is, if there are 200 points worth of work in the backlog, and the team can do 20 points of work each Sprint, then it's roughly 10 Sprint's before they will be ready. This information can be used to generate a rough estimate of an end date assuming everything on the backlog will be completed. This is very different than a Team that attempts to work out all of the details up front in a Waterfall model project and drive the end date from the sum of all of the little estimates for tasks. They would inevitably leave out items or overestimate their ability to accomplish particular tasks. The end date then slips as the project proceeds and they end up as most projects do - late, less than desired quality and with an exhausted Team.

Understanding what Velocity is and how it can help a Team and the Product Owner understand how fast work is getting done and when a product may be ready for release is a key part of Scrum. It's not a magic bullet however. A Team that performs work that wasn't on the backlog, moves partially completed work from one Sprint to another without accounting for the weight of that work, and so on will end up with a misleading Velocity.

Next time, I'll finish up with some thoughts around Sprint Retrospectives and why they are an important part of Scrum.

Posted by Mark M. Baker at 06:35 PM  Permalink