Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label

Estimation is Hard

Flexible plans executed via iterative development are at the core of Agile:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is great for figuring out what to build, but all this flexibility can make planning and estimation hard. In practice, developers tend to prefer backlogs containing a few weeks worth of fine-grained stories following INVEST principles, followed by low-fidelity—and unestimated—chunks of epic-sized features. The thinking is that any stories farther out are unstable, and that it’s wasteful to spend time specifying them in detail. Agile planning tools like Pivotal Tracker are built with this perspective in mind, and are great for managing fine-grained details. But what happens when you need to get a more big-picture view of a project? Recently, a colleague said:

As development moves forward, features change. And those changes have implications on the stories later in the backlog or icebox. … Not sure if this the best way since it causes me to not want stories that extend beyond a few iterations.

Isn’t this the perfect distillation of the Agile Manifesto’s notion of “Responding to change over following a plan”? I find the problem isn’t changing stories—this is a natural part of Agile development. Rather, the difficulty is doing the work to 1) figure out which stories are stale, and 2) to re-estimate stale stories, lest 3) clients make plans based on stale estimates and then get upset when we say “sorry, those estimates aren’t accurate any more”. Ideally, the estimates will be revamped downwards (there’s less uncertainty now that we know more about what’s going on, right?), although sometimes we’re discovering hidden complexity and the estimates go up. D’oh!

The Assumptions Label Technique

One technique I’ve used successfully on a few projects is what I like to call the Bullpucky Assumptions Label. I pull it out when the client demands—not unreasonably, I might add—that we estimate out the next 3-12 months of work so that they can get funding / approval from their boss / etc. I’ve seen project teams fight this for weeks (the PM getting more irate and frustrated the whole time), finally lose, and schedule a (miserable) half- or one- or two-day mini-inception during which they proceed to estimate every story for the next few quarters in fine-grained detail. Of course, they inevitably have to re-estimate half those stories in angry IPMs when it becomes clear the estimates are wrong, grumbling “we told you these estimates were bullpuckey”.

Here’s the Assumptions Label technique:

  1. Schedule a 2-3 hour Assumptions Meeting with the PM and 1 or 2 devs. (You don’t need the whole team; these aren’t real estimates). Estimate “stories” (they’re really closer to epics) at a multiples-of-8-point level of granularity. Pretend we’ve built the basic shopping-cart and inventory functionality of Hamazon (“The Internet’s Favorite Purveyors of Pork since 2009!”), and now the client wants to fully copy Amazon’s feature set. It might contain rough estimates like “Reviews and ratings? Mmmm…24 points. Recommendation Engine? 40 points.” Rough out the desired feature set. You’re basically estimating at a pair-week level of granularity, so multiply pair-weeks by (velocity/team strength) and you’ve got your pointed estimate.
  2. Write titles in all caps (they’re easier to see that way). Don’t bother writing a description for the story. It’s ok to use multiple 8-pointers to get to the number you need.
  3. Throw an “assumptions” label on all these stories; they’re easier to wrangle (and it never hurts to drive the point home).
The Assumptions Label technique in action.

The Assumptions Label technique in action. Use it to re-prioritize coarse-grained blocks of epic, and watch estimated completion dates adjust.

Now your PM can give a rough estimate to their boss or their boss’s boss, re-prioritize at a rough level of resolution, and cut scope or add pairs. But it remains clear to everyone that these should never be mistaken for actual, deliverable stories. In fact, these “assumption” stories become a decent way to see what’s next when story-writing. IPM or pre-IPM often becomes an exercise in picking the top assumption off the top of the file and fleshing it out into real stories. By reducing the difficulty in seeing what’s a real story and what’s a rough estimate for planning’s sake, everyone gets better visibility into the project. Pivots can set better expectations for their PMs, PMs can set proper expectations for their boss, and trust is preserved on the team.

  • Matthew Parker

    On our project, we just had a release planning where we gave a scoping-level estimation for the work discussed. This was in response to our clients stated goals – get a rough idea of how much work was left (in pair hours) so that they could request funding / resourcing for the remainder of the project. We considered creating stories (or at least story titles) in tracker and giving them “estimates”, but discarded the idea; we knew half of the stories would change, the other half would be discarded, and all of the estimates would have to be redone.

  • Jonathan Berger

    > we just…gave a scoping-level estimation…so that they could request funding / resourcing…we knew…all of the estimates would have to be redone.

    That’s exactly the problem that we’ve used the Assumptions Label technique to address. I’ve found it helpful to keep as much planning as possible in one place (e.g. Tracker). As long as its trivial to distinguish real pointed stories from scoping-level guesses, this coarse-grained planning seems to work.

  • Pingback: Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label |

  • Munish M

    I found the article very useful, and pragmatic.
    We had come across a similar need where we utilized the bucketing approach to size the project. It turned out to be a pretty logical approach, and bucketing epics made the business owners understand the relative complexity of the requirements.

    However, I would like to know your opinion on the assumptions that should be laid down while sharing these ball park estimates to the stakeholders. Also, I would appreciate if you have any ideas on how the estimates, assumptions should be presented.


  • Pingback: Estimation Sanity in an Agile World - Aspirent ConsultingAspirent Consulting()

  • Jonsi Martten

    Great idea – how has this been working out for you? I think we might borrow this table of yours. I’m just about convinced now that agile methods like scrum can work for projects longer than 6-9 months in span. I was reading this: , paired with what I just saw here – feel almost confident to put my as* on the line and try this with my dev team. Thanks a bunch!

Share This