Consider Stories at Multiple Levels

I often work with teams adding new large features to existing applications. It is common for teams like this who are new to agile to go into too much detail too soon. It seems that those accustomed to waterfall believe you've only got one shot to discuss any requirement, so they must discuss it in detail.

In agile you get many looks at each user story (requirement), preferably from many different angles and ultimately getting progressively more detailed as you go. I like to explain it with these four levels.

VISUALIZE -- The Concept

We typically start with a project name or enhancement name, don't we? It's the handle by which we call this thing. From there we hope to have the vision, a short narrative for what we're after. Perhaps we have the name of a few super-epics. Refine that into some epics. Begin to understand the minimal marketable features (MMFs). Metaphorically, this may be an aerial view of the forest, or maybe the planet. Keep the vision in front of the team throughout the project.

PRIORITIZE, ORGANIZE and SOCIALIZE -- The Forest

By prioritize and organize, I mean use any approach to help the team see how the stories fit into the vision and understand the minimal marketable feature set. An example technique is Story Mapping. Understand your epics. Metaphorically, this is understanding what the forest full of trees looks like.

None of these are a one shot deal. Iteratively refine your prioritization. Tune the MMF and re-socialize stories as you learn and get feedback. You aren't done socializing just because sprint zero is over. For anything of size, you don't get done socializing in just one meeting. Nor does all the socializing happen in meetings.

SIZE -- The Trees

When sizing (with abstract relative points), look at your stories in a little more depth, but not to the level of detail described below. Look at it just enough to give an estimate relative to the other stories. You don't need as much detail for a relative estimate as you would for an hours/days/weeks estimate. You quickly get to a point of diminishing returns. Consider that we use a Fibonacci series or something similar -- we use a diminishing level of precision as the stories get larger. Once you are pretty confident that it's a 21 point story, you don't need to spend more time to make sure it isn't really a 13 pointer.

As with the above, you may look at a story for sizing multiple times. If you've sized a bunch of stories at the start of a release, you should re-size the remaining work after 3 to 5 iterations. By then you've learned more. You will have become more familiar with the project, subject matter and the affected code.

Sizing also shouldn't be expected to be static. How big a 3 point story is will shift over time, especially but not only because of changes in the team. Hopefully the individuals are getting better, smarter, and the code is getting cleaner. Also, the work that we're comparing stories to changes. Point-drift happens. Old estimates are like milk -- they don't get better with time.

PLAN -- The Details

In iteration planning we break stories down into tasks. We estimate tasks in hours or half-days or maybe in pomodoros. We think in terms of detailed design and code and test cases.


Understanding that we're going to see each story multiple times with progressive levels of detail helps overcome the desire to go too deep too soon.

What approaches have you used to help people think about stories at the appropriate level?