What?
The #NoEstimates idea is to break all pieces of work into similar sized chunks based on a consistent “slicing heuristic”; not give sizes or estimates up front, and hope to be able to predict future development based on how long each one of those similarly complex small tasks ends up taking to deliver. But also very importantly: ensure you deliver regularly.
It’s less about “not estimating”, and more about improving how you work such that estimates are less necessary. Deliver regularly, focusing on the flow, is key to this.
About that slicing heuristic: a heuristic is an approach to problem solving that is known to not be perfect, but is good enough for the time being. So a “slicing heuristic” is best guess at deciding how to split large pieces of work into similarly complex tasks. You’ll make it better each time you try until you something that works for your team.
An example slicing heuristic would be that a feature can only consist of one acceptance test; if you have more than one acceptance test, slice the feature into two or more features.
I’m probably over simplifying the concept, but it’s a pretty simple concept in the first place!
Why?
Whilst coming up with the latest iteration of the development process at Mailcloud, I coincidentally stumbled upon an article about #NoEstimates and subsequently various videos on the subject, and more articles, with support from more articles.
The idea is an interesting one, if only due to my dislike of day-long planning meetings/sizing sessions where inevitably everything ends up being a 3,5 or a 40.
Seems like a lovely idea, right? It also seems fundamentally flawed for reasons such as an inability to give a reasonable quote or estimate to a client up front, especially for extremely large projects. Also, the team has to be able to split the work into chunks of similar complexity, which is easier said than done; ever been in a sizing meeting where everything ends up almost the same size? You require a team’s ability to be consistently effective and efficient, as opposed to just being “consistent” (and not in a good way).
I’m no fan of huge, minutely detailed, projects, so perhaps these aren’t so bad?
Given that I’m one of those pesky critical thinkers, I went out and did a little research on the opposition. There are some extremely vocal detractors of this concept.
The most vocal and well known detractors of #noestimates appear to be those with significant experience in several large projects over more than 2 or 3 decades, with a background in statistical analysis, probability, and software project management.
A quote to sum up this perspective, which appears to have been adapted from a Lao Tsu quote:
“Those who have knowledge of probability, statistics, and the processes described by them can predict their future behaviour. Those without this knowledge, skills, or experience cannot”
i.e., stop being lazy and learn basic stats.
Most vocal and well known #NoEstimates proponents are either also proponents of XP or have more experience in small to medium scale projects and put less importance on statistical analysis.
There’s a lot of – quite childish – banter between these two camps on twitter an in blogs, trying to say who is right, when it’s quite obvious that these different approaches suit different projects; if your client has a fixed budget and a deadline, then not being able to give any confidence in meeting that deadline within that budget (i.e., no estimates) is not going to be a feasible option. Similarly, if you’re not quite certain what you’re building yet, or only know the start and are able to follow the Product Owner and user feedback, then estimating an uncertain backlog to give a realistic finish date is likewise unlikely.
As such, it would appear that you have to – as I always do – make up your own mind, and in some cases take a little from all available sources to create something that works for you and your team or company.
That’s exactly what I’m doing at the moment, and it’s possibly not anything that really exists yet; a little XP, a little kanban, a little scrum, a little noestimates (hey, why not? We’re a start-up!); and a damned lot of trello.
This is Dev Process version v5; I don’t doubt for a second we’ll have a v6, v7, and so on as the team grows and as the product changes.
Interested in learning more about #NoEstimates? You can check out the book, and get a free chapter to kick off with.
I’d view this in two ways:
First teams should find their own sizing that suits them internally and also works to communicate to others. So this might be perfect for some teams and their stakeholders.
Second this feels like standard agile sizing but with the ends of the bell curve lopped off. Something too small pack it up with another thing to make a same sized chunk. Something too big then break it down till its chunkable. My take then would be well you can always roll stories back up to more useful sizes and you should definitely break down stories to manageable sizes when you can.
My only issue therefore is how much effort do you take breaking down larger things into size chunks before you’re ready? Not much at all then knock yourself out. But spend a lot of time breaking down poorly understood items to chunk them (or worse effectively pretend you have a good handle on something before you actually do).
As an aside, my general rules on breaking things down are that no task should be longer than a day. No ready to work story should be bigger than half a sprint (and in general be a lot smaller than that).
Ultimately I’d say having a clear understanding of your process and what your estimates mean in that context (vague but getting more concrete over time, detailed but with contingency for inevitable change, detailed up front but vaguer further out) between all parties is more important.
First let’s start with some principles. Business runs on cash flow. Knowing the cost to produce a value and knowing the tradeoffs between multiple choices if the principle of Microeconomics applied to writing software for money. The notion of Not Estimating is willfully ignoring those principles. #NoEstimates has stated from day one that decisions can be made in the absence of estimates.
Next is the notion that all project work is probabilistic. Making decisions about future outcomes in the future requires some means of developing knowledge about those outcomes. To date #NoEstimates has provide no means to make those decisions in the presence of uncertainty.
Improving the way estimates are made is a universal quest. Not limited to #NoEstimates. But #NoEstimates says we can make decisions without estimates. So this is direct conflict with the search to improve estimating.
The #NoEstimates advocates use bad management as the starting point for not estimating. Chapter 1 of Vasco’s book is a horror story of bad management. Assigning a project to an inexperienced project manager that is 100x what she has ever seen, then expecting success is bad management. Then blaming estimating on the cause of the problem is also bad management. We have a phrase in our domain. “Don’t Do Stupid Things On Purpose.” (DDSTOP)The manager in Chapter 1 does just that.
Let’s look at some specifics
Slicing is a common process in any estimating method. The “basis of estimate” can be arrived at be decomposing the work into “chunks” that can be recognized as having been done before or small enough to actually get tested. This takes effort and does not come for free. So slicing is an estimating process. Calling Slicing Not Estimating is another oxymoron of #NoEstimates.
If you spend a day estimating and always end up with a 3, 5, or 40 for story sizes – and decompose the 40 to 3 or 1, then skip to the end next time and assign 1, 3, 5 to stories once they’ve be decomposed DDSTOP. This is called Reference Class Forecasting. It’s used everywhere. Google will find you all the materials needed for RCF.
Huge minutely detailed projects are bad management. In our domain, we only plan in detail within the planning horizon. Work is placed in Work Packages – iterations, and all other is placed in Planning Packages at a high level with less resolution.
But all project work is probabilistic, so any planning process must consider the reducible and irreducible risks. Irreducible risks require margin – schedule, cost, and technical margin. This is the naturally occurring variances. A reducible risk requires explicit “buy down” process to make the risk go away. If you “managing” a project without margin and risk buy down activities, you’re late and over budget before you start. Blaming that on estimating is an oxymoron as well.
As one of those asking hard questions – labeled as detractors by #NoEstimates – it’s clear those conjecturing not estimating while making decisions have yet to come to understand the basic principles of business – microeconomics and probabilistic planning. As a manager and former software engineer of mission critical, high risk, high reward projects, the process of estimating must be applied by determining the “Value at Risk.” Low risk? Don’t spend too much time estimating. High risk, you’d better have some confidence in the budget, duration, and probability that it will work when you arrive at the end of the project.
Having managed 3 startups the notion that estimates are not needed is nonsense. Those paying – VC’s and PE’s want to know when we’ll break even, when we’ll have a demonstration of the product, when we’ll be at our first tradeshow, what we’ll produce for their investment and when we’ll be able to seek the next round of financing so they can start to get their money back. The #NoEstimates advocates using “startup” as their excuse for not estimating must have low value at risk. In our domain a typical investment for first round is $20M. Those provide $20M need estimates.
Regarding the book, I’ve read most of the chapters. Chapter 1 sets the tone – bad management. So if you think bad management is the reason to ignore microeconomics then proceed. But take care you may find that bad management also means “going out of business.” So while you are No Estimating then money is likely to run out and both problems will be solved. You won’t need to estimate, because you won’t have a job.
Above all else remember this from the non-trivial, microeconomics based business paradigm – It’s Not Your Money. If it is your money, spend is wisely and make sure you have enough to reach Break Even before it runs out.
Nice comment from Neil Killick, one of the key proponents of the concept: