Using estimates for planning
Developing software is a marathon, not a sprint, which makes planning a key part of the process; without a plan, you’ll get dragged away by the events of the day and, eventually, find that you didn’t quite end up where you wanted to.
One of the crucial activities that support planning is that of estimation; while this is a contentious view, in this article, we explain how estimation, when done well enough, can make the difference in the planning of software development.
What is estimation?
In software development, the term “estimation” is commonly used to describe the activity of predicting how long a given task, feature or even entire project will take to complete.
Estimating is then, at its heart, assigning a cost to some action which, in the context of planning, allows that action to be compared with the alternatives1.
Why are estimates useful?
In our experience, estimates are most helpful when combined with the benefit the team expects to derive from completing a particular piece of work.
By plotting a unit of work’s estimated cost against its estimated benefit, we can place it in an Action Priority Matrix2:
Fill Ins, which can be completed quickly but don’t add a lot of value;
Quick Wins, work that has low-cost but high benefit;
Thankless Tasks that, despite their high cost to complete, don’t actually achieve much;
Big Bets involving a lot of effort but also with a large payoff.
By classifying tasks into these four categories, it becomes evident that a team will want to spend most of its time working on Quick Wins and avoiding Thankless Tasks3, since these will generate (in theory) the most value in the least amount of time; thus, the use of estimates provides a basis for prioritizing work.
Summary
While the topic of estimation in software development can be a contentious one, we’ve described one way in which it can be used to support planning activities; by analyzing a task’s benefit and cost, it becomes easier to recognize in which category of the Action Priority Matrix it belongs and thus prioritize quickly, even with large backlogs.
The benefit or value that would be derived from a given work unit is usually an estimate itself; the reason we haven’t included in this definition of estimation is that benefits are often tied to business outcomes and thus not generally estimated by engineering.
We haven’t been able to find an origin for this, although it seems to often be associated with Eisenhower’s Matrix, as popularized by Stephen R. Covey, the author of “The 7 Habits of Highly Effective People”.
While Fill Ins and Big Bets have similar cost/benefit ratios, in practice, Fill Ins should be favored because they’re associated with smaller batches and thus smaller risk.