Estimation is an improbably lively subject. The #NoEstimates movement is one recent window into the maelstrom that’s proven of interest to agile colleagues and clients alike, so read on for both referenced summary and unvarnished opinion on the matter.
Why Estimate at all?
What is the point of estimation? It is one potential solution to a legion of different questions:
- Portfolio Selection: What projects should we do, based on cost vs. benefit?
- Budgeting: How much will our development work cost?
- Forecasting for Clients & Stakeholders: When will we get it?
- Setting Targets for Scope Control: How long should we give ourselves?
- Story Splitting: Are stories small enough for development?
- Capacity Planning for the Team: How much will fit in the sprint?
- Scenario Planning for the Team: What approach gives the best cost/benefit ratio?
While these seem like reasonable questions, is estimation the best way to answer them? In my opinion, it often is not, but there are exceptions.
Defining #NoEstimates
I have observed advanced agile teams go without estimating, remaining highly reliable and predictive nonetheless. This is how they went about it, as well as the loose formula for #NoEstimates:
- Create focused, relatively stable, bounded and largely crossfunctional teams.
- Focus the teams on picking the most valuable work to do.
- Break work down into small chunks with clear objectives, usually just a few days.
- Measure how long things take, Kanban-style (e.g. 4.8-5.2 days on average).
- Forecast based on short and long-term delivery cycle data.
The #NoEstimates movement has largely focused on alternatives to estimation for agile team capacity planning and short-term forecasting, though you will find discussions on the other potential reasons for estimating as well. Based on my experience, the guidance above makes sense in most situations, whether we’re talking about software development or not.
However, it’s apparent that these ideas do not address the entirety of the concerns noted above, so perhaps eliminating estimation is just one part of a broader strategy.
Estimation for Portfolio Selection & Budgeting
Selecting projects based on relative projected cost/benefit is obviously commonplace. But the word “projected” should give you pause considering how often this activity goes strongly awry.
Assessing future benefit with accuracy is no mean feat, 
or more than 10% of new businesses would succeed. The fact is that most organizations do not even bother to track ROI; it is both difficult and ultimately largely pointless, as what’s done is done and times keep changing. This means that one variable of two in our cost/benefit equation is usually a wild guess.
As for estimates, they are demonstrably weak predictors of completion more often than not, a trend that worsens with large projects and long timeframes.
Perhaps asking “how much will it cost” is the wrong question to guide fiduciary control. A better one is “are we spending whatever resources we do have in the wisest way?” And we should ask this much more often than once per year.
The alternative? There are several popular tactics that can facilitate stronger financial controls and greater predictability while substantially reducing effort and waste in both areas:
- Stop doing projects and move to persistent value streams (#NoProjects).
- Align stable teams against these value streams.
- Fund value streams, departments or teams instead of projects.
- Budget and fund more incrementally, quarterly or monthly instead of annually.
- Plan and communicate smaller, more frequent deliveries, adapting constantly.
- Track and optimize revenue streams based on current, local information that feeds planning on agile teams (this is part of the promise for DevOps).
Forecasting for Clients & Stakeholders
The old way of forecasting involved estimating large batches of requests within a project context. It is a well-established fact that what we appear to want or need tends to change as projects go along. The fundamental reason for the existence of agile methods is to address this truism by making change cheaper and easier.
Given this, why set expectations and spend significant energy forecasting things that might never happen? One problem with exerting significant energy towards something is that it makes changing direction harder. We’re less likely to walk away from a design that took us a matter of days to create versus one that we only discussed in theory, and much less a project we’ve spent months analyzing and estimating.
This said, there is perhaps an appropriate time and place for forecasting, but how much, and where can we do it without estimating?
- Estimate major initiatives with coarse units like T-shirt sizes (XL, L, M, S).
- Break projects into releases of no more than 3 months or so each.
- Create real-time release capability through continuous delivery infrastructure.
- Measure team capacity using story count ranges (45-50 stories per sprint).
- Create detailed story maps for new products, and use story count to project delivery ranges. Example: 180 stories might take about 5-6 sprints for a team that historically delivered 30-36 stories per sprint.
Estimates for Scope Control
“Work expands so as to fill the time available for its completion.” Known as Parkinson’s Law, this old adage reflects our human tendency to use whatever we’re given to do the best job we can. Why give back time that could be used for further creation and polishing? That’s just when things are getting fun…
…so we give ourselves dates, to force our own hands. But then, in agile methods we already have timeboxes like sprints and purposefully small stories addressing this very same issue. So do we really need dates at the release or project level too? I think that, absent unbreakable external commitments, the answer is a qualified “no.”
The core agile stance is that we should consider how much we’re willing to invest in something to determine what it’s worth, and that the true level of investment unfolds most rapidly once things get underway. Thus, small experiments upfront can help to determine how long something might take, and we can certainly then guess at a likely completion timeframe. But why lock things to a rigid distant date upfront if we can’t determine when the business value will have been achieved?
I will note an exception for long-form experiments like that seen in the XPrize, which are intended to generate prototypes rather than final products. These are simply large timeboxes, appropriate in instances where extensive research needs and audacious goals require more time to get to a solid external inspection point.
The alternative:
- Use standard lean and agile time-boxing techniques to control local scope creep.
- Focus on enabling frequent inspection and adaptation.
- Make feedback loops between team, business and customers as tight as possible to quantifiably assess value against investment.
- Keep investment and adaptation decisions as local as possible to ensure informed context.
Estimates for Story Splitting
Here’s one area where I think new teams can get some benefit from estimation. I have a great deal of personal experience with standard agile methods like planning poker and story pointing, and I’ve seen them all work well. I believe they can help drive cross-functional conversations that illuminate the full scope of work, and eventually can lead to more poly-skilled individuals. They are also reasonably predictive, but Kanban with rearview-mirror cycle time projections can be even more so.
But it is of course the conversations more than the estimates which produce value. It is the small units of work that result which make work easier. So, simply focus on cross-functional behavior and communication, drive towards highly modular and quantized work, and drop the numbers.
Estimation for Capacity Planning
Capacity planning at the team level amounts to figuring out what a team or individual can accomplish within a timebox. This can again be accomplished as easily by keeping work in small chunks and seeing how much of it gets done historically.
With well-employed techniques like collocation, daily scrums, visual planning and scheduling systems already helping to ensure that capacity is wisely applied in real-time, the need for estimation-based capacity planning at a team level becomes largely redundant. Use simple story count ranges to get an idea, but focus more on flowing in the best stories at any given point in time. Let leaders like Product Owners keep local efforts focused towards the greater good.
Individual capacity planning? Leave it to the team to figure out. Manage investments at a higher level, as activity-based costing makes little sense when team members work together across activities.
Estimation for Scenario Planning
What about when teams need to figure out which developmental approach, tool or pattern is best? Shouldn’t they consider relative cost versus perceived benefit? Well, of course… but once again, do estimated numbers help this or not? Could we subjectively and wisely select between options without first quantifying their respective costs?
Again, I’d say simply leave this to the team. I have no problem with using quantified information to drive decisions when the data is good and plentiful, but it often isn’t. Obviously different options may make quantification simply unnecessary. If the team is sufficiently knowledgeable, they will usually make the right choice.
And there again is the rub; it is local knowledge, wisdom and ability to compare options which are truly valuable, while estimation remains just one possible means to those ends.
Summary
Returning to our original justifications for estimation, I would rate its performance for each question as follows:
- What projects should we do, based on cost vs. benefit? Fine at a high level.
- How much will our development work cost? Alternatives are better.
- When will we get it? Sometimes useful, but alternatives are better.
- How long should we give ourselves? Sometimes useful, but unnecessary.
- Are stories small enough for development? Sometimes useful, but unnecessary.
- How much will fit in the sprint? Sometimes useful, but unnecessary.
- What approach gives the best cost/benefit ratio? Sometimes useful, but unnecessary.
So the point is this: with the right environment, team structures and practices, estimation becomes a blunt tool rendered largely unnecessary. Try dropping it and applying some of the practices noted above, and see what happens. If you need help, you know who to call…
References
For further erudite thoughts on the #NoEstimates subject from the community:
- Vasco Duarte is a leading light on the subject. Two references from him:
- A new book: https://noestimatesbook.com/
- A great video: https://noestimates.org/blog/2014/07/vasco-duarte/
- A nice summary: https://www.scrumalliance.org/community/articles/2016/june/noestimates
- Perspectives from six experts: https://plan.io/blog/post/145902333978/noestimates-6-software-experts-give-their-view
- Some deep thinking and a story: https://www.methodsandtools.com/archive/noestimates.php
