Why negotiating your team estimates doesn't make sense?

[Björn Brynjar Jónsson]

Pushing for a lower estimate is like negotiating better weather with the meteorologist! The meteorologist doesn't control the weather, so the negotiation doesn't make sense.

Yet it is fairly common practice external stakeholders push teams for a lower estimate, saying something like, 'No, it's less effort than that!'

Let's cover when this question is valid and when it is not. And how to move the discussion towards a more productive conversation.

I would love to get your feedback to improve my thinking on the topic!

'No, it's less effort than that!'

There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.

Often stakeholders outside of 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!'. Their purpose is to push the team to give a 'better' estimate. Note that 'better' in this case means a lower estimate. The problem with going down this path and taking part in these discussions is 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 are from the article Is tasking developers with creating detailed estimates a waste of money?

When is pushing for a lower estimate valid when is it not?

Statements pushing for a lower estimate are often valid, especially when discussing a story with a colleague in your team and when it's backed up with facts.

However, if the stakeholder making this claim is not part of the development team and doesn't know what needs to happen when implementing the story. Furthermore, if no new information is shared impacting the effort, then making this claim is like starting a conversation with a meteorologist saying:

Hey meteorologist, the weather forecast for tomorrow will not be this bad!

Let's cover why this is so and how to move the discussion forward!

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 observes the latest data to forecast the weather.

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 observes the latest 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. Not a recommended practice, as often teams pay more later when using this strategy. Also, the team has ways to improve the velocity. However, teams need to base estimates on their current throughput and not expected future throughput when giving an estimate. In other words, the team has minimal control over its effort (in the short term) 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 the meteorologist it isn't going to be this bad weather tomorrow?

Because negotiating an estimate is like negotiating better weather with the meteorologist. It doesn't make any sense. However, there is a better discussion to have.

The discussion to have instead!

Building software is complicated often takes more time than people think, and therefore, stakeholders often expect lower effort and can't rationalize spending more than a specific amount. What then?

In these cases, discuss with your stakeholders:
1. why the estimated effort is this much?
2. what part of the story takes the most time?
3. where are the biggest unknowns?

In addition, discuss ways to:
1. slice up the story and deliver it in multiple parts
2. validate each part early, preferably using prototypes

In addition, find ways to leave parts of the story out, especially the features that require lots of effort and have the least value.

This approach makes sense because research shows that a large part of software functionality built is rarely used. Therefore, it's critical to "get out of the building" and talk to the actual users using the software. Because it's often the case, stakeholders base their thoughts on opinions rather than actual data or discussions with users. As Steve Blank (who taught Eric Ries all about Customer Development) often says:

No facts exist inside the building, only opinions

This post was originally published on Smart Guess - Blog.

About the author Björn Brynjar Jónsson