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