When we drive development with stories, we need the stories we're actually working on to have numerical estimates of size; we use these numbers to calculate a velocity, which is an approximation to our capacity. By having a capacity we can have some confidence in our budgeting and predictions.

Fine.

This logic leads toolmakers to make tools that require a size value for all our stories. This is where I have a problem. And it's with epics, which are usually large, fuzzy, unknown, stories (some epics are large and very well known, but I'll ignore those for now).

When we estimate a story when we don't really understand it, we're creating an illusion of knowledge. This illusion is then often used for long-range planning, and the illusion becomes a reality, called a budget. That is, estimating an epic is actually budgeting the amount of effort we are willing to spend on that epic. Now, this budget may be in Story Points, not days, but after we have a Story Point velocity (by working on well-defined stories) it becomes a budget.

We may want this. If we do, then say "I budget 128 SPs for this epic in this release" and extract the new epic "Release X version of Epic" and put it in the backlog. Of course, the rest of the epic (with unknown size) is still sitting there, right?

In general, though, I recommend we don't estimate epics, and that our tools allow for this. In my dream tool, I can estimate an epic by putting in the word "epic" or "unknown"; in other words, let my tool reflect what I actually feel, don't make me conform my feelings to the tool.

Of course, my tool is going to have to be transparent, and tell the truth. When I ask it how much stuff is in my backlog, I expect an answer like "345 SPs, and 3 Unknowns" to let me know that there is ambiguity in there, and hence, risk.

Just my 2 cents...

Dan ;-)
dan@danube.com