The first consists of all the people complaining "the Dev estimate on this work is far too high!"
The second consists of all the people complaining "Dev have taken far longer than they estimated!"
It is not unknown for members of the first queue, having had their query swatted away, to immediately join the second queue, or vice versa, without a hint of irony.
Let's address the first one here. Why might someone think an estimate is too high? Conversely, why might a Dev team give an estimate that others consider "high"?
- You don't agree on the scope - estimation is often done off the back of a ticket in a workflow system that has little detail on it. Even if the Dev team engage the product owner in a conversation when estimating (and you do, right?), there are often lots of implicit assumptions made by both sides, not least the assumption that the "other side" are making the same assumptions. In the absence of knowing the right questions to ask, it's natural for developers to err on the side of caution and fill in the gaps with their own assumptions about what's needed. There's a simple solution to this: keep talking. Find out from the Dev team what assumptions they've made, or what tasks they're planning, and help them turn them into concrete things.
- The team doesn't know the domain - perhaps they've been asked to take over a system they haven't worked on before. It is unrealistic to expect a team that's never worked on something to make changes to it at the same rate as a team that may have built it from scratch. Don't be surprised if it takes 2 or even 3 times longer. Developing software is not like following a recipe. Either quit moving systems between teams, or consider the initial effort an investment to make things quicker next time.
- The system has technical debt - Whisper it quietly, but sometimes software is not that well written. Or at least, once upon a time it was, but over time things have gotten a little messy. Perhaps the Dev team have been less than careful about the changes they made. Perhaps they did it to get the work done quicker and make your estimates smaller last time. Either way, now you're paying the price, and the price is more effort, which means a higher estimate. It is the righteous and courageous Dev team that says "no, we're fixing this now, not later". If my builder didn't do that, I'd probably be writing to Watchdog.
- You think you know something the team doesn't - And so we come to the most common cause for "that estimate is too high!". It's just a one-liner, right?
- You actually do know something the team doesn't - If you do, congratulations! Share it with the Dev team. Share your experience or your knowledge, or connect them with other people who have it. The Dev team will almost certainly be thankful for the input. However, just telling them what you know doesn't necessarily mean that right now they can do it as quick as they will be able to once they've got experience for themselves.
- The team know something you don't - Yes, it's a one-liner. At least, it is once we've refactored the code into the right shape. And written the unit test. And functional test. And integration test. And tested it across all browsers. And deployed it. And listened to your feedback about how it's slightly the wrong shade of blue and needs to blink. And attended the meeting with the customer to explain to them how to use the new feature.
There is a third queue at my desk. It's the people complaining "the Dev team have done the work far quicker than they estimated!". It's currently empty. Feel free to join it sometime.
