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.