How to Estimate Big, Scary User Stories

Let’s talk about how to deal with stories that are hard to estimate. (If you’re interested in a broader discussion of Agile point-based estimation, check out this post over here.)

In every backlog I’ve estimated, I can recall running into a handful of stories for which I had no idea what point value to assign. I’d usually be using the following scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. Most of my estimates would fall in the 1-13 range–nice and concise. I could feel a pattern coming together directing where every story would fit. Each one would take about the same amount of time to discuss. And then…

I encounter the story that knows no bound. The Un-estimatable Story. Anxiety wells within me at the thought of the protracted, drawn-out conversation about to begin as we get pulled into a rabbit hole made up of more rabbit holes while trying to define this mini-project.

Should I skip it? I would very much like to.

I don’t want to spend an hour blabbing about this one story when we have so many more to estimate which are well-defined.

So again: Should we skip it?

Yes, AND estimate it!

We can do both, and I’ll show you how.

The Strategy

First, let’s bring out the big guns: the 20-, 40-, and 100-point estimates. Think of these numbers as a different category of estimation. Estimates in the range of 1-13 provide value by producing accuracy when considered in aggregate. Estimates made with 20, 40, or 100 are valuable because they highlight risks needing management.

Put another way, don’t think of a 100-point story as breaking down into twenty 5-point stories. Rather, think of a 100-point story as twice as risky or scary as another 40-point story.

Now, this might not sound like skipping or deferring the estimate. And that’s correct; we’re technically assigning a point value. However, we’re not going to de-risk this story now, or break it all the way down now, or have a design discussion now. Instead, we’re going to squint, pick a number that feels about right for the risk or lack of clarity we perceive, identify some next steps to learn more, and move on.

More Tips for Assigning Points

If you’re still having trouble picking a number, consider one of the following lenses for evaluating the story:

    1. Does it include a big technical risk? e.g. It may integrate with a third-party service or use a library you’ve never used before. Pick your estimate based on your gut feeling about the worst-case scenario AND add a chore to the backlog, estimated as a time box, for doing a technical spike to gain more knowledge about the technical risk.
    2. Are there multiple ways something could be implemented and no clear decision? e.g. You may see multiple approaches from a technical perspective, or multiple ways the feature could be designed. Make your estimate with the most expensive option in mind. List any alternative approaches in the story details, and denote which one you were thinking of for your estimate. Add and estimate a technical spike chore to your backlog if there’s any research or experiment that could inform your final choice.
    3. Is this story actually a bunch of smaller stories? e.g. It may break down into “Users should be able to view reports” or “Public API.” In this case, guess the average size of one of the smaller stories, then multiply it by your best guess as to the amount of stories. For example, if you think each report would probably be 8 points and there are four or five reports your stakeholders want, go with 40 points and record your assumptions in the story details. Again, if there is any technical prototype or research you could do to inform your choice, add a chore to the backlog to represent it and estimate it.

You may see a pattern emerging with these three archetypes of big stories. For each of them, we:

      1. Make some high-level assumptions that are reasonable based on what we do know.
      2. Record them in the story.
      3. Use them to derive an estimate that quantifies the cost to contain a risk.
      4. Identify any next steps the development team can take to gain a better understanding of the work represented by the big story, and add it to the backlog as a chore.
      5. Lastly (not mentioned above), record any questions for your product owner, customer, or UX designer in the story details.

Benefits for Your Backlog Manager

When employed, this approach yields all the tools I would need to take appropriate actions as a backlog manager. I can use the relative sizes of these large estimates to understand the magnitude of risk associated with each story. I can use this information to manage the risk of these items appropriately. I may choose to avoid some of these items altogether, pushing them back to a follow-on release or scrapping them completely. If there are technical spike chores associated with the large story, I can prioritize them into the next sprint, ensuring we gain knowledge in the areas most likely to create problems. I can take product, customer, and UX questions to the appropriate people to gain clarity and follow up with the development team once we have enough a clearer direction.

Having the risk represented in points will naturally motivate me, as a backlog manager, to bring clarity to these items or make tough decisions. While these big numbers may not be precise, they’re much more accurate than the cumulative effect of 0 points I’d get from a story with no estimate.