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.

Budgeting

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.

Summary

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!



Comments

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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…