Estimates are difficult, usually wrong, and frequently misused. The problem only gets worse as the scale of work increases and you are estimating for larger-scale work involving multiple teams.

Definitions of "epics" vary, but I define them as those larger packages of work that will take an entire development team at least one cycle to complete. Most organisations have a long list of “epic” level things that they want to do. There needs to be some process of prioritizing these “epics”, which usually involves some trade-off between value and effort.

That is where the problems set in. It is difficult to estimate the effort required at an epic-level scale as the margin of error is too great. There are too many variables and too many uncertainties. At this level, the best you can do is waive your finger in the air and make a guess.

This lack of certainty makes estimation a poor tool for identifying the trade-offs between different pieces of work. The process of creating estimates can also be corrosive as it encourages the kind of top-down, up-front planning that can stifle iterative, evolutionary development.

Story points, gummy bears, and other failures

Agile orthodoxy tends to be a little hazy about planning large-scale work. It regards estimation as a collaborative, team concern that is usually managed through an arbitrary scale. This can be based on story points, “t-shirt sizes”, “gummy bears” or even NUTS (Nebulous Units of Time). The Fibonacci sequence is often used to bake in the notion that you can estimate smaller and better understood features more accurately than larger ones.

All these units are used in much the same way – teams calculate their velocity based on the number of units they have completed in previous iterations. This gives a constantly evolving view of the team’s capacity that can be used for planning. This mechanism tends not to translate well into larger scale work as the relative value of any estimation unit will vary between different teams.

The Scaled Agile Framework (SAFe) attempts to overcome this by forcing teams to normalise their estimates and enable cross-team planning. Epic estimation in the SAFe world arrives at a duration estimate based on a combination of story points and historical velocity for the teams involved in delivery. The outputs of this number crunching might look plausible on a dashboard, but as indicators of effort they are little more than a guess dressed up as certainty.

Scrum tends to focus on a single team and is a little quiet about larger scale development. Large-Scale Scrum (LeSS) does at least recognise that more structure is needed for groups of more than eight teams. It organises them into separate “requirement areas”, each with their own high-level backlogs. It gets a little hazy on the detail of how this work is specified and estimated.

None of this makes it easier for technical teams, who are often reluctant to commit themselves to any large-scale estimates. They will perceive a project that is riven with uncertainty and ambiguity. It may just be scary to think about or too big to really get their heads around. They are likely to be wary of being held to these estimates in the future. All developers know that estimates are just guesses, and pretty bad ones at that. Not every stakeholder realises this too.

Some have even gone as far to try and banish estimates from planning altogether. I have a lot of sympathy for the #NoEstimates movement. On a micro, team-based level you really can organise work in terms of small incremental chunks of work and push rapidly towards a shippable product. It’s just that people who make prioritisation decisions cannot work like this.

Side-stepping estimates by setting an appetite

Large-scale estimation has always been one of the great fallibilities of agile, iterative development. If you are trying to get anybody to agree to fund a big chunk of development, you cannot go into the conversation without some indication of relative cost. That means an estimate, right?

Basecamp's "Shape up" methodology offers an alternative approach that side-steps the need for an estimate while allowing a meaningful debate about relative cost and value.

When you are defining work on an epic level, you still in the process of trying to work how much time you are prepared to spend on something. This sense of an appetite defines the budget for a solution. It creates a constraint where the timescale is fixed but the scope is variable.

This appetite does not indicate how long it will take build a mature solution. It expresses how much time the business is prepared to invest in it. This is the crucial difference between an appetite and estimate. The former is a measure of interest and perceived value, while the latter is an expression of scope based on large-scale guesswork.

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design.
Shape-up, chapter 3

In every project there is a tension between time, quality, and scope. Estimates tend to undermine project quality by forcing teams to commit to a particular scope and timescale. Defining an appetite on the other hand encourages teams to make hard decisions about what really matters to the project. It helps to concentrate minds and encourage an efficient approach to design.

It does not insulate you from some of the more familiar problems of agile planning. There will be disagreements over what can be reasonably expected within the timescales and teams will still come under pressure to “do more for less”. Appetite helps to frame these arguments in a more helpful context by shining a stronger light on the trade-off between effort and scope.

Filed under Agile and Development process.