Enterprise Agility – The Big Picture (13 continued): Estimating Epics

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been gradually working our way from the bottom (stories, iterations and the like) towards the top to where the enterprise vision originates. In the last post Portfolio and Vision, we briefly described the Epics that drive so much of the behavior of the agile teams at Level 1 and 2. In this post, we’ll talk about Epic estimation.


Big Picture 13 (continued) - Estimating Epics

Everything Starts with the User Story

Before we discuss estimating Epics, however, we must return to Level 1where the teams do their work. In an earlier post, we discussed the User Story.  This is the artifact used by agile teams to communicate the basic intent of the behavior of the system, heavily weighted towards descriptions which clearly deliver value to the user. User stories are captured and maintained in a team’s Backlog, where they are prioritized, estimated and held until they are to be implemented. Estimating user stories is a team skill that all agile teams must master. The aggregate amount of story points that a team can deliver in the course of the iteration is the team’s velocity, and every agile team has one and maintains it routinely. Velocity represents the amount of user value (number of story points) that a team can deliver over any particular time box. Story points can be measured in the abstract (story points) or as Ideal Developer Days (IDDs), with the abstract measure being the most common.

To learn how to estimate points in the abstract, teams are taught relative estimating, often with the simple exercise below:

Exercise: Assign “dog points” to each of the following types of dog to compare their “bigness”: Labrador Retriever, Dachshund, Great Dane, Terrier, German Shepherd, Poodle, St. Bernard, Bulldog.

With this exercise, teams learn how to assign a “relative bigness” to each dog (or story) without debate or concern for the actual units of measure. Then they use that scale to estimate their upcoming stories and after a few iterations, they know their initial velocity (story points per iteration) by counting the points for all completed stories. When teams change size, or vacations or holidays occur, they simple adjust the expected velocity in each iteration and plan for a greater or lesser number of stories as indicated.

Estimating Delivery of Features or Epics

At the Feature or Epic level, our estimating model can be the same and it builds on the basic agile estimating team skill. We simply estimate these bigger items relative to each other and maintain the relative estimates in the Release or Portfolio Backlog. However, while that part is relatively straightforward (but admittedly it is not so straightforward to compare unlike things to each other), even relative sizing gives us no idea when a team can possibly ship what.

For this next step, we are dependent on the Big Picture’s model of expressing system behavior in terms of the parent-child relationship implied by Epics, Features, and Stories:

>> Epics cause Features to exist; (features are “children” of the epics that spawned them)

>> Features cause Stories to exist; (stories are children of the features that spawned them)

>> Stories are the native implementation unit and are also used to measure Velocity

All that is well and good but it still doesn’t tell us anything about when we can deliver what to whom. For this we need some tracking information which allows us to translate Epics into story points. Fortunately, competent agile project management tools (every agile enterprise will likely have one) support this hierarchical model and will have captured historical story point data for earlier Features and Epics. Given an understanding of what percentage of the team’s time we are willing to devote to the new item, we can use historical data  to predict how long it will take to deliver a new Epic. (Example: Epic A was implemented in about 1,000 story points and took X months; Epic B is a little bigger, therefore B will take a little longer).

The Estimated Cost of an Epic can also be Derived

This provides a rough estimate of the time it might take to deliver an Epic based on teams (and teams of teams) actual velocity. It still doesn’t give us any notion of cost. While the teams themselves may not have a one-for-one translation of a cost of a story point, at the portfolio level it is fairly straightforward to calculate one. Simply, look at the burdened cost for any timebox for the set of teams most likely to implement the new Epic and divide that by the number of story points they achieved in the same unit of time. This gives an estimate of the cost per story point for the subject teams in that domain. So if a story point costs, for example, $1,000, then more story points cost more.

A Big Note of Caution

I suspect that you’ve already applied caution enough with this imprecise, yet effective agile estimating model. However, one additional and critical factor is the assumption that all a team’s story points can be dedicated to a new initiative. That is rarely the case as most teams run from 20-50% of their total capacity supporting the existing product with necessary features that are “below the radar” of the portfolio level, as well as resolving defects, performing research spikes, refactoring and other work items that may not contribute so immediately to new user value. So in applying this model, one must be aware of how teams measure their velocity and base the time estimate (but not the cost estimate) on the velocity which is actually available to be used for new Epics.

That’s it for this post. The next post will likely be a miniseries (a post or two or three) on that last big box to the left, the Agile Portfolio.


3 thoughts on “Enterprise Agility – The Big Picture (13 continued): Estimating Epics

  1. Great post! We use a similar strategy (however our terminology is reversed – an epic is a feature and vice-versa). For this post, I will use your terminology to avoid confusion.

    For determining an understanding of our roadmap, we created a matrix that has releases along the top bar and agile teams along the row portion. The features are the data within the matrix – stated differently, each feature belongs to one and only team and one and only one release.

    While this may seem a bit unclear, it creates a great structure for understanding velocity. You now have the ability to forecast each “feature” based on the actual team’s velocity. You can even expand upon this by using one of many velocity calculations – perhaps the velocity of the past release or perhaps the average of the last three releases. Within each release/team box, we also capture the velocity in the form of points, or FTEs or hours (whatever the team uses). Since we treat each feature independently by team, we can also treat velocity independently by team.

    The epic allows you to aggregate the features in a way that still allows you to track the information properly. Now… if I take a step back, you will know see why we used differently terminology
    * Epic – equates to a team / release level commitment within a given release
    * Feature – equates to one or more epics within a given release (aggregate). This really isn’t necessary though – you can still aggregate across releases
    * Initiative – equates to a collection of features necessary to reach an end business objective (perhaps “WiMax”)

    Dean – I will send you an example of the matrix we created. Might be something worth considering in the future! Nice job!

  2. Hi Dean,

    My question relates to the practicalities of estimating an Epic and, in particular, avoiding the pitfall of “big upfront planning”.

    Given an Epic, I see the general approach being to decompose it into features & perhaps sub-features, estimating them in points and then rolling it up to give the estimated Epic size (and furthermore in conjunction with Velocity, the “when we can deliver what”).

    My gut feel would say decomposing down further into the story level is starting to smell too much like a full blown Work Breakdown Structure & “big upfront planning”, so I was keen to hear your thoughts on how you would balance these competing concerns to meet the goal of estimation, but avoid unhelpful early decision making

    • Christo,
      I see various approaches with different agile teams. Epics are usually too big to be successfully estimated, so yes, breaking into features and then estimating the features using relative estimating to comparable, implemented features, is a suggested approach. Even then, since the estimates come from the teams, some teams will still want to break them into stories to increase their level of comfort. Since this is generally still way above the task level and it tends to preload the backlog with placeholder stories, there’s little waste in that approach, and the teams may feel more comfortable with their estimates.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s