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