Estimation: When predictability is defined by the deadlines

"It doesn't matter, all this -estimating- effort is lost time, since they'll -Product Owners & Stakeholders- have to accommodate to the truth, and we'll have to do overtime to get there either way" - an anonymous developer

This phrase is something I've heard in my agile coach experience. Teams accepting the fact that externals do not understand how estimating should work, already abandoning all hope to make a change in the way stuff is done.
The first thing that waved in my mind as a warning flag, is the "Us vs Them" perception. Having sides, is a clear notice that we are not working towards the same goal, or under the same understanding of what "having the same" goal really means. It's my hope that with this short note, I can help as many Developers, Product Owners, Product Managers and Stakeholders to get to the same page once again.

How is it badly used

Take a look on some of the example situations I can think of top of my mind that you could be finding in your Teams-Managers-Stakeholder relation:

• Ask for an estimation of a long term project, hold everyone accountable on that.
• Ask for an estimation of a project, knowing beforehand that there's no negotiation point on the scope nor the deadlines.
• Optimistic with the undefined: People raise risks but can't measure the uncertainties, therefore they tend to be optimistic with their assessment, the risk "is not being raised enough" so it loses focus.
• "You regularly deliver this much, so less than this raises warning flags".

I hope I can clarify some of these in this short lecture so that you can handle them better next time.

What really is

• An estimate is precise, but not accurate.

If I say "My birthday is at some point in June", I'm being precise, although I'm not accurate on the exact date. When we ask professionals an estimate we're looking to reduce to the feasible range dates. Narrowing it as much as possible. But what we often tend to forget is that it still is a range. We need not to get accurate estimates, if those have a high probability to be wrong.

In this case S or M would depend on how the risks might impact,  M would be to play safe, and be precise.

• If you work with a fixed deadline:

As POs we should prioritize, and with those ranges in mind, be transparent with what can be achieved on a best case and worst case scenario, declaring beforehand what we won't have for sure, and negotiate having the "at risk" range in the middle already shown.

• If you work with a fixed scope instead:

As POs we should share that the best and the worst case scenario ranges will be handled in delivery dates, and the negotiation will be on those. you'll be have a best case scenario in which we could have everything delivered immediately after that, and the far date in a worst case that by then for sure we'll have everything.

• An estimate is relative.

Estimates are usually taken in relative sizing, and that is to get a common language within the dev teammates. They let people with different skillsets use the same unit.
Why not just use working hours? Everyone knows the size of an hour, right? Well yes, but not all size a particular work in the same amount of hours.

• An estimate is a mix of complexity, repetition and risk.

First we need to analyze complexity and repetition: Something complex is how difficult is to have this done. Something with high repetition and low complexity could take you a long time but it has almost no risk to get there as planned.
Let's say we have a team of two made of a neurosurgeon and a 7 year kid, with two tasks: performing a "standard" brain surgery and lick one thousand stamps, the team could agree that both stories have a relative estimate of 8 points, the complexity and repetition of each one are dissimilar. And where do I place the higher risk? That should be shown in width of the range when more risks are present more width you'll find between best and worst case scenario.

• An estimate may change as we add more knowledge.

Plans are worthless but planning is everything. An original estimate presented at the starting point of a project, will for sure evolve as we keep adding more info to our knowledge base. And everyone should be prepared to quickly adapt to this newly added information.

It's unrealistic to expect to finish something at the estimated time, when the estimation is being done at the beginning of the project.

• An estimate is a communication that should be alive in an agile context.

Talking about newly added info, it's important to keep the communication channels open. It's not uncommon to see organizations where the communication gets tampered at some mid point due to the political impact of communicating delays. Or cases when the main objectives slightly change, but we forget to communicate the new objectives to the devs. This communication aspects should be transparent with the whole program team, and remove all intermediaries as much as possible. Let the team be self organized in the communications sent and received as well.

Estimating for iterations.

We've seen how to use the estimates on a long term goal, now let's analyze what happens on regular intervals.
On an iteration analysis, the estimates are used to define the capacity in story points that each team can take. Now regularly, we fall in the pit of saying "this is the number we've been doing, so we need to get this same much". Now this is another partial truth, because it's always good additional info to consider but under no circumstance we should work towards aiming for a certain number.
You should aim for as much as you feel confident you can commit to. You might (and will) receive a challenge on the final iteration estimate, if it differs from the regular one, and sometimes those challenges will prove to be healthy, since it'll get the team to reconsider previous analysis that they did. The team needs to be able to explain why they have those changes. Again, transparent communication and openness are some of the root values.

My personal experience

Something I did to work on this situation, was to attack what I thought is the root of the problem: have them looking towards the same goal: I started generating the insight within the developers to communicate in a more valuable way, by making powerful questions: "Are you on track with what you originally estimated?" "Do you know when is the deadline and what needs to be delivered?". Now the powerful questions for the Product owners and managers are different: "Do you trust the teams to have clear the path you have planned for the product and the deadlines we have?". With that I triggered the thoughts that generates their awareness, and ignited the will to action from those who are most fit to do it.

Wrapping up

Going back to our original phrase, estimation is only lost time if being predictable does not make sense for you. Sure, when the actual daily trenches fight happens, the estimates could have important deviations from the originals; but a continuous, open, and flowing communication is key to define if the now updated path we are moving forward together, is the best one at a daily, tactical and strategy level. It's better if we all can accommodate to the truth as fast as we can, to take the best decisions as a single team, with a single vision.
And on overtime: overtime is a tool that if considered standard work model on a regular pace, might be evidence that you have a greater problem in the way the work is being organized. I encourage you to ask your team(s) for a root cause analysis retrospective on what this situation is popping up at a regular pace. One thing that happened to me in this regard is that I ended up finding out that the company was pushing for a fixed scope and fixed time, which goes against the agile perspective, but that's another story which hopefully I'll address in one of my next entries.