A concrete alternative to estimating story points in Scrum

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)

Acceptance Tests: A concrete basis for estimates

Tracking progress

Budgeting

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!