Skip to main content

What good are story points and velocity in Scrum?

We use velocity as a measure of how many story points to take into the next sprint. When you take in enough stories, and story points, so that you reach your average velocity, then, you can end the sprint planning meeting.
Although this is a common approach, it is exactly how you should not use story points in Scrum. It leads to over-commitment and spillover (started, but unfinished work) at the end of the sprint. Both of these are bad for performance. How should you use story points in planning? How do you create the Forecast? And what do you do if the team runs out of work?

The first thing to remember is that Development Team is self-organizing. They have exclusive jurisdiction over how much work they take on. The Product Owner has final say over the ordering of items in the backlog, but nobody tells the the Development Team how much work to take on! Not the Product Owner, not the ScrumMaster, and certainly not the math!

As a Product Owner, I would use story points to help set medium and long-term expectations on what is really achievable. Wish and probable reality need to be more or less in sync with each other. If the disparity is too big, it's the Product Owner's job to fix the problem, and she has lots of options: less scope, simpler acceptance criteria, more time, more people, pivot, persevere, or even abandon.

As a ScrumMaster, I would use velocity to identify a number of dysfunctions. A wavy burndown chart is often a symptom of stories that are too big, excessive spillover, or poorly understood acceptance criteria (to name the most likely causes). A flattening burn-down chart is often a sign of technical debt. An accelerating burn-down chart may be sign of management pressure to perform (story point inflation). A lack of a burn-down or velocity chart may be a sign of flying blind!

As a member of the Development Team, I would use the estimate in story points to help decide whether stories are ready to take into the sprint. An individual story should represent on average 10% or less of the team's capacity.

How to create the Sprint Forecast

How much work should the team take on in a sprint? As Scrum Master, I would ask the team, can you do the first story? Can you do the first and the second? Can you do first, the second and the third? Keep asking until the team hesitates. As soon as they hesitate, stop. That is the forecast.

Why should you stop at this point? Taking on more stories will add congestion and slow down the team. Think of the highway at rush hour. Do more cars on the road mean the traffic moves faster? Would be nice.

Why do you even make a forecast? Some projects say, let's just get into a state of flow, and pull work as we are ready to take it. This can work too, but my own experience with that approach has been mixed. It is very easy to lose focus on getting things done and lose the ability to predict what can be done over a longer period of time. So I believe Sprint Forecasts are useful because they help us inspect-and-adapt enroute to our longer term goal.

What about "yesterday's weather"? Can we use the results of the last sprint to reality check the forecast for this sprint? Sure! If your team promised 100 but only delivered 70 or less, this is a sign that they should not commit to more than 70, and quite probably less. I call this "throttling", and it is one of my 12 Tips for Product Owners who want better performance from their Scrum Teams. But yesterday's weather is not a target, it's a sanity check. If it becomes your target, it may be holding you down.

What if the team runs out of work?

On the one hand, this is easy. If the team runs out of work, they can just ask the Product Owner for more. A working agreement can streamline this process, for example, Team, if you run out of work, you can:

  • Take the top item from the product backlog.
  • Contact me (the Product Owner) if you get down to just one ready item in the backlog
  • Implement your top priority improvement to our code ("refactoring")

Implementing improvements from the last retrospective is usually a particularly good idea, unless you are very close to a release. There are investments in productivity that will often pay huge dividends, surprisingly quickly!


Anonymous said…
Thank you Peter for your newest post!

First, I do agree with "(...) nobody tells the the Development Team how much work to take on! Not the Product Owner, not the Scrum Master, and certainly not the math!"

But I think, the [a: max. of hours a team can be productive during the next sprint] vs. [b: the average velocity over the last 3 sprints] can give a PO a good feeling on [c: what seems to be possible].

But this [c] IS NOT the [d: what must be possible] for the next sprint. Estimation is still done by the dev. team and nobody else! And the commitment from the dev. team is still asked "(...) keep asking until the team hesitates" and even more, requested.

This [c] may have a influence to the priorities given by PO for some critical user stories and may (or has) a influence to a release plan - at least when it comes to a first "go live"/"go productive"/"go public" with a product.

The key thing here is for sure to have a realistic [a], a good feeling what does mean the [b] (it goes down, it stays or it goes up = why and what does that mean?) and to have experiences with "go public" or even better with "continuous deployment" while developing a product.

What you think, Peter?
Peter said…
Dear Anonymous -- and I hope your not that Anonymous ;-)

These topics -- how much value is there in an estimate, or what does the team really commit to in sprint planning -- have been the subject of much debate over the years.

A few years ago, Ken Schwaber created a storm by changing the result of Sprint Planning 1 from a commitment to a forecast. And the discussion around #noestimates have been especially entertaining!

The idea behind "forecast instead of commitment" is the team commits to do its best. The team may not deliver all it forecast, but what it delivers will work (it's "done"), be on time (i.e. by the end of the sprint), and be on budget (no overtime or delays).

So Scrum has a default agreement on how the team should fail if it can't meet the commitment. I have found it helpful to discuss with agreement with the Stakeholders. Since the alternatives are usually bad for quality, cost, and release predictability, most PO's and stakeholders go along with the standard agreement (although there have been some special cases, usually in the last sprint before an important deadline). Those that value scope over quality usually end up unhappy.

I have seen teams waste a lot of time doing detailed task estimates in sprint planning 2. It's hard work and the value add is small. So keep planning and estimating as lightweight as possible.

My own experience has been the best when teams focus on getting things really done in one story before moving on to the next one. That means zero tolerance for bugs! This gives higher velocity and better release predictability the getting things sort of done, and fixing the details later. It does require a closer collaboration with the Product Owner and/or other stakeholders, but I find it gives better results.

To address you last question, I think this is good conversation to have with the product owner. It builds trust and alignment on both values and priorities.

Anonymous said…
For any forecasting method, SP or "hog's heads" (a unit we used in physics undergrad course to make the TA's do some of the work), must have the variance.
Average is meaningless without the variance. It's not the Average that should be used anyway. It's the Most Likely (the mode, the most recurring value).
All the examples of #NE using past performance (empirical) data use Average. This is bad math at least and unreliable math at worst.
Next is the time series evolution of the past performance. This is easily determined with ARIMA and an R desktop environment.
The result of the "simple" approach is disappointing forecast and the misunderstanding that estimates don't produce good results and blaming these on estimating in principle, rather than the improper use of estimates.
I dislike platitudes but - "It's a poor workman who blames his tools."
Learn to use the tools, and only then determine if they are applicable to the problem at hand - the "value at risk."

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…