Estimating the Sizes of Epics

Many, and perhaps most, agile teams use Planning Poker to estimate the sizes of their user stories. Agile projects can have up to a few hundred, even a few thousand (in multi-year projects) user stories.  If building the requirements runway is done entirely upfront (i.e. before the sprints start), the writing and estimation of the user stories may take a few weeks or longer, making the project look more like a waterfall rather than an agile project.

If we just spread the estimation of the user story sizes throughout the agile project rather than do it all upfront, we still need a way to come up with the initial point (or at least an early point within the first 3 to 4 sprints) on the product/release burndown chart.  Determining such an early point requires that we know the summation of the user story sizes for the product/release.  Note that knowing such a point on the product/release burndown chart is crucial for the early determination of whether the agile project can achieve on-time delivery of the functionality on the product/release backlog.  This is because after 3 to 4 Sprints, we can divide the initial (or early) point on the product/release burndown chart by the average velocity of the agile team to see how many sprints are needed to complete the backlog.

To determine such an early point on the product/release burndown chart without being bogged down by an inordinately long building of the requirements runway, Planning Poker can be done on epics rather than on individual user stories – after all, what’s an epic but a big, fat user story.  Since the number of epics would be much less than the number of user stories, the time required for such estimation would be much shorter to spend at the beginning of the project to get an initial point on the product/release burndown chart.  The agile team can proceed in one of the following two ways to poker-plan epics: time required for such estimation would be much shorter to spend at the beginning of the project to get an initial point on the product/release burndown chart.  The agile team can proceed in one of the following two ways to poker-plan epics:

1. Once a list of epics is obtained, either directly from the product owner (PO), or from the PO working with other stakeholders and with the agile team, the team can proceed to poker-plan (i.e. estimate the sizes) of the epics before breaking any epic into its constituent user stories.  Each scored size is then multiplied by ten to recognize the larger size-scale of epics (as compared to user stories).  For example, if an epic is scored to have 13 points, its size will be captured as 130; if it’s scored at 40, its size will be 400, and so on.

This technique requires that the planning-poker participants possess enough insight into the domain of the agile project to be able to come up with such epic estimates without first breaking them down into their respective user stories.

In any event, when the first epic is broken down into stories, and the stories are completed in the Sprints, the total size of the stories may end up being different from the originally estimated epic size.  So an epic with an originally estimated size of 130 may yield stories that add up to 200 points.  In such a case, the rest of the epic sizes be scaled up (or down) accordingly.  So a yet-to-be-broken-down epic of a size of 400 would in this case be scaled up to (200/130)x400 = 615 points.  This allows the team to come up with a more accurate estimate of how many more Sprints are needed to finish the work.

2. If the poker-planning participants do not possess enough insight into the domain of the agile project to be able to come up with such epic estimates, I found that such teams can develop better insight for estimation if they start with poker-planning user stories first, and then proceed with estimating epics.  The team can select about 10% or fewer (as experience has shown) of the epics as representative epics for breakdown into their respective constituent user stories, poker-plan the user stories, add up the sizes of the user stories to come up with a total for each representative epic, and then use the sizes of the representative epics to poker-plan the remaining epics.

For an epic to be “representative”, it needs to be conducive to comparisons with other (non-broken-down-into-user-stories) epics for size estimation.  For example, in a system that processes health insurance claims, “process professional claims” can be selected as a representative epic to break down into user stories, and then to compare its total size to other (non-broken-down) epics like “process institutional claims,” “process dental claims,” etc.

To recap, early in an agile project estimating first the sizes of epics enables the team to relatively quickly get an estimate of the total size of the release backlog.  This total size is important to begin to figure out how many sprints it will take to complete the release, especially for a large project.  The team should still estimate the sizes of individual user stories, which can follow the estimation of epic sizes.