Potential Benefits of Velocity and Story Points
Note: Velocity and Story Points are NOT part of the Scrum framework but an optional, complementary practice.
Introduction
I’ve noticed a trend where Velocity and Story Points are criticized. While it certainly does have downsides, often, it’s misinterpreted and misused. Does that make it a bad idea?
Many other sources describe what Velocity and Story Points are (not). In this article, I want to give a different perspective and describe potential, often underestimated benefits. What value can it add?
If and how you should forecast is highly dependent on your context. After this article, you will be in a better position to decide if Velocity and Story Points might work for you.
What is the need for predictability in the first place?
After I fell in love with Scrum in 2010, I set up my own company and tried to sell Agile contracts, seeing many benefits for the customer and myself. The first year, I didn’t sell a single contract. At one point, I was so frustrated I just bluntly asked the question:
Dear client, would you rather:
- Accept uncertainty not knowing what you’ll get in the end, allowing us to build the most valuable thing at that time, or
- Know upfront when you get what, even though it’s an illusion?
It was kind of a rhetorical question, but I was flabbergasted this client chose the second option!
Stakeholders will often ask two fundamental questions: “When will it be done?” and “How much will it cost?”. Almost every company needs some forecasting strategy. Business is mainly about forecasting what people will need in the future and how we will give it to them. Stakeholders like to know when to expect the value to plan the next steps. Organizations need this information for decision-making, like determining how long projects will take, what skills are required, how much they cost, etc.
Besides that, people find uncertainty uncomfortable; it can even cause stress.¹ People feel safer when there’s a plan, having an end in mind. In Scrum, we set goals (which enable empiricism and create focus, energy, and direction), but at the same time, we accept reality and embrace the unknowns. We inspect and adapt along the way, increasing our chances of doing something valuable.
Ok, we’ve established that there’s a need for predictability. The next question is: how predictable do you need to be? I would start by asking the Product Owner and stakeholders. In my experience, when a company begins practicing Scrum, the need for predictability is relatively high. When the teams start delivering, this will increase trust and decrease the need for predictability.
Either way, some form of forecasting and estimation always takes place. It can be as simple as considering whether an item fits into a Sprint. The goal is to find the sweet spot, which is a tradeoff between value and effort, as shown in this graph:
After a point, spending more time does not lead to better estimates, but will only delay the delivery of your product. We can often spend a little time thinking about an estimate and come up with a number nearly as good as if we had spent a lot of time thinking about it. Teams tend to fall into the trap of spending more time than necessary on coming up with estimates. Spending a lot of time creates an illusion of accuracy and drives behaviour in which we get attached to our estimates.
Planning with Velocity’s Super Powers
We first looked at the need for predictability; now we look at the benefits of fulfilling that need using Velocity (which includes estimating Product Backlog Items (PBIs) using Story Points and Planning Poker).
The plan enables empiricism.
We’ve established that the activity of planning is more important than the plan itself, but that doesn’t mean the plan is useless ².
Empiricism reduces uncertainty by doing something, not by planning more. For empiricism to work, you need to have goals and targets. The plan describes the intent of doing something. It creates focus and direction. Having a plan enables inspection of progress, enabling adaptation (be open to anything that seems better). For instance, an estimate during Sprint Planning gives the team something to inspect against.
As Deming pointed out, improvement and experimentation require prediction and measurement.
When you have a carte blanche, the day’s issues might sway you, which makes it harder to realize longer-term goals.
Increased shared understanding and self-management
The critical point of Planning Poker is to trigger conversations around assumptions, technical options, scope, etc.
The value is in the discussions where estimators are called upon by their peers to justify their estimates. Estimating a PBI, you must think more deeply about it. These discussions lead to better compensation for missing information. It brings together multiple expert opinions. The team learns more about the work and flushes out assumptions (and coordinates dependencies). This thought process decreases the chances of getting significant setbacks.
If the team does not understand the work, development effort and time tend to balloon, increasing the chances of the team missing the Sprint Goal and not delivering what stakeholders expect.
Increased predictability and credibility
The purpose of planning is to communicate and manage expectations. Estimates are not about being precise but about being predictable. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
With an estimated Product Backlog, the team can provide insights into delivery and give (rough) indications. Estimate size, and derive duration.
The increased predictability has another benefit: With a known Velocity, it is less likely to have work in progress at the end of the Sprint, which improves transparency. It’s a nice moment to inspect the Increment when there are no moving parts.
Enables or facilitates prioritization
The estimated size of a PBI helps make value/risk tradeoffs. The potential value always needs to be put against the required effort.
The size makes the PBIs more tangible and decreases scope creep. It prevents unnecessary stuff from getting into the product because people add invisible requirements. The estimates trigger discussion and negotiation between the team and the customer.
Enables sizing
Knowing the size of a PBI is a big trigger to creating smaller PBIs. Smaller items improve focus and flow. To what degree can Developers break a solution down so that value is delivered sooner?
My teams had an upper limit of 8 (or 13) Story Points. Whenever a PBI was bigger, they sliced it into multiple smaller PBIs.
Enables sustainable pace
Velocity is about rhythm and pace. It’s a way for the team to achieve a sustainable pace and protect them from over (and under-) committing.
Too many teams overlook history, availability, and buffers, so they over-commit. Then they wonder why there is spillover and lack of delivery, which decreases trust. If a team overburdens itself, it will be stressed with context switching, wasteful communication, and (likely) suffer demotivation. An overburdened team will not have time to think and likely work harder, not smarter.
People usually overestimate what they can do. It’s human nature to be overly ambitious. We want to please others and make a good impression, so we tend to be much more optimistic, insinuating that we can do things faster because we’re better. So past Velocity helps in being more realistic and avoiding overworking. Using knowledge based on experience and planning collectively overcome Planning Fallacy, with an optimistic bias towards our tasks and a pessimistic bias towards others’ tasks.
Ideal time vs elapsed time
When a team provides estimates, most likely they’re in ideal time. It is much easier to predict the duration of a task in ideal time than in elapsed time since it is impossible to foresee future interruptions. Velocity indicates how much work the team can complete, taking interruptions into account.
Story Points’ Super Powers
Story Points are usually scored with the beautiful Fibonacci sequence, which works well because the values increase by about the same proportion each time, well representing the increasing uncertainty.
Story Points represent a combination of effort, uncertainty, complexity, risk, coordination, delays, etc. They’re nebulous. Even though they are numbers, think of them as ranges or bands.
Story Points have two powerful traits:
1. Relative
- Our brains are a lot better at relative- than absolute estimation ³. We always put that new thing that we need to estimate in relation to things we already know, which is more comfortable. Estimating in absolute terms is really difficult since it requires us to estimate something that we have no knowledge of.
- Uses triangulation (comparing with two other values). There’s no direct coupling between size and duration. There’s one indirectly, but still weak. Every estimate has a statistical distribution and comes with its variances. When you add multiple together, the variances will compensate each other; when you keep estimating the wrong size, that’s fine because it’s consistent. Estimates tend to converge over time, and the pessimism for one estimate usually offsets the optimism of another. The average can’t be overly optimistic or pessimistic with relative estimates because they’re unitless.
Relative estimation helps teams incorporate complexity and unknowns, is based on experience with known work (empirical), and minimizes the amount of time spent on estimation (i.e., potential waste).
Relative estimation is more important than using Story Points, gummy bears, or whatever!
2. Additive
With additive numbers, it’s possible to (roughly) forecast what will be delivered and when. For instance, with T-shirt sizes, this is a lot harder. How much are a Medium and a Large combined?
The Kryptonites
To reap the aforementioned benefits of planning with Velocity, there are some challenging prerequisites that need to be met.
Working Value-driven instead of Plan-driven
Often, the problem is not estimation but the perception that estimates equal promises. We’re afraid to say “I don’t know “because we don’t like showing up empty-handed in front of our stakeholders. The problem is that estimation is perceived as a unique, one-time thing. PBIs get an initial estimate when they’re still vague, but I hardly see teams re-estimate, which are missed opportunities to put learning back into the system.
Every plan has some risk that people keep clinging to it for too long. Plan-driven delivery starts with identifying requirements and then executing them. When things do not go according to the plan, some try to adjust reality, for example, by working overtime instead of changing the plan itself.
In a complex domain, the plan is wrong but still useful. This is an essential mental model to get value out of forecasting, as it also helps in limiting your effort.
Velocity is a result, not a desire
The primary concern about using Velocity is that it distracts from focusing on delivering value. It’s prevalent for teams to focus more on delivering the thing right, rather than delivering the right thing.
Whenever a team’s Velocity increases, it should be a consequence of improving the system. It’s not something you want to optimize for (directly). There’s no good or bad Velocity; it just is. Most Scrum practitioners focus on increasing Velocity without considering goals or outcomes. Outcomes over output. Value over volume.
Velocity is only used by and for the team
“The people most competent in solving the task should estimate it” ⁴.
Measuring Velocity is exclusively for the team itself. Velocity serves as one datapoint that the team uses to manage themselves. Things get ugly when others, like management, decide to steer on elocity or compare different teams’ Velocities. Transparency decreases, and fear will set in. Teams do different types of work with other variabilities. The developers can quickly ‘bloat’ their estimates. To avoid being blamed or punished, the team spends too much time upfront gathering all the details, or they will game the system (for instance, be wary of a continuous upward trend).
For the people who want to measure the teams: Stop it, and measure at least one level up (i.e. impact at the product level).
Individual vs Group estimates
Research indicates that group estimation is more accurate than individual estimation. It requires that groups have diversity and independence and that authority is decentralized within the group.
The estimations are a property of the team as a whole, never of an individual member (he’s the specialist on that subject, he will decide how much effort it will take him). Team members estimate each item without knowing who will work on it.
Don’t measure/link it to absolute time
Some people try to estimate by converting to absolute time first. Some believe there’s a constant that you can use to convert Story Points to hours, which there isn’t! It assumes linearity, precision and consistency, which are not there; the numbers in the Fibonacci Sequence exhibit exponential growth.
Relative estimation is the process of estimating our work in relation to what we already know. In contrast, estimating in absolute terms is difficult, if not impossible, to do since it requires us to estimate something we don’t know.
Conclusion
Velocity and Story Points are not perfect and have limited value, but many people underestimate the benefits. As with any other metric, it’s more important who uses them and how.
I’m not saying you should use Velocity and Story Points; I just disagree with people who say you should never. Estimation can be considered a tool. Refusing to use a tool doesn’t make sense. Some of my teams found it valuable. Just make sure that the team is able to work on the right problem!
Hopefully, these explanations help in deciding if it might work for you. Some of the benefits don’t just come from using Velocity, but I’d definitely keep them in mind. Whatever planning process you use, I’d recommend taking an empirical approach.
Also thanks to Maarten Dalmijn and Kunal Shah for reviewing.
