Estimates have always been an integral part of the software development process. By estimating the amount of time, money, and effort it will take to reach project goals and outcomes, developers and team leaders can help managers and clients better predict budgets and meet project goals.
At least that's the theory behind the widespread and often unquestioned use of estimates in the IT industry today.
In recent years, however, developers, including Woody Zuill and Vasco Duarte, have begun to question the efficacy, and even the purpose, of using estimates to predict a project's cost and time line. A fierce debate has sprung up on Twitter, between those calling for an end to estimates and those who continue to champion their use in a professional setting.
On the surface, it would appear that the debate is black and white. Proponents of the #NoEstimates Twitter hashtag are promoting a hard stop to all estimates industry-wide, and critics of the movement are insisting on a conservative approach that leaves little room for innovation. However, the reality of the debate has unfolded in far more complex, nuanced shades of gray.
I wanted to dig deep and pinpoint where the debate started, where it now stands, and what its implications are for the future of software development. My search took me beyond the often heated Twitter-based mudslinging, back to 2012, when Woody Zuill first blogged about completing a project sans estimates.
As I explored what a #NoEstimates project looks like in practice, I examined the opposing perspective. My interview with Peter Kretzman, a strong critic of the #NoEstimates movement and a supporter of the continued use of estimates when effective, demonstrated just how complicated and subtle this debate has really become. For example, there are many points on which Zuill and Kretzman actually agree, giving both sides of the debate common ground on which to build a continually better approach to the question that's being begged: to estimate or not to estimate?
Here's what I found in my search for the truth beyond the hashtag.
The history of the #NoEstimates movement
Back in 2012, an unobtrusive blog post by Woody Zuill made an unexpected splash when he shared it on Twitter, along with the first instance of the #NoEstimates hashtag. That tweet ignited a debate that has only grown in fervor, gaining traction because of the controversial implications of doing away with estimates altogether.
A senior consultant at Industrial Logic, Zuill used the playful post to detail the success of a project completed without estimates. When faced with a seemingly endless requirements document and asked for estimates on implementation, Zuill and his team took a somewhat radical approach: they identified what they considered to be the most important story in the document, then broke that story down into smaller tasks, and executed those tasks as swiftly as possible. Once the client was shown the initial win in the form of working software, they were less concerned with estimates and more willing to let the development team continue checking items off the to-do list.
Zuill's team was able to shift their focus from estimating time worked to actually doing the work, and from projecting costs to cutting costs by simply diving in and getting down to business.
At the same time Zuill coined the #NoEstimates hashtag, thought leaders like Vasco Duarte and Neil Killick were also beginning to highlight the inefficiency and futility of estimates. Duarte argued that "in a complex environment, we don't have discernible causality." In other words, if the software development process takes place in a complex environment (and Duarte argues that it does), then it's impossible to accurately predict factors such as time and cost. There are simply too many complex variables impacting the accuracy of an estimate, rendering estimates pointless.
Killick did Duarte one better, insisting that estimates aren't only inaccurate and a waste of time, but that they can be downright destructive, "creating an environment of fear" where the developer is pressured to estimate outcomes based on what's desired, not on what's realistic.
The writings of Zuill, Duarte, and Killick sparked a massive debate about the role estimates play in the development process, whether or not that role should be reexamined, and what processes, if any, can or should serve as a replacement for estimates in the future.
The #NoEstimates camp
Key players: Woody Zuill, Vasco Duarte, Neil Killick
The argument
- Estimates are part of the software development process not because they're effective or beneficial, but because they've been a part of the process for so long that developers, managers, and team leaders assume they're a necessity.
- Estimates are always inaccurate and therefore pointless. When developers are asked to estimate the amount of time and work it will take to complete a project, they're asked to predict the future in a way that can't possibly account for the complex factors that will impact the estimate.
- Estimates are often padded by developers, encouraging mistrust between team members, mangers, and clients. This can harm project transparency and even damage healthy working relationships.
- Estimates are a waste of valuable time. Instead of beginning the work, developers are forced to spend time and money creating estimates that aren't accurate to begin with and are therefore useless.
The gray area
Zuill, one of the strongest voices behind the #NoEstimates movement, is a far cry from the equally vocal #NoEstimates fundamentalists who have turned the Twitter debate into a veritable rage. Although some may argue that he fathered the #NoEstimates movement, Zuill is much more diplomatic when it comes to examining estimates and their function in the development process.
In a recent interview with TechBeacon, Zuill revealed he has no problem with estimates in and of themselves; the problem occurs when estimates are done just because they've always been done.
"I feel I must question everything about the way I work and the way I think," Zuill says. "That's particularly true about the things I have the deepest beliefs about."
Estimates, then, should be questioned precisely because they've become such a deeply ingrained part of the software development process. According to Zuill, estimates aren't bad or good but are merely tools that give managers and developers "a feeling of control. [Estimates] make it easy, not right."
Zuill goes on to argue that estimates are made at the point in the development process when we know the least about something. While there are certainly cases in which estimates can be useful, these should be determined on a case-by-case basis. Estimates shouldn't be automatically required for every project, 100 percent of the time.
The call to change
In his now-famous blog post, Zuill detailed a project where he and his team worked without estimates. During the project, he successfully demonstrated to his client that beginning the work without completing estimates was more cost-effective than spending time estimating every item on a lengthy requirements document.
Here's how Zuill's #NoEstimates technique looks in practice:
- Instead of providing an estimate about how much time/money/effort it will take to deliver on a large requirements document, dive into the work by identifying the most important story and implementing it. Once that's completed, move on to the next most important story.
- If you work in small chunks, you will often negate the need for many items on the requirements document. Since many of the items the client initially wants end up being set aside, providing estimates on them is a waste of time. (Why estimate when chances are good you won't end up completing the work at all?)
- Move beyond the idea of story points, a common measure of the number of units a story will take to complete. Instead, look at the total number of stories that need to be completed as a gauge of the total amount of work that needs to be done. If a story can't be completed in one sprint by one person, break it down until it can. Count the total number of stories to be completed, not story points, and then determine how many stories you can deliver by a certain date.
While many developers have jumped on the #NoEstimates bandwagon, claiming to have successfully completed projects without estimates, not everyone is convinced that working sans estimates is realistic or even desirable. Critics of #NoEstimates demand evidence of large scale, long-term, multi-team projects that have been completed without estimates, and cite a failure to share such evidence as proof of #NoEstimate's inadequacy.
I interviewed veteran IT executive Peter Kretzman to find out why some aren't convinced that #NoEstimates will work.
The #Estimates camp
Key players: Peter Kretzman, Glen Alleman
The counterargument
- Of course estimates are always wrong—that's why they're called "estimates!"
- By refusing to provide estimates to management, developers remain insensitive to the complicated needs of the company that reach far beyond their particular project.
- Providing an estimate may impact multiple departments, teams, and individuals in ways the developer isn't privy to. Estimates should therefore be considered an important professional courtesy, even if developers themselves prefer to work without them.
- If you can't provide an estimate you won't get funding—that's just how businesses work.
- If your estimates are inaccurate, why not improve them? Inaccuracy isn't a reason to abandon best practices.
- While the #NoEstimates camp claims "We can't predict the future" by providing estimates, the #Estimates camp argues that we can and should. Businesses are built by predicting and analyzing market trends. Future forecasts are based on past performance. Estimates, therefore, can be created by assessing the time, cost, and units of work completed in past projects and by projecting them onto the current project.
The gray area
According to Kretzman, the #NoEstimates narrative has changed drastically over the past two years.
"It started off as 'no estimates, period,' and now people are saying 'estimates are fine if/when they work.' "
If #NoEstimates supporters are no longer calling for an absolute end to estimates, Kretzman challenges them to reveal when and where they will use estimates in their projects.
Chances are those projects won't be large-scale, multi-million-dollar undertakings, however. #Estimates supporters demand examples of the #NoEstimates theory working on a large scale, claiming that most #NoEstimates supporters can't provide simple answers to questions about the domain, value, and risks associated with their #NoEstimates projects.
Kretzman has been particularly vocal in his demands for evidence of #NoEstimates projects that have been successful, including their scale, scope, governance model, and value over time.
"#NoEstimates probably works great if you don't care what you're developing, when you'll deliver it, or how much it will cost," he says. The same #NoEstimates approach that works for a three-person company may not work for a 300-person or 30,000-person company.
The question of stories and story points is another point of contention for the #Estimates camp. Kretzman balks at the thought of "picking the most important story and starting with that."
"The most important story to whom?" he asks.
The developers' perception of what's most important might be completely different than the client's. There might also be legal implications to consider and other factors influencing the project's direction that reach far beyond the control or awareness of the developers, rendering the most important story difficult to define.
The call to change
Like the #NoEstimates camp, the #Estimates camp doesn't call for a one-size-fits-all approach to estimates. Instead, supporters like Kretzman advocate the responsible use of estimates, calling for increased transparency by including risk assessments in estimates. He also suggests the increased use of test-driven development (TDD) as a way to increase project efficiency.
"The most important tenet of the #Estimates movement, however, is the call for transparency from the #NoEstimates camp in terms of the specifics surrounding their estimate-free projects. Without providing details as to how various #NoEstimates undertakings work, other developers will not be able to successfully adopt the techniques that made the #NoEstimates project possible in the first place," Kretzman says.
An ongoing debate
The #NoEstimates movement has called into question the purpose behind using estimates in software development projects. While the movement initially called for an end to the use of estimates across the board, it has morphed into a discussion that questions so-called best practices and opens a dialogue concerning their application in software development.
Claims that development projects can be successfully completed without estimates, while sometimes supported by vague, anecdotal evidence at best, have nonetheless sparked a conversation about how to increase project efficiency and accuracy. There's a wide range of opinion surrounding #NoEstimates, with both supporters and opponents agreeing that estimates are necessary in some circumstances.
The debate centers around what those circumstances may be and at what point estimates become irrelevant and unnecessary.
According to the #Estimates camp, the #NoEstimates movement has yet to propose a practical alternative to estimates in the face of large-scale projects, and it fails to account for the business realities that often require estimates in order to move forward on a project. For a story-based approach to replace traditional estimates in software development, leaders of the #NoEstimates movement may need to increase the transparency with which they share project details, especially when it comes to large-scale projects completed without estimates.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
