What is a Story Point: CURE the Debate

These dishes will reveal the CURE to your estimation woes. In Sprint Planning or Backlog Refinement, an occasional yet recurring debate sometimes breaks out concerning estimation. Are we talking about effort or complexity? Spoiler alert: if you think it’s all about effort, you’re wrong.

## What Are Story Points? **Story Points are a unit of measure commonly used to estimate the amount of work to complete a user story.**

Story points originated from Xtreme Programming. Points were a simplification of ideal days (another type of agile estimation) in an attempt to decouple the rough estimate from the precise expectation of calendar days. Ron Jefferies rebranded ideal days as story points, hoping that the obfuscation would prevent the sense of accuracy associated with the word ‘days.’

When I say mopping the kitchen floor is two points of work, that statement tends to go unchallenged. Especially if I explain that I based the estimation on taking out the garbage, which is one point of work. However, if I were to tell you that mopping the floor was two ideal days, this would likely warrant a skeptical response. How in the world is it going to take me two days to clean that floor? A three-year-old could do it in less than two days.

Moving to a more nebulous unit of measurement avoided some of these wasteful conversations and allowed conversations to focus on more important matters. Since agile teams commonly leverage user stories to capture user needs, the points naturally became story points.

How are Story Points Decided?

Story points are assigned based on a collaboration of the development team that considers complexity, risk, uncertainty, and effort.

Although these aspects sound similar, some nuanced differences are essential to understand. Let’s go through an example.

Let’s imagine our dishwasher is on the fritz, and we’ve asked a couple of volunteers to estimate the work to wash and put away a small pile of dishes. Since the point of this contrived situation is to demonstrate the factors of estimation, our friends will use, you guessed it, story points.

This small backlog of dishes we need to wash consists of a glass, two knives, a cheese grater, and a pizza cutter.

Effort

Looking for the most effortless item first, our team decides to start with the dinner knife. To wash this knife it’s two swipes of a sponge (one for each side). If you’re proficient, maybe a grip and slide can do both sides simultaneously.

Even though our friends have different levels of experience with manually washing dishes, they agree that the knife would be a one in terms of story points.

They’ve based this exercise of estimating solely on the level of effort. They feel pretty confident about the work they’ll need to do, and they don’t feel like there is any risk associated with this particular utensil. As far as complexity goes, you can’t get much more straightforward than this table knife.

Complexity

Next up in the dirty dish lineup is the glass.

Washing the glass will involve more than a couple of swipes with the sponge. To make sure the inside is clean, we’ll have to do a bit of a squish and swish. Then we’ll need to peer into the bottom to verify that there isn’t any residue hanging out down there. Even though this isn’t overly complicated, it does involve more complexity than the knife. Our friends estimate the glass as two story points given the additional (albeit slight) difficulty level.

Now they move on to wrangle this basic kitchen necessity. As you can see below, this isn’t a typical pizza cutter; this thing comes apart into five different pieces. Although it doesn’t take a brain surgeon to put it back together, my family struggles with it every single time.

You have to put the two smaller circular fidgety bits together through the blade, align them just right, and push them together until they click. Then, a hole in either side of the transparent cover slides over the small column in the green handle. Next, the blade assembly slides over the column. The transparent cover then folds in half at the hinge, laying the other hole over the green column. Lastly, the green handle is folded in half to snap the whole thing together.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

-Alan Perlis

After this explanation, we take a moment to debate the pros and cons of tossing the pizza cutter in the trash and buying a new one. Once we decide that’s a bit ridiculous, the team gets to work on accounting for the complexity involved. They figure each of the larger pieces (blade, green handle, and clear guard) are roughly equivalent to the table knife. So, that logic puts them at three points (one each for the larger pieces). Given the insane complexity, they bump the three up to five.

Risk

The next dish is the chef’s knife. Technically speaking, the blade would be roughly equivalent to the dinner knife as far as effort is concerned. The chef’s knife is more straightforward than the glass and less complex than the pizza cutter (perhaps we should just cut pizza with this knife and trash the pizza cutter?)

However, this particular knife is that it’s sharp, and it will require some careful handling to prevent a nasty cut. We also need to be a bit more diligent about putting this item away to avoid the future injury of others.

Risk is the aspect of story pointing that applies in this situation.

Due to the added risk the knife introduces, our imaginary estimators agree that it’s probably a three, about twice the work as the dinner knife, plus the additional risk.

