I gave a talk a few years ago and shared some engineering strategies I use regularly to help teams deliver their best work. The ‘Less Estimation, More Iteration’ slide often sparks some good reflection and great conversations.
What is estimation?
Generally speaking, estimation is an attempt to understand the level of effort an engineer (hopefully the person doing the work) estimates it will take to complete the work. The premise of the practice, at its core, is to identify the complexity and the unknowns of the work in order to estimate the level of effort and by that the investment/cost to get the work complete.
Most teams and their leaders lose sight of the value of this practice and sadly either waste fruitless hours debating whether a story is an 8 or a 13 (if you use story points) or worst, penalize the team for not delivering the work within the estimated time. And please don’t get me started on how this does not make for a good engineering metric (let’s leave this for another post).
This is not productive and certainly not going to empower your team to deliver faster or hold themselves to a high standard for quality.
Why is estimation so hard?
There is a world where estimation is close to consistent and accurate. This is more plausible when you have a team of highly experienced engineers on the project, company and the ins-and-outs of the codebase. It could take years to gain this level of expertise.
Asking engineers who are not as intimately familiar with the project to estimate the work ahead of doing it rarely leads to much value and often misses the mark by a long shot.
So what should you do instead of estimation?
Spend less time estimating and debating. Spend more time understanding the problem you are trying to solve as a team and how you would approach solving this problem in the first 1 or 2 iterations.
You see, unlike estimation which often happens before the team had a chance to dive in and understand the work, iterations allow the engineers to get hands on with the work and attempt to complete 1 deliverable of value within the shortest amount of time. This constraint brings clarity and encourages the team to get a deeper understanding of the complexity of the work.
Definition of an Iteration: An iteration is a small vertical slice of a deliverable which brings some value (within a constraint scope) to the user. It includes all necessary elements to ship this deliverable to production (tests, documentation, instrumentation, etc). This is an important distinction because it allows you to iterate on a small deliverable yet keep the bar high for what goes into production.
An iteration is different from a spike. A spike is typically a prototype or an investigation to understand the level of complexity of the wok needed. It’s a great tool to leverage when you have a lot of unknowns especially on the technical side. Spike deliverables do not go into production as they are meant for discovery and to allow the team to identify a good technical path forward.
A few other quick notes on estimation:
There is value in t-shirt sizing if you prefer to replace your point estimates with another framework. Be cautious though, if the team estimates work to be M or L, it usually means there are a number of unknowns and things they still need to figure out. Help them break down the work into iterations or milestones so they can get more familiar with the ask.
Estimation can be a valuable 'do I want it for this much’ type of discussion with your product manager. If an ask will cost 2 months to implement, does your PM still want it for that level of investment? Is there something simpler the team can deliver instead. Encourage the team to iterate with a smaller deliverable to get user feedback quickly which can help you decide how much further to invest. This is another win if you practice delivering in iterations.