Almost everybody has heard of Scrum and no sooner do we learn of its existence, we hear about 'velocity'. But what is it and what part does it play in Scrum? Let's take a look.
Definition of Velocity
Let's start with a definition of velocity within the context of Scrum. I've deliberately broken this down into small phrases as each phrase deserves an explanation:
Velocity is:
The Amount of work
A Scrum Team
Gets Done
Within a Sprint
Please note that this is a 'Derek Definition' and not an official Scrum definition.
Breaking it down
The first phrase: 'Amount of work' is deliberately neutral on the subject of how you measure. You can use hours, work items, features, story points, t-shirt sizes or any other form of consistent measurement that is useful to you. Don't worry if you've never heard of some of these measurement types before. All that matters is that you have a consistent way of measuring the work.
The second phrase, 'A Scrum Team' indicates that this definition applies specifically to Scrum. It could equally apply to an agile team though, as long as the composition of the team is consistent.
'Gets done' comes next. This means work that is completed in conformance with the definition of done.
Finally, we have the phrase 'Within a Sprint' to indicate the time boundary within which we measure.
Every Sprint Can Have a Different Velocity. Which Do You Use?
It is common for Velocity to fluctuate over Sprints. When that happens, there are a number of approaches you can use:
- Take the last number and use that. It's the most recent data point you have and therefore, the most accurate
- Take the average over all Sprints. It smoothes out the peaks and troughs and gives us an average we can work with
- Take the average of the last three Sprints
- Take the average of the best three Sprints
- Take the average of the three worst Sprints
Each of the above approaches are valid. Use your knowledge of context to decide which works best for you.
When is Velocity Useful?
Velocity can be useful in the following circ*mstances:
- As a guide when forecasting how much work can be be done within a Sprint
- Creating burn-down and burn-up charts
- Creating forecasts for Release and Product delivery dates
When is Velocity Not Useful?
Velocity is not useful under the following circ*mstances:
- Comparing performance of different Scrum Teams
- Assessing the performance of the Scrum Team to which it relates
- When used as a target rather than a measure
The Benefits
The Scrum Guide does not mention Velocity. Instead, it refers to the need for forecasting, planning and sizing. So, where does Velocity fit in and what are the benefits?
- It's a common technique that is useful for forecasting, planning and sizing. Many Scrum Teams use it and it's a good technique to understand
- The creation of forecasts, charts and reports is easier. If only because the mathematics is simpler.
- Forecasts are usually more accurate
Examples of Use
Example 1 : Sprint Planning
A typical format for Sprint Planning might look like this: The Product Owner brings an ordered Product Backlog to Sprint Planning. They take the first item and ask the Developers "Can you do this"? The Developers assess the size of the item against the Velocity. As long as the sum of sizes for all item estimates is less than the Velocity, the Developers accept the work.
Example 2 : Forecasting a Delivery Date
The Product Owner sums the size of all Product Backlog Items that remain in the Product Backlog. They divide the sum by the Velocity and round up the result to the nearest integer. This tells us how many Sprints are needed to get the Product done.
Taking a worked example: The size of the items in the Product Backlog sums up to 210 points. The average velocity of the team is 21 points. We divide 210 by 21 and get the result 10. It will take 10 Sprints to deliver the product. If we work in two-week Sprints, that's 20 weeks.
Summary
It was the search for a new way to estimate software projects that brought me to Scrum. When I discovered Velocity, it set about a revolution in the way I made forecasts and plans. It was fast, effective, and more accurate that the way I used to estimate.
Velocity is a useful measure. Because it is based on actual work 'done', it is beneficial for creating forecasts. It is common for Velocity to fluctuate between Sprints and equally common to work with an average when creating forecasts.
Velocity is an excellent measure and a terrible target. Once a measure becomes a target (ie: for performance measurement), it loses the ability to provide meaningful, trustworthy, transparent data. This is because the number gets gamed. Avoid this at all costs. Because the best Velocity is an honest one.
