Release Cadence is a Stronger Predictor than Estimates
Engineering Managers, Tech Leads—Learn how much your team can do in a day
Topics for today:
Why estimates don’t produce good forecasts? Engineers don’t spend time as they do money. Instead—an environment where their availability is always matched with demand—they estimate buying power. This leads to vast overconfidence.
Angst of re-planning when reality doesn’t meet estimates. It’s one thing to be optimistic and avoid panicking when things don’t go according to plan. It’s entirely another to ignore signs that signal the situation isn’t well. I have observed and coached teams that do the latter much more than the former.
Reason over anxiety: forecasting based on measurements. The science of the ideal solution to this problem is a solved problem. It ranges back to the 1970’s! So if we supposedly know all this… why aren’t all teams in the industry simply applying it?
Why estimates don’t produce good forecasts?
Engineers don’t spend time as they do money. Instead—in an environment where their availability is always matched with demand—they estimate buying power. This leads to vast overconfidence.
Imagine a software development project. A new feature within a tight deadline. You tasked your team to come up with estimations. They determined that it would take two weeks to complete, based on previous similar projects and the team's capabilities.
However, as the team begins working on the project, they encounter unforeseen technical challenges that significantly delayed their progress. The estimated two-week timeline proves unrealistic, leading to frustration and stress among team members.
…
sigh
…
We’ve all been there, right?
Estimates are subject to limitations. The initial estimate was based on assumptions and historical data, but it failed to account for the unique nuance of this feature. After-all, you aren’t producing the exact same feature all the time.
“But that’s silly!”, you might say. “If nothing is predictable then why are all sprints exactly the same level of slow?
The answer is simple: because you and your team are resisting learning the lessons presented to you.
Angst of re-planning when reality doesn’t meet estimates.
It’s one thing to be optimistic and avoid panicking when things don’t go according to plan. It’s entirely another to ignore signs that signal the situation isn’t well. I have observed and coached teams that do the latter much more than the former.
Surprises lead to unmet expectations. Re-planning leads to frustration.
Frustration is a key factor for the brain’s neuroplasticity. In order for your brain cells to do their work, your body has to go through a complex process of filtering and combating conflicting information. You are essentially re-indexing when given new insights and a-ha moments.
You feel this as frustration. And you’ll do everything possible to avoid it if you think there is nothing for you to learn. And so will your team. As well as your stakeholders and the business owners.
Relax, this is human—we all do this. But we don’t have succumb to it.
Commodity processes like replicating and manufacturing a car requires a fast production line and reliable supply chains.
Creative work like software requires quick feedback loops of information and learning. How quick? Hours. Today.
Quick feedback loops are the key behind Lean software development. And agile.
You can read more on it on Google’s Cloud Architecture Centre.
Reason over anxiety: forecasting based on measurements.
The science of the ideal solution to this problem is a solved problem. It ranges back to the 1970’s! So if we supposedly know all this… why aren’t all teams in the industry simply applying it?
There are three orthogonal, unrelated goals here:
Trust—Improve the accuracy of forecasts to match delivery
Improvement—Make delivery faster where possible (and ensure it doesn’t slow over time)
Learning—Reduce the number of iterations needed to figure out what is valuable (ie. how often you get-it-wrong and how long your learning cycle is)
You may notice that none of the above values have to do with fear or anxiety. Those are not core inputs into this equation.
It is in fact the opposite! Fear and anxiety are the output of your process when you clog it with resistance to change in times of challenge and adversity.
A team that is providing a profit centre to the business is directly improving business metrics, not process metrics. Exclusive focus on process metrics like velocity will lead you down a rabbit-hole of optimising a slow-paced feature factory.
Measure what your team can accomplish in a day
Most teams I coach get planning poker wrong. It isn’t about some convoluted fibonacci joke. The point of planning poker is that the team agrees on what ONE means:
How much work and value can the team deliver collectively in a day.
Deliver means following definition of done.
Value is separate from work—because misses have to be re-worked.
The team’s unanimous agreement is step one to any good forecasting. The number doesn’t matter. You can call it 100 or 10 or Bob. What matters is that it isn’t individual and nothing to do with hours.
Don’t sugarcoat weird, off-weeks. Look at the current week and assume that’s how it’s going to be. Don’t make excuses for “oh but we had that emergency.” There will always be emergencies. And don’t weasel it into perfectly shaped sprints or kan-kans.
This is not a strict measurement. It is about intuition. The learning here isn’t a number that predicts how many hours in their workday are effective. The a-ha moment is realising how little time and attention your team has in a day to produce something valuable.
That’s how you nurture a high-performing team. Be direct and honest about your limitations, then communicate them candidly to stakeholders. Equate the pressure and cut scope. Scope can always be cut.