Scrum Notes 2013-20

Estimation has been the bane of the developer's life ever since we moved beyond the hacker era of software creation, and into "corporate software".

When people hacked, they just wrote code, completed stuff and released it. People took pride in their work, challenged one another, made things up as they went along and produced wonders, the like of which no one had ever seen before.¹

And then it got serious. The business world saw the value of software, and wanted in. Trouble is they viewed software creation as another form of manufacturing—a predictable, measurable endeavour where demands could be made of developers and results expected exactly as the requirements dictated. No need to go into all the history of defined, linear process, up-front requirements and design, engineering-think and all the other follies the captains of industry and their MBA compatriots fell into. We know today it was flawed thinking, and that's why Agile in all its assorted flavours is surfacing as the preferred way to develop software.

Yet the residue of the old way has shown itself to be sticky. Although it is now recognized that getting real working software in front of real users sooner rather than later allows a company a powerful business edge, the old habits of writing detailed requirements, making date and scope promises, and estimating effort haven't gone away—indeed many so-called Agilists continue to perpetuate the myth that such thinking is still necessary and useful.

Take estimation. I know of few organizations who have discarded the wasteful practice of upfront effort estimation. Most perpetuate the idea that this serves a useful purpose. Sure, it is easier and more realistic to estimate for a two week period than for a three-to-six-month period, but in practice this leads to pain, shoddy quality, and broken promises. Many agile teams suffer from the illusion that if we use relative estimation, e.g. story points rather than actual time estimation, we are somehow spared the pain of being held to our promises. This is not true. Story points merely add a level of indirection, quickly translated into actual time, with the same pain resulting.

Story points obfuscate rather than clarify. They increase waste rather than reduce it. Using story points also leads to velocity calculation, perhaps the single worst (or best!) management weapon for beating teams with. The way we estimate is profoundly broken. The question I'm interested in is this: Is there a need for estimation at all, and if so, how can it be a tool for learning rather than another form of compliance to old-think?

Estimating—making guesses—is a natural way to discern between options in order to make decisions. We do it all the time, in all aspects of life. This morning I looked at the clock and estimated I wouldn't have time to walk to the station in time to catch the train to work. The information directed me to another option: Request a ride to the station. I caught the train.

A better analogy for estimating software may be to look at hiring a contractor. Some contracting work is very simple, e.g. painting a room, and both worker and customer can usually be satisfied with a fixed price/fixed time estimate. Other work is more complex, e.g. creating a custom-built kitchen, or even designing and building an entire house. As a contractor I wouldn't expect the client to just say "get going, and tell me the price at the end". I'd expect a request for both price and time. But I've never built a house like this before. I don't know what to expect. Still, I have built other houses so I can say something like: "it'll cost around $300,00 and take about six months". Useful information—if taken as an informed guess. Utterly useless if taken as a promise. Once I've researched the foundations, got planning permission, hired workers and started building, I'll have better idea of cost and time. I update the customer. Working closely with the customer we can change the design, add or remove features, select different materials, and so on. We can inspect and adapt. The customer can choose to stay on budget, stay within scope, or be flexible on both. Building software is not like building a house, of course, but both benefit from ongoing dialog about what to do next. The added advantage of software is that it is thousands of times more pliable and changeable.

I recall a situation where I was working with a software consultancy who charged their clients by the hour. This was painful for both parties. The customer didn't want to buy hours, she wanted to buy working software to meet a business need. We changed the pricing model to offer an upfront guess, within a reasonable range, with the understanding we would update that estimate every two weeks. The first thing we did was agree on the most important features to build first, then price each of those features. The agreement was that the customer would pay for the features built, and not pay for the ones not built. Seemed fair. At the end of that two-week period the customer owned the working features (i.e. all of the code) and could decide to take their business—and our code—elsewhere if they were not happy. Or they could decide to have us build a few more features, and offer a fresh estimate of time and price based on the set of features the customer wanted (or thought she wanted).

Thus guided the customer could work closely with the team to prioritise and get the minimal product in front of real users very early. No one promised anything, no one was beaten up for not delivering, problems were surfaced early, and (in this case) adaptations to scope were made frequently to stay in budget. This is iterative estimation: estimation based on mutual trust and shared purpose, used to guide and inform.

When requests are kept small estimation of effort became irrelevant. Price was agreed through shared understanding. Sometimes the development team was wrong—but not always in the same direction, thus it balanced out. The whole project was still driven through estimation though—informed guesses used to make the next decision.

Estimation as commonly practiced is mostly (if not always) useless. We cannot promise time, cost and scope, and it always results in pain if we deny that. Estimation for learning though, that's helpful. We estimate all the time anyway, so let's make it explicit, and do it mindfully.

¹ I recommend Hackers: Heroes of the Computer Revolution, by Steven Levy, 2010