Are Estimates Ever Helpful to Developers?
We know that stakeholders and clients want estimates.
They benefit from being able to plan, prioritize, and predict the dates their product will be delivered.
But for a developer, the benefits are less clear. In fact, it can feel like there is no benefit at all if estimates are interpreted as a promise and then constantly used against you.
So it’s no surprise that developers are often reluctant to estimate. If doing something always seems to cause you trouble, why keep doing it? Isn’t that the definition of insanity?
I understand and sympathize with this way of thinking, but the truth is that estimates can benefit teams. In fact, over time they can elevate your status in the eyes of stakeholders and give you more bargaining power than you might realize.
But how?
My Experience of Being Held Accountable to Estimates
My background is very much as a hardcore programmer, first in C, then C++, then Java. When I began programming, being asked to estimate made me nervous because I knew every estimate I ever gave could possibly be used against me.
Not only that, but we were rarely celebrated for achieving an estimate. There were no rewards or bonuses if I finished coding something within my estimate. I’d merely done what I’d said I’d do, fulfilled a basic expectation. No one really noticed.
But if I finished late? People noticed, and noticed enough so that sometimes I’d get yelled at.
This early experience stayed with me as I progressed into a management role. If managers were supposed to get mad at developers who finished late, that’s what I’d do. This was the only management style I’d seen at the time. It didn’t feel right, but it was all I knew.
I quickly learned that holding team members accountable for bad estimates didn’t work.
The developers working for me were—just as I had been—chronically optimistic, and would tend to under-estimate the amount of time it would take to complete something.
As a new manager, I thought that if I held the team to their overly optimistic estimates, they might not make them—but they’d be close. We’d finish projects faster than my boss and stakeholders expected. And I’d look good as a new manager.
Predictably, that didn’t work out. When I pushed the team to reach these estimates, they soon realized there were consequences of estimating too low—they’d have to work overtime or cut corners to meet the deadline. That wasn’t a fun way to work and so they learned to pad their estimates as a way to make the pace more sustainable.
It was tense, dishonesty was becoming entrenched, and I knew then I needed a better approach.
A Valuable Incentive for Teams to Estimate: Bargaining Power
As I mentioned at the start of this post, the benefits of estimating seem to be stacked in favor of stakeholders. I wanted to encourage my team to want to estimate instead of seeing it as an arbitrary exercise that could only get them into trouble.
By then I was managing multiple teams. Naturally some teams were better at estimating than others.
And I noticed something very interesting: The teams who had given better estimates on their past few projects had better relationships with their stakeholders. Stakeholders listened when those teams said that meeting a deadline was impossible.
What Happens When a Team Is Bad at Estimating (or Refuses to Try)
Imagine a team that refuses to estimate—they have no history of delivering on their estimates. Or imagine a team that is terrible at estimating—they have a poor track record of delivering on what they say is possible.
Their boss comes to the team, outlines a set of functionality and asks the team how long it will take, hinting that it really needs to be delivered in six months if possible.
The team estimates the work and decides that it’s going to take much longer than six months. Team members explain they need more resources, more time, or can deliver in six months with fewer features. But all that functionality in six months? Just not possible.
The boss’s likely response in a situation like this? “Let’s just do it in six months.”
Now, before we decide this boss is a jerk, remember this team either has no history of estimating, or a history of poor estimating.
The team hasn’t earned the right to be heeded when they say the deadline is impossible.
The boss in this case is likely to view the team’s resistance as something to overcome rather than an informed opinion based on facts.
A Good (Not Perfect) Estimating History Elevates Your Status
Now let’s contrast this situation with one in which the team estimates and estimates well. I don’t want to cheat and say the team estimates perfectly. They’re good, not perfect.
For example, on one past project they told the boss they could deliver in April or May, and they finished just before the end of May.
On another project, team members said it would take three months. And they delivered right on the deadline but did have to postpone a couple of fairly small product backlog items.
So, they aren’t perfect estimators, but they’re good.
And now the boss asks this team if they can deliver a certain amount of functionality in six months. This team estimates the work, considers it, and team members ultimately tell the boss that it’s too much. It can’t be done and realistically they’d need eight or nine months.
Does the boss tell this team to do it anyway as with the first team?
No. This team has provided credible estimates in the past, so the boss pays attention when they say it can’t be done. The boss will even treat the team as equal partners in solving their shared problem of what to do, given that the desired deadline is impossible.
The boss and team will likely discuss ways to solve their shared problem. Perhaps more people can be added to the team. Or an entire second team could be added. Perhaps one or two requirements have an outsized impact on the schedule. Perhaps it’s not a problem to release the full functionality a month late as long as certain features are delivered on time.
A Healthy, Respectful Relationship
This team’s history of providing good estimates leads to a healthy relationship with the boss that is based on mutual respect and trust. This allows the boss and team to explore options as equals.
It might be hard to imagine the benefits that are waiting for you if you can build a solid history of successful estimating, but they are there. Don’t get me wrong: this type of relationship isn’t built overnight, but I can guarantee it won’t be built at all if a team refuses to estimate.
What Other Benefits Are There for Developers?
What do you think? Are there more benefits for developers if they build a credible estimating track record? Or are stakeholders the only ones who benefit? Have you tried a new approach to overcome team resistance to estimating? Let me know in the comments.