Uncertainty

Now, we’re going to throw our estimators for a bit of a loop. Seeing that we’re getting ready to wash some dishes, my housemate points out a dirty casserole dish in the kitchen downstairs that also needs cleaning.

Having seen this dish before, my friends have a pretty good idea of the size and the complexity of the shape compared to other objects they’ve already estimated.

However, there is an element of uncertainty for this casserole dish. Without knowing what last cooked in it, we can’t say the effort involved in cleaning it. Does it have that pesky ring of burnt-on cheese that we’ll need to shuck off? Or perhaps it was lined with aluminum foil in its last use and will therefore be virtually spotless already?

Washing the casserole dish will have the same squish and peer dynamics that we used for the glass, but there is more surface to cover. So, my imaginary friends start with a four (which isn’t a potential value when using an adjusted Fibonacci scale). Then they knock that up to a five to account for the uncertainty. Our fearless estimators debate going up to an eight but decide it might be unwarranted in this case after my housemate assures them it wasn’t “too dirty.”

Story Points Example

Let’s bring it all together.

Now they come to the last item to be estimated, the cheese grater. After eyeing the cheese grater for a bit, our estimators decide it checks off all the aspects of story pointing.

There is an effort in washing the cheese grater, certainly. There is also a bit of risk, as it has some sharp holes and slicing edges. We’re uncertain what kind of cheese was last grated on its surfaces, which is applicable because some types of cheeses will clump up in the holes, and it’s a nightmare to get out. The plethora of holes also introduces complexity. Each side has different-sized holes and shapes and slicing edges. We’ll need a slightly different approach to cleaning each side of the cheese grater.

Our brave estimators start with a two, reasoning this is about the same size and shape as the glass, so it should be a similar level of effort. Then after taking into account the risk, uncertainty, and complexity, they bump that up to an eight.

Consider All Factors

If the agile development team doesn’t consider all four work factors when providing estimates, they’ll likely underestimate their work. Low estimates can contribute to an inability to complete the committed work within a sprint. If the team piles on stories with unaccounted risk, uncertainty, or complexity, they’re likely biting off more than they can chew.

If your team struggles to complete their sprint backlog, discuss the reasons in a retrospective. Ask leading questions to determine if we’re accounting for all factors of our work during estimation.

The Real Reason for Using Story Points

Regardless of the estimation process, the calibration of estimations will require the development team to reach a shared understanding of the work. The same conversations that allow us to triangulate our estimates will help us uncover unknowns that we may not have accounted for individually. We’ll have a shared understanding of the proposed implementation when all is said and done.

Why use Story Points?

I recommend using story points over time estimates for two main reasons. First, it’s faster than estimating in time. Second, it decouples estimates from deadlines.

Once a team gets in the groove, story point estimation will be faster than time estimations. Something psychological happens when you ask someone to provide time estimations. Because we tie time-based estimations to tangible units of time, there is more pressure to be accurate. The thing is, though, no one can predict the future with one hundred percent certainty. So, the extra effort we spend reaching a false sense of accuracy is wasteful.

Problems with Story Points

Story points were created as a deliberate obfuscation from time estimates. I understand the purpose and need for this, but it also feels somewhat shady. Taking this approach seems out of alignment with Scrum’s value of openness. Alternative methods like some of the metrics described in David Anderson’s Kanban book feel more pragmatic and mathematically sound, in my opinion. However, I accept that story points can be a stepping stone to better agile estimation techniques.

My second issue with story points is that they’re hard to explain to stakeholders. Constantly clarifying how story points work, what they mean, and why they’re better than estimating in hours can be irritating. At times I’ve felt like it eroded the confidence in the development team. I’d be skeptical of a lawn mowing service that estimates based on how many grass souls they’ll exorcise. The concept sometimes feels a bit too frivolous.

Works Consulted

• Story Points Revisited
• Head First Agile: A Brain-Friendly Guide to Agile Principles, Ideas, and Real-World Practices
• User Stories Applied: For Agile Software Development

TLDR

Estimating without accounting for all four aspects of work can significantly contribute to an inability to meet commitments. When estimating, consider each of the four factors: complexity, uncertainty, risk, and effort. If you’re like me and struggle to always remember these four dimensions of estimation, remember the mnemonic CURE instead.

(C)omplexity (U)ncertainty (R)isk (E)ffort = CURE