Provide certainty to stakeholders, not estimates
Guessing is a quick fix that always backfires
Since my first roadmap planning there was always something off about these meetings. Despite the effort and brainpower that went into all the estimation and detailed requirements gathering, no one ever left these meetings with a higher degree of certainty.
If anything, the teams I lead got really good at playing an intricate game of cat and mouse. Once everyone accepted that their estimates shaped the deadlines everyone started gaming these metrics and the team became competitive on who could create the best ideal illusion. Experienced devs bloated the estimates boasting their vast experience and ability to find complex problems to solve; while the more junior hires received praised for giving optimistic, short estimates. I am certain you do not require a lot of imagination to picture what I’m talking about.
I spent the last few years coaching CTOs, engineering and product managers to figure out what fuelled this cat and mouse game. It’s interesting how easy non-technical stakeholders are to get on your side once you share your influence and give them your ear.
Here’s what I found that worked well and how you can adopt it.
“Estimation is just a fancy word for guessing.”—Dave Farley, Continuous Delivery
Estimation vs Configuration
Semantic Diffusion is a clever distortion in our industry. Not everyone agrees with what microservice, DevOps or continuous integration means. In that same vein we can all agree that we never agree on what an estimate is.
Can I use it as a deadline?
Is it relative in size? (poker planning, T-shirt size)
Can I make marketing decisions based off of it?
Can I assume it is 100% clear?
If you give me a range, can I use the mean value?
Is the sum of several estimates more accurate or less? (hint: it’s LESS)
This is all very unintuitive. It just happens to be guess-work on top of a complex soup of intuition and statistics. Unfortunately, neither engineers nor stakeholders are very good at communicating and understanding this information.
Let’s took at the root cause first: mistaking Estimation for Configuration.
👆This is an estimate
An estimate has quantifiable metrics and easy to understand boundaries. The boundaries are knowable and linear. They communicate progress. The measurements are absolute, ie. 150m2. They answer questions like How much? How long? How often? How many?
Some estimates may have an error range (depicted as 1500-1800 above).
Asking a house painter you for a quote will be based on the estimate of work that they produce based on square meters of painting surface (or just rough shape). The activity is commoditised and scales linearly with surface area.
What’s not obvious is that this is pre-scoped. A painter knows that they can do a job below 1,000 square meters, but 10,000 or 100,000 to be painted is their no-go zone.
The no-go zone of work, described by the upper limit of “acceptable” is controlled by the painter.
The buyer controls a no-go zone of budget. These are different. And the estimate does not speak of the latter, only its downstream consequences.
Let’s recap:
Knowable, quantifiable boundaries
Absolute measurements, but may have error range
Linear progression
Answers How much, how long, how often, how many?
May have an upper bound for no-go (ie. a budget or scale)
👆This is a configuration
A configuration is one of many options to solve a problem. Sometimes the number of options is infinite. It gives us a cost-benefit analysis. Measurements are in relative terms to other options.
The outcome of all alternative options is not knowable. Usually trying only one (at a time). There may be more than one moving piece in the configuration (components). This creates decision trees.
Playing a game of chess, you have many options. Each potential move opens up and closes others. As the number of steps into the future increases the space of possible moves grows exponentially.
Exponential curves are hard to imagine. You’ll be shocked to learn that the number of paths to victory on most chess openings is greater than the number of atoms in the known universe. How can this be? The Wheat and chessboard problem is a great simple mental exercise to get you warmed up on exponential curves.
Build a new home and hire an architect to create the best floor plan. It’s not a math problem—one of the first question they will ask is “What does best mean for you?”
The analysis and planning phase is often time-consuming. Objective constraints are necessary to rein in the number of options being explored.
Configurations of such nature make most measurements subjective and prone to error. Not that this is not a measurement error. It’s simply wrong caused by human bias.
Progress is measured and knowable only by full completion. Progress on unfinished work is speculative. Ask for progress you may get two types of answers:
Absolute answers on the done components
Guessing on the unfinished components
Let’s recap:
Unbounded, many options, pick one (at first)
Number of options grows exponentially with components and choices
Subjectively constrained to limit number of considered options
Measurements are binary (done/not done), but per component
Answers “What’s next? What is best?”
Progress on finished components is definitive
Progress on unfinished components is speculative
The stress kicks in on certainty and progress
Certainty: “When will it be done?”
Progress: “How will we measure progress / know that we are done?”
Take a deep breath. I can hear your shoulders hunching over just by imagining the last meeting that went like that. But inevitably we arrive here.
Why?
Because business stakeholders value certainty more than cost. They will pay to have more certainty. They may not pay more to give you more time. This is an important lesson I learned only a decade into my tech career when I went solo into coaching and focused my attention on sales and product for a while.
In other words, certainty is a guarantee of outcome. That’s the expensive stuff. Not quality. Not tests. Not good estimates. Guarantee of outcome. That’s the conversation every stakeholder wants to have.
Stakeholders start this conversation by asking the two questions above.
Now picture how most engineers and managers respond.
Do they give guarantees of outcome?
Do they give certainties and risk factors?
Or do they estimate?
How do you respond?
Often they are responding out of fear of over-spending or focusing on the wrong thing. They ask for estimates and invest enormous piles of cash into guessing per-work-task progress and size.
However, what will truly serve stakeholders is tangible proof of done increments on configurations. And they don’t know how to articulate this.
Agile at its core principles focuses on limiting explored options and exploring The next thing. Not with fake progress, but with incremental done components than remove the need for guess-work.
Here’s how it goes
Pick constraints and requirements
Choose a few options
Pick the first component that shows promise towards the goal
When done, reconsider your options from your current position. Like a chess game.
You build a house room by room, exploring as you go. Of course, you wouldn’t build a physical house like this. It is tangible, slow-to-create and key decisions are irreversible in the near future. But software isn’t.
Software is chaotic and unbounded. Riddled with uncertainties.
Estimates pile on more uncertainties on top of the existing ones. An estimate is intangible.
Proof of progress by exploring configurations provides certainty and tangible progress.
So next time you have a large long-term planning session, get the details on Why? and What? right. Get agreement on the impact on your value and revenue streams. Then decide What’s next. That next thing should be done in a matter of days. If it’s not, you don’t understand the What and Why. Go back to step one. If it’s done. Re-asses the plan and continue.
Congratulations, you are now agile.
Warning: This last paragraph may take years to get right. Don’t rush it. Don’t give up. Get it right.
Budget and Deadlines are a Constraint
Estimates: Constraints help you evaluate the no-go zone.
Configurations: Constraints help you rein in the possible options.
The most common disaster scenario with estimates I’ve witnessed goes something like this (based on a real project from my own experience):
Stakeholders want project X
Stakeholders describe project X to you. They have a gut feeling it would be great to have within 5 months. It may provide a huge opportunity to land a client or new users.
Stakeholders ask for estimates
They want to know whether their 5 month gut feeling was realistic. This is a go/no-go conversation. You humm and haww and decide it’s best to bring it to the team and have it be crowd-estimated. Investment starts already with planning. You produce is a rough plan on what can be achieved in 5 months, bonus points if you can include how long “all of project X” would take.
Stakeholders negotiate
This all seems reasonable and certain, but takes too long. Some minor features seem unreasonably complex. Ultimately the plan gets cut somewhat and budget gets approved. Deadline is set to 6 months.
Development starts
I won’t bore you with the gory details. Suffice to say stakeholders want a status update 2 months in. Everyone is comparing progress to the original planned estimates, but those are now obsolete as new problems and challenges pop up. When things are behind schedule, progress is being speculated by coming up with new estimates for things not in the original plan. New work that bypasses budget approval. What were the outcome guarantees again?
You renegotiate scope and budget
Ultimately, the project evolves and priorities change, needing a change in budget. 6 months in maybe you made it maybe you didn’t. Safe to say the original plan for Project X is very far from the deliverables. Further conversations focus on whether to continue this project or focus on something else. Project Y is waiting in the pipeline.
You repeat this cycle and put Project X on the backburner. Project X goes to market and doesn’t produce desired effect. Ultimately, it takes years of maintenance and support to make it profitable.
What went wrong?
The entire budget was spent
Work was invested in estimation without giving guarantees
Budgets were forcefully expanded without proof of market success
The scope changed without renegotiating go/no-go or market demand
Progress was speculative and uncertain
The project was abandoned when feedback from users started coming in
The team was busy when the feedback arrived
Stakeholders hate this.
When you renegotiate scope under budget or deadline pressure—driving more estimation meetings and heated debates—you communicate that you value spending the entire budget effectively more than delivering the right product sooner.
What can be done better?
Defer commitment: Do not commit to Project X until you have proof of market success. Extract the most meaningful next step and start on that. Re-negotiate go/no-go with each increment. This provides stakeholders the opportunity to cut the project without spending the entire budget.
Use deadlines and budget as constraints for configurations: When asked for estimates, come up with configurations instead. Create an event model and show a few combinations of slices that may be launched together. This provides go-to-market options with a scarce and rough set of features.
Create knowledge and beta test: Get to market to a limited number of users without spending the budget. Get user feedback during the development process. Ideally weekly, not later than 1/4th into the deadline. Do not invest into software development without proof of market demand. You create an MVP or prototype to create demand, not to prove you can build it. Nobody can build it at first. But you will learn how if there is demand. This equation doesn’t work the other way around.
Act on the feedback: Rather than committing to the initial plan for Project X, create incentives to adjust course based on feedback. Feedback can come from anywhere—metrics, surveys, interviews, customer support, internal sessions, qualitative analysis, gut feeling. Do not act on lack of data. Lack of data doesn’t mean NO. It means you aren’t asking the right questions or the right people.
Establish processes that guarantee fast delivery and lead time on DONE work: Done work should not marinade in your project repository. Unfinished work should not survive long. Make sure that 5% done also means that 5% is deployable and useable. If partial increments are not deployable you are working on the wrong component or configuration.
Work backwards: Incremental, iterative work doesn’t mean no planning. You have a configuration after all. It tells you when the project is over. It tells you which critical components make the project end and a success. Start with those. The big, hard-to-setup valuable features first. If you don’t know which those are, do very small increments on a few until you figure it out (see beta testing and feedback). Do not commit until you have this information. Working backwards (ie. with an event model) allows you to focus on user-facing, tactile functionality first, even if it’s prototyped or rough around the edges.
I'm aware configuration may not have been the best terminology here. Do you know a better term for combining a plan together?