No, It’s Less Effort Than That! Why Challenging Estimates Will Backfire
There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.
Often, stakeholders outside the development team, with limited technical know-how or insights into the codebase, question team estimates, saying something like 'No, it's less effort than that!'. They aim to push the team to give a 'better' estimate, where 'better' means a lower estimate. Stakeholders and Development teams who participate in these discussions, assuming estimates can be negotiated, are going down a path of diminished trust and further issues down the line:
Finally, an agreed-upon estimate is provided with much grumbling. Most of the time, nobody is happy; everybody feels compromised. The most important stakeholder, the business, is especially compromised as a bad expectation was set on when the software will be delivered to the customer.
Both quotes above are from the article Is tasking developers with creating detailed estimates a waste of money?
In this post, I will share how it's a mistake for external stakeholders to push for a lower estimate without new facts impacting the effort. In addition, I will share how development teams can move their stakeholder dialogue into a much more productive discussion.
Challenging Estimates Without Facts? Here’s Why It’s a Problem
No, it's less effort than that!
Challenging an estimate can be valid, especially when discussing a story within the development team and when backed by facts.
However, when a stakeholder outside the development team pushes for a lower estimate—without understanding the implementation details or providing new information—it’s like telling a meteorologist:
Your weather forecast for tomorrow is wrong. It will be much better—I just know.
Let's cover why this is and how to handle these situations effectively.
Pushing for a lower estimate is like negotiating better weather with the meteorologist!
The fact is the meteorologist doesn't control the weather. The meteorologist uses his knowledge and observing data to forecast how the weather will be.
In the same way, the development team doesn't control the actual effort - only by a tiny part. The development team uses their knowledge and data to forecast expected effort. They use established team velocity, review data on complete stories, and continuously improve their process every sprint.
What do I mean by saying only by a tiny part? The team can skip parts of their process and deliver lower-quality software. It's not a recommended practice, as teams often pay more later when using this strategy. Also, the team has ways to improve their velocity. However, when giving an estimate, teams need to base estimates on their current throughput rather than expected future throughput.
Someone might tell your team, "Well, you just need to put in longer hours!" If this is the dialog in your company, consider finding another place to work. Why? Because it is a recipe for disaster working in an environment like that, as can be seen from these experiences:
- but then my scrum master and my manager want an x pointed story done within y number of days
- I work for a consultancy. My managers are paid to not understand this
- I work in an agency and I'm about to be fired because of this
In other words, the team has minimal control over its effort to implement a fixed set of functionality.
Next time, when someone starts a conversation about your team's estimate, pushing for a lower estimate without any new insights that will lower the effort, ask them:
Do you ever tell a meteorologist: "Your forecast for tomorrow is wrong, I can't bring this back to my people, give me a better one!"
This line of thinking doesn't make any sense, and yes, there is a better discussion you need to have.
The discussion you need to have instead
Building software is complicated and often takes more time than people think. Therefore, stakeholders often expect lower effort and can only rationalize spending a specific amount. What then?
In these cases, discuss with your stakeholders:
- How much can you spend on this story?
- Discuss what part of the story takes the most time.
- Discuss where are the biggest unknowns
- Discuss alternative ways to address #2 and #3
In addition, discuss ways to:
- slice up the story and deliver it in multiple parts
- validate each part early, preferably using prototypes
Find ways to leave parts of the story out, especially the features that require lots of effort and have the least value.
In our next post we will cover how to answer questions such as:
- When can you deliver feature A?
- What can you deliver before the end of next quarter?
- Can we get feature A delivered before the end of next quarter?
About Smart Guess
We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.
Like, retweet, or share your thoughts on Twitter about this topic.
