We asked three programmers to share their takes on effort estimates. Reddit Senior Director of Engineering KD Bhulani said each developer on his team starts projects with what he called a “scientific, wild-ass guess.”
SquareFoot CTO Joshua Vickery said traditional estimates provide the bad package deal of “poor predictability” and a “false sense of confidence,” which “is worse than not knowing.”
Kent Beck, whose extreme programming paradigm changed the way many programmers approach estimates, is over the whole thing.
“I choose not to play that game,” he said. “But I’m working from a position of considerable privilege. I can just say: ‘Yeah, piss off. I can’t tell you, so I won’t.’”
The Bad Habit We Can’t Quite Shake
And there you have it.
The arithmetic estimation approaches of yore have given way to #NoEstimates, a charge spearheaded by programmer Woody Zuill that is exactly what it sounds like, and general estimation malaise. Check “software development effort estimation” on Wikipedia and find an entire section dedicated to disparaging jokes, like this one from Fred Brooks: “What one programmer can do in one month, two programmers can do in two months.”
What is it about software that makes estimates so impossible?
First, Vickery told me, it’s not a software-specific problem: “If you ask someone when their kitchen renovation is going to be done, the common answer is that it’s twice as long as the contractor says, right?”
“You don’t have to estimate. You just have to not die.”
Second, estimating isn’t impossible, Beck said. It’s just usually inappropriate. His “explore, expand, extract” theory describes companies in three different stages of growth. For established, successful companies in the “extract” stage, estimating makes sense because they’ve likely completed similar projects before. For companies that are exploring or expanding, estimates don’t provide value, because they’re not based on any real experience.
“You don’t have to estimate. You just have to not die,” Beck said.
But, as he acknowledged, the “piss off” response isn’t an option for everyone. In most workplaces, estimates come with the job, and developers don’t get to opt out entirely.
Often, there’s a good reason managers or colleagues want an estimate — maybe the company’s hiring plans rely on it, or there are dependencies with other projects. Other times, there’s a bad reason — like the desire to boost productivity at any cost or grab interdepartmental control by manipulating timelines.
Either way, estimating is here to stay (for now). But that doesn’t mean it has to run the show. Let’s survey what can go wrong when estimates are used inappropriately. Then, we’ll take a look at a better, middle path.
Symptoms of Wrongheaded Estimating
Beck hasn’t kept up with evolving debates around estimates.
“It’s such a divisive topic, and I just don’t think it’s terribly important,” he said.
Just because someone demands a date or a dollar number doesn’t mean developers have to respond in kind, according to Beck. The estimation conversation contains a multitude of other considerations, like “Is this project worth doing?” and “How can this team demonstrate its value?” Those considerations often get masked by hand-wringing about timelines.
Here are some things that happen to teams that get sucked into estimate tunnel vision:
They Wait Too Long to Kill Bad Ideas
Like Vickery said, estimates give an illusion of certainty. Once something gets labeled a four-month project, the odds are good it will take four months.
But what if everyone on the team knows the project is a disaster after just one month?
Sometimes, estimates incentivize orgs to cling to ill-fated projects. A better way, Beck said, is to approach everything in increments, so projects can be tossed out or reworked at any time, no matter their scope.
“I don’t want a nine-month project. I want nine one-month projects,” he said. “And then if you tell me I have nine one-month projects, I’m going to say that each month is going to be four week-long projects, just because I always want that feedback loop.”
They Treat Estimates Like Currency
In his book, Death March, Ed Yourdon instructs developers on how to navigate software projects that are “doomed to fail.”
In a death-march dynamic, the project at hand is often attractive to leadership, but not a priority, Beck explained. To justify its execution, developers are pressured to give a condensed timeline. Then, the timeline often continues to shrink, until the team is burnt out and the work suffers.
That’s a misuse of estimates, according to Beck. You should use them to compare multiple projects with similar projected payoffs, not to boost the attractiveness of projects with insufficient buy-in.
“Even if you’re comparing two potentially profitable projects, I’m probably going to tell you to do a little bit of both of the projects, so then you’ll know a whole lot more about both projects and their relative value,” he said.
“Even if you’re comparing two potentially profitable projects, I’m probably going to tell you to do a little bit of both of the projects.”
So, bargaining with shortened timelines is no good — but the same goes for protracted timelines. A longer timeline may buy you more developers, but it doesn’t guarantee a more valuable project. That’s a misaligned incentive, Beck said, and one that won’t win any favor from shareholders at the end of the day.
Whether it’s overshooting or undershooting, treating estimates like currency to bargain with is a tempting mistake, especially for managers without the organizational cache to sidestep requests for estimates.
They Weaponize Estimates
Often, Vickery said, dysfunctional teams use estimates as “functions of control.”
“It may be that you want to expand your sphere of influence into another department by forcing them to stick to very strict estimates so that you can control what they’re doing, or it may be a productivity multiplier where you’re saying, ‘If we set unrealistic estimates, it will make people work harder,’” he said.
Other times, people simply prefer feeling like they know when things will be done, he added. But that leads to another problem:
They Waste Time
All that time developers spent refining their estimates? They could have been executing the project. Also, the estimates are wrong.
Beck’s favorite estimating advice? Take your initial guess, double the number, and increase the unit by one. So, if something looks like it will take eight hours, it will take 16 days.
Telling a colleague their six-month project could easily take 12 years won’t win you many friends, though. When someone asks for an estimate, a better tactic is to hold off answering until that answer is based on some actual project experience.
“I think answering that question with a number is a big mistake,” Beck said. “How about if we just go do the first month’s worth and see what we get out of it? Why don’t we do the first week’s worth and see if we get value out of it. We can validate most of what we expect to receive from the project and what we expect to spend.”
They Emphasize Output Over Outcomes
Estimates are about output — what gets built. Good software is about outcomes — measurable benefits for customers and stakeholders.
If developers are evaluated based on output, there’s an incentive to ship features, even if it’s clear halfway through the sprint that those features don’t provide value. The best way to avoid that, Beck said, is by evaluating developers using business health metrics like revenue or retention and letting them own projects end-to-end — but that can be tricky. Developers can control which features they write and how, but not whether sales or marketing does its part to boost revenue. That complexity can lead to dysfunction.
“But as a shareholder, I don’t care,” he said. “I don’t care what your job title is. If you can do something to improve the value as experienced by the customer or the company, I want you to do that thing. Whether it involves programming or not, not my problem.”
An Org-by-Org Approach
There are a lot of ways for estimating to go badly. But is there anything that works well?
According to Vickery, that depends on your mindset.
“There are essentially two ways to hit estimates consistently,” he said. “You either figure out exactly what you need to do, like by having done it before. Or you adjust what you’re doing to fit a time frame.”
At SquareFoot, developers take the second route. Each quarter starts with top-level planning by executives to identify a few areas where the company could make an impact. That information is passed down to various departments, where individuals pitch ideas they believe would best address the impact areas. Department leads work together to whittle down the pitches and formulate projects with specific time frames — each no longer than a quarter and no shorter than two weeks. Then, developers work in two-week sprints.
There are a few requirements for this method to work, Vickery said. First, “projects” should be goals, not detailed maps of what to execute. For example, “We want to roll out COVID-19 messaging through as much of our marketing materials web app as possible by next Tuesday.” No one knows what those materials will be or how they’ll be implemented, but the teams can be sure that next Tuesday, there will be something there to assess and build on.
Second, if a project exceeds its allotted time, its owners must reduce its scope and complexity.
“It’s not quite the same as estimating because we’re adjusting what we do in order to fit to the time period,” Vickery said. “But it does give you the predictability of saying that, at the end of that time period, you’re confident you will have some key things available.”
Vickery calls those key things “sprint promises.”
“If you’re an engineering manager, and your product manager says, ‘We really should deliver this entire feature this sprint,’ you’re going to say, ‘OK, we’ll try.’ Well, you’ve already admitted that you’re probably not going to do it,” he said. “It’s better to say, ‘I want to find something that has value that we can actually promise to get done by the end of the sprint.’”
“I want to find something that has value that we can actually promise to get done by the end of the sprint.”
If a sprint promise isn’t delivered, it’s actually a big deal, Vickery said. The team comes together to discuss what went wrong and what needs to change so the same mistake never happens again.
That doesn’t mean the approach is foolproof, though. Sometimes, projects ooze out of their time constraints, not because sprint promises aren’t met, but because they are met. New promises are identified, and the sprint cycle continues until a project manager notices the error.
Other times, even loosely defined goals are tough to deliver on. Once, Vickery told a stakeholder he couldn’t commit to finishing a project in six months, but he could deliver something to build on. Even that proved an overreach, and delivering the semi-functional solution required a “Herculean effort.”
Regardless, Vickery is happy with his organization’s take. Unlike traditional estimating, it focuses on outcomes and skips a lot of guesswork. But, like estimating, it promotes peace of mind by allowing for scalability and dependencies.
“I think once you [hit sprint promises] consistently, you gain a tremendous amount of credibility in an organization,” he said. “You have the power to say, ‘Yeah, that’s what we’re gonna do.’ And then you just do it, which is sort of uncommon in software.”
Don’t Keep Estimating the Same Way If It’s Not Creating Value
Vickery’s approach works for his team, but there’s no one-size-fits-all approach to estimates, Bhulani told me.
“I would love to know about a magic formula that works for everyone. But it’s important to remember that sizing projects is an art as well as an ever-evolving science,” he wrote.
There are some tried-and-true guideposts for teams that want to refine their approaches, though. Here’s what Bhulani suggested:
Treat Estimation Like Any Other Process, and Review It
Bhulani described the Reddit growth team as a “mini science lab” — they focus on quick experiments that generate product insights. Before, when the team kicked off new projects, owners would guess at high-level scope and timelines with “roughly 50 percent confidence,” Bhulani wrote, and leads would use that information to prioritize based on opportunity cost. That kept planning time very short.
But, as the growth team grew, this fast-and-loose approach didn’t work as well. So, Bhulani and his team added estimation to the list of things to review in each quarterly retrospective. New approaches to estimating didn’t eclipse the old version; rather, they were added to Reddit’s arsenal of potential estimation tactics.
“While evolution is important, there is also a fine balance between being nimble and being predictable.”
“While evolution is important, there is also a fine balance between being nimble and being predictable,” he wrote. “Every project comes with its own set of challenges.”
Don’t Shame Developers When Things Change
Missed deadlines shouldn’t come up for the first time in weekly stand-ups or retrospectives. Give developers a low-stakes forum for keeping the team updated.
“I like the push framework to communicate date changes and blockers in real time via Slack,” Bhulani wrote. “This proactive form of communication engages the stakeholders in a problem-solving mode, as opposed to an interrogation mode.”
Dare to Have ... Fun?
If sweating over project timelines isn’t doing it for you (and it’s not), try something more lightweight. Bhulani’s team sometimes reverts to what he called “poker planning”: Every person in the room makes an estimate at the same time.
“This approach helps us avoid an anchoring bias and can reveal a misunderstanding of a ticket, previously missed complexity or a new insight about the path forward,” he wrote.
What Are We Really Asking?
Estimates are easy to misuse, but many organizations still rely on them in some shape or form. Does that mean estimation deserves real estate in our brains?
“Just because somebody asks for an estimate doesn’t mean you have to give it to them, number one,” Beck said. “And number two, it doesn’t mean that’s actually the question.”
According to Beck, estimate conversations are rarely about estimates. When someone asks for one, they could be saying they’re worried about profitability. They could be concerned the org is prioritizing poorly. They could be asking how quickly they can report some progress up the management chain.
“Just because somebody asks for an estimate doesn’t mean you have to give it to them, number one. And number two, it doesn’t mean that’s actually the question.”
In that last case, responding with a number or date is the worst possible move, Beck said. Instead, slice the project into increments that will help that colleague show demonstrable progress as soon as possible.
“Yes, we have this big thing to do. But the real answer is, “How do we slice it?’ Not, ‘How big is the big thing?’” he added.
Take the time necessary to get at the real questions lurking under requests for estimates. That will require some vulnerability from both you and your coworkers — they need to share their real desires and concerns, and you need to empathize. That kind of vulnerability can be really hard, Beck said.
But it’s probably easier than estimating.
