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”.

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.

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. 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.

4 Comments

Matthew Parker says:

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.

April 1, 2013 at 10:16 pm

Jonathan Berger says:

> 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.

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.

Jonathan Berger is a designer, developer and technologist who has been active in the NYC technology scene since around 2005, helping to organize events like the Agile Experience Design Meetup, the Pivotal Labs Tech Talk series in NY, Startup Weekend, Barcamp, Fashioncamp, and IgniteNYC. He spends his days building software with Pivotal Labs and his nights and weekends working on Market Publique. Prior to that, he earned a Bachelors in Philosophy at Vassar College and a Masters in Media Studies at the New School(where he also spent quite a bit of time at Parson’s Design + Technology program). He has worked as a designer, developer, video editor, animator, and technology consultant for institutions as diverse as Eyebeam, MTV Networks, Yahoo!, Ogilvy, and the American Museum of Natural History.
He speaks about startups and technology at events like the Future of Web Design, O’Reilly’s Web 2.0 Expo, New York Tech Meetup, Fashion 2.0 Startup Showcase, Startup Weekend, North Brooklyn Breakfast Club, The Product Group, and others.
He makes it a point of honor to include Comic Sans in every design project.
Find him on twitter, github, flickr, etc. as @jonathanpberger.