Someone saying 'No, it's less effort than that!'?

'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?

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.

Does pushing for lower estimates make sense?

No, it's less effort than that

Statements pushing for a lower estimate can be 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 and doesn't bring any new facts, 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 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 is using 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. 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 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 you need 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 often says:

No facts exist inside the building, only opinions