Bringing clarity on Estimate from a Commitment
The biggest challenge for Developers* in estimating Product Backlog Items (PBIs) remains in the aftermath of providing a relative estimate when the same numbers start haunting them back as a commitment to live up to.
You guessed it wrong if the challenge faced by Developers* was with providing a relative number (size) considering the complexity, the quantum of work & uncertainty.
Estimates are turned into commitments and that’s when every conversation gets nasty bundled with fear and fabrication. The word commitment usually relates to undertaking duties. Once committed to a bunch of Product Backlog Items (PBIs), the Developers* are left with not much choice other than obliging to deliver within the stipulated time.
Let us look at a practical example of weather forecasting. Assuming I commute 50 km one way to reach to work from my residence using a motorbike. I strongly lean on the weather forecast for understanding the weather and deciding alternates on a day forecasted with heavy showers.
The day with the weather predicted to have heavy showers, I start early and commute using public transport considering the additional time it takes. But what if the prediction fails at the end of the day and there is not as much rain as expected?
Can I sue the news channel that made the weather forecast influencing for my additional time and effort took in commuting? Absolutely not.
A forecast is a prediction made by experts with available information on hand. A forecast has to do with making assumptions based on reliable information and evidence.
Remember Empiricism? According to the philosophy behind Empiricism, there are no innate ideas or traditions from where we derive our knowledge rather from evidence in the form of ideas, experience, and information we have on hand at that juncture.
Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans.
When Developers’ forecast turns into a commitment, the Sprint Backlog turns out to be a Contract with a fixed time, cost, and scope enabling them to negotiate only on quality.
To prevent management and leaders to magically convert ‘forecasts’ to ‘commitment’, we Scrum Masters and Coaches need to create a lot of awareness and help facilitate conversations around these concepts.
Estimates are provided at a time when there are minimum insight and clarity about the piece of work to be undertaken.
Cone of uncertainty defined by Steve McConnel comes in handy to explain the challenge faced by software professionals when estimating Product Backlog Items.
Quick Tips to prevent estimates turn up to become commitments:
- Never make forecasts and come up with estimates for a longer time frame. The shorter the time frame, the lesser the challenge in remembering the abstractness behind estimates.
- Involve the entire Developers* in estimating Product Backlog Items.
- Call out the underlying assumptions made while drawing estimates explicitly.
- Provide a range and not an absolute number while estimating work. Let us explore forecasting work and Confidence Intervals in our subsequent article.
- Remember to inspect and adapt as a team with new information emerges.
Wrap up!
Commitments are not wrong but committing to individual Product Backlog Items and turning up estimates as commitments are where we get it wrong. When the Developers* agree for a commitment / encourage calling estimates as commitment, they are helping the business at the other end to start assuming the progress to be made and come up with early decisions based on such commitments.
It definitely gets worse in our complex domain when such a commitment is not fulfilled, the business may try to negate and make individuals part of such commitment liable for the promises made.
Remember, when a commitment is broken or not fulfilled, it is usual to expect some sort of accountability, fault, or even compensation.
At the same time, when a forecast doesn’t come true, it is easier to think about matters such as learning from the experience, improvement, and - in one word - empiricism, which at the end is what Scrum is about.
*Developers – The term ‘Development Team’ mentioned in Scrum Guide 2017 changed to ‘Developers’ since Nov 18th, 2020 with the recent Scrum Guide changes. Refer to the latest Scrum Guide here: https://www.scrumguides.org/scrum-guide.html