Carl Erickson recently wrote about the rich life of stories at Atomic Object. In addition to our vanilla user stories, we also create “Epic” stories.
We use Epics as large placeholders for some number of user stories. Epics are written at a very high level, and do not contain much detail. We want to record a general understanding of what the customer is looking for, without having to dig into all of the details.
Epics will typically have very large estimates. One Epic could potentially be estimated to take many iterations to implement. By using Epics to put rough estimates on all of the customer’s desired functionality we can provide them with a better idea of the size of the project, without having to go into great detail in up-front requirements work.
When the customer prioritizes an Epic towards the top of the backlog, it is broken down into smaller user stories. We make no attempt to restrict that the total number of points from the resulting stories adds up to the previous estimate of the Epic. This allows more flexibility in granular story estimates and ultimately better accuracy in the final backlog.
Using Epics in this way at the beginning of a project we can quickly provide our customers with the information they need to budget, schedule, and prioritize. We defer spending the time necessary to gain a deeper understanding of the requested functionality until it is more likely that the functionality is actually going to be needed.
3 Comments
I like the idea of epic stories. They provide a meaningful context to the goals of the application, whether it’s business objectives or user goals. Traditionally, breaking larger stories into smaller ones removes this context which is even further lost by prioritization efforts of a flat backlog.
Combining epic stories and stories with a story map seems to be a much better medium for communicating the full spectrum of business/project/user goals/objectives down thru development cycles. A form of communication that provides value long before development starts and into the development cycles.
I’m very excited about the combination of this type of approach with the kanban philosophy.
Nice.
I have a question about this: “We make no attempt to restrict that the total number of points from the resulting stories adds up to the previous estimate of the Epic”.
How do you find that affects your burn charts? In particular, imagine you are half way through a project. All the epics up to that point in the project have been “expanded” into smaller user stories. But the epics after that point have not yet been expanded. Imagine also that, when expanding an epics, the total number of points in the small stories is typically greater than the total of the original epic.
This would mean that past work has reasonably accurate numbers of points associated with it, but that future work, still in epic form, is underestimated. (Since, when you decompose the future work, its point value will typically go up, so therefore its _current_ point value is too low).
If this happens, it may skew your burn charts and make you think you’re closer to finishing than you really are.
However, from your description of your success with this approach, I take it that this problem doesn’t actually affect you
I have used a similar approach myself but, being concerned about the above problem, I have always taken care to preserve the same total point value when breaking down the epics. Hence my interest in hearing how you have tackled, or avoided, the same problem.
John: Great question. I responded to you comment in a new post: http://spin.atomicobject.com/2011/07/20/breaking-down-epic-stories/
One Trackback
[...] couple of years ago I wrote about how I was using Epic stories for early project estimations. Recently John Rusk posted a question in the [...]