In the beginning of the year, the #noestimates movement gained some attention and traction in the software development world.  It’s an interesting position, with some strong arguments in its favor — but personally I find it to be entirely development-focused and that it ignores the business and customer realities that we as Product Managers must wrangle with every single day.

Of course, most Product Managers don’t approach estimates in the right way, so it’s no wonder that developers feel that their time and effort is being wasted.  But the answer isn’t to dispose of estimates altogether, but rather to ensure that they’re being obtained and used in appropriate ways.

Muda, Mura, and Muri – What is “Waste”?

The goal of any lean process, including Agile development, is to reduce unnecessary and unproductive waste (the “muda, mura, muri” of the Toyota Production System, from which modern lean practices derive).  Essentially, if something does not add value to the end result, it is considered “waste” and should be minimized or eliminated.  I think nearly everyone in the world should be able to agree on this as a general principle — if it’s not improving or supporting the end result, why do it?

However, it’s important to note here that the lens with which we should be viewing whether or not something is “waste” is not with regard to a specific team, or a specific department, but rather with the end goal that is trying to be achieved — by everyone involved.  The TPS (insert Office Space joke here) process empowers everyone involved to “stop the presses” when they notice something is ineffective, and focuses on the quality of the end product.  As a manufacturing process, this is something that’s pretty easy to quantify — is the widget that falls out at the end of the line the widget that was intended at the beginning of the line, and did it go through the line as fast as it could?

Software development is not a manufacturing process, though — and it’s a nearly universal fact that what is specified or intended at the outset of a unit of work may or may not be what actually comes out on the other end.  Thus, it’s not a predictable, controllable process that lends itself to direct comparison to manufacturing metaphors.  It’s similar in many ways, but also different in others.  Rather, most successful companies in the current world measure their success and the success of their efforts based on how well they are able to respond to their market and their customers, and provide them with useful solutions to their problems.  Anything that contributes to these goals is not waste.

Estimates Don’t Need to Be “Waste”

Estimates become wasteful when they are not rationally connected to legitimate goals of the organization.  And in many companies, estimates absolutely are wasteful.  They’re expected to be too accurate, too reliable, or too detailed at inappropriate times.  And this is a failure on the part of Product Managers in understanding the realities of estimates, when and how they should be applied, and managing the expectations of others in the organization with regard to estimates as a whole.

But that’s not a problem with estimates, it’s a problem with people.  Just like Agile processes don’t work when they’re not fully baked or fully accepted, the process of obtaining estimates and their use doesn’t work when people have unreasonable expectations or don’t understand why, how, and when different types of estimates should be used.

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers.  We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately.  “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

How Do We Make Estimates Less Wasteful?

The primary way that we as Product Managers should approach estimates is to balance the needs of the organization and the business with the needs of the development teams.  There’s always tension here because the organization generally wants certainty, while the developers just want to get started building something.  The good news is that there’s clear middle ground between the two, and it’s mostly an issue of the Product Manager working to manage expectations on both sides of the coin.

Here are a few of my rules of estimating:

• Estimates should only be as specific or reliable as they need to be at the time.
• Estimates should require only as much work as needed to suit the need at the time.
• Estimates should be based on conversations between development and stakeholders/PM.
• Estimates become more specific and reliable as work gets done.
• Estimates are not a contract, nor are they binding in any way on future efforts.

I’m a strong proponent of using Story Points as rough level-of-effort estimation, and evangelizing within the organization that Story Points are used only for understanding “how big” something is, not how long it will take, not how many resources we’ll need, not when something will be done, or any of the common misconceptions around them as an estimating tool.  Story Points, in my world, are used specifically to determine which efforts are “small”, which are “medium” and which are “big” — how that translates into actual work is decided when we start working on something.

Additionally, I’m a firm believer in specifically calling out that we know very little about almost every aspect of a project when we first start it.  There are many times when an initial Story Point estimate shows that something was supposed to be “small”, but once we open up the hood, we find out that it’s actually significantly larger.  There’s nothing wrong with this, and it’s not evidence that the initial estimate was “wasted”…it means that we made a decision based on what we knew at the time, and then found out more, and that we need to adjust our decisions based on the new information.  Of course, there are also other times when something we thought was “large” turns out to be smaller when we start it — again, this informs future decisions about that project and future estimates on related items.

Healthy use of estimates and estimation processes helps to normalize relationships between development teams and the rest of the business; they help everyone to understand what’s known, what’s not known, and what needs to be discovered.  Unhealthy use of estimates results in dissention and unhappiness as developers view their efforts as waste.