Skip to main content

A concrete alternative to estimating story points in Scrum

Estimating is such a pain. I remember when I first read about Scrum and saw that the team was responsible for estimates, not the Scrum Master. I was sold!

But... estimates are controversial. Without estimates many stakeholders are unwilling to fund development efforts. The upside is that the process of discussing the stories in the team helps everyone understand what the feature is about. It's about the conversation, not the number. OTOH, estimates do not produce value for the user, so they are potential waste, and may be used to beat up the team if the estimates are not correct, which is even more counterproductive.

Story points are particularly controversial, because they are vague and fragile. Using real or hypothetical hours has other disadvantages. (What do I do when my customer only wants to pay the hypothetical hours, not reals ones?!)

I believe you can base estimates on something more concrete and measurable: Acceptance tests.

This satisfies the need to estimate larger projects, while eliminating the main drawbacks of story points and maintaining the benefits of estimation from the team perspective. Let me explain how I came to this conclusion.

"Shouldn't we create estimates now?" Yesterday, I lead a group of aspiring Product Owners through a 1-hour Scrum simulation to create the "analogue version" of the products they had conceived in the previous exercises. After the teams had created their forecast for the sprint, they wondered if they should estimate.

What is the value-add of the estimate? At this point, not much, because they have already made their forecast, which is itself an estimate, and they would be wasting time that they could use to actually produce the result.

I suggested instead that they make sure they are clear on how to verify that the goal of each story has been achieved. Write the goal on the front of the card, and the confirmation on the back. If the goal or the confirmation are too complicated to fit on a single card, make more cards, each with a goal and confirmation, until the cards add up to the original goal.

Does you recognize the XP (Extreme Programming) approach here? The three C's - Card, Conversation, Confirmation. The description and the confirmation have to fit on one card (I use 1/3rd of A4, but A5 or 4"x6" are probably okay too). A card corresponds to an acceptance test.

Does anyone see the similarity to Pawel Brodzinski's "#Noestimates scale"?
  • 1 - fits easily into a sprint. 
  • TFB. (T means "too", B means "big" and F is for you to figure out)
  • NFC (N mean "no", C means "clue" and F is forever the same)
Estimating in #NoEstimates is simply breaking the stories down to until they are standard size, then counting the cards. My understanding is XP cards are usually very small; many fit easily into a sprint. So XP cards count as a "1" on the #NoEstimates scale.

Counting the cards is the same as counting the acceptance criteria, which in turn is creating an estimate.

How can you use acceptance criteria to estimate a project?

Story points and planning poker were a big leap forward. The discussions between the development team, product owner and other domain experts facilitated a common understanding of the problem to be solved, and eliminated the need to do work-breakdown analysis. Using this approach us you can use simple math and charts to predict and monitor how much functionality will be done by when. Using the Fibonacci sequence or the Cohn scale addressed the problem of false precision.

The main drawback of this approach is that story points are vague and fragile. If you put them under pressure, they break. (Is this a 3 or a 5? The product owner wants higher velocity, so let's call it a five!) Because they are difficult to standardize, it is difficult to compare velocity of different teams. Teams often ask to re-estimate because something is more work than they thought it was.

What if the basis could be more objective? 

Acceptance Tests: A concrete basis for estimates

How might this work in practice? Given this story for a job portal: 
  • As a job hunter, I want to submit my CV with my application for (reasons that should be obvious)
How to know how big the story is? After discussion the team and product owner agree on the following workflow (I call this "how-to-demo"):
  • Given I have selected a position to apply to...
  • Step 1 Create an application
  • Step 2 Attach my CV by dragging it to the application
  • Step 3 Preview the application to submit and see that the CV is attached.
Assuming that these steps are sufficiently granular that they fit easily into a sprint, each one becomes a point, and the story is a three-pointer. 

A tangible estimate

One point equals one step in the how-to-demo. 

If any of the steps are too big, it becomes a new card with its own how-to-demo. So let's say Step 2 is "TFB", then we would make a new card. Create and preview the application are each one point, and Attach the CV depends on the number of steps to validate it. If this is also three points, then the total for this feature is 5.

How do you estimate before the start of the project? Simple. Use planning poker, but instead of applying some abstract size, you are guessing the number of acceptance criteria you expect to satisfy. 

Tracking progress

As you implement the project:
  • you take credit for acceptance tests satisfied, just as you did with story points. (The issue of partial credit disappears, because the stories are very small, and a test is passed or not).
  • if the requirements change, you update your guesses accordingly. Do you expect to have more, fewer or the same number of acceptance tests?
  • In backlog refinement (getting ready to implement), your guesses become actual acceptance criteria.
  • Replace your guesses with the actual number of steps in the how to demo. This enables you to keep track of how good your estimates are, because for each story there is an estimated number of steps and the actual number of steps.


As with story points, this approach requires a baseline for comparison. How many individual acceptance criteria can you team actually get done in a sprint? Once you have established this, the math should be the same as for story points: (Size / velocity) * Team Size * Sprint Length = Estimate in Person days.


A point corresponds to a step in your how-to-demo confirmation workflow. An estimate is a guess of how many steps there will be to confirm the story. Backlog refinement confirms or updates the estimate and produces fine-grained stories which are ready for implementation. Velocity measurements, budgeting, a estimating function much like convention story points.

3/12/2017 -- Updated to recognize Pawel Brodzinski, the source of what I dubbed the #NoEstimates scale.  His discussion of the topic is quite illuminating!


Nyland said…
I really like the concept of 'steps'; its something we've been working on with athletic development. (). What do you think of an approach like:

If it took a hundred steps to complete a sprint, how many of those steps would this (PBI) roughly be?
This way you get proper relative sizing, but clear context to the sprint length.

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…