Skip to content

Avoiding the estimation death spiral

There are so many engineering cultures which expend a tremendous amount of effort and time on planning and estimating how long their work will take. There are ceremonies involving playing cards and T-shirt sizes and fibonacci sequences and all manner of meetings and tickets.

All in an effort to get a better grasp on the fundamental question of when will then be now?

Many of these techniques are cargo culted from much larger organizations, where these techniques were a response to acute organizational pain.

That pain typically involves missed expectations.

Projects run late, and perhaps don’t match the expectations of the business or the product team.

Ok. So, we need better requirements. So we can estimate better.

Things still run late.

So, we need smaller tickets, so we can estimate them better.

And that’s how you end up with hours a week of laborious planning or backlog grooming sessions and run the risk of constantly planning and never shipping.

You end up with ScrumFall.

This is the death spiral of startups.

How did we get here?

First off, we estimate software projects because, well, somebody asked for a timeline or a launch date.

This is a reasonable request on their part! The release of software comes with lots of other activities for the business – from marketing to enablement to press releases and board decks.

Knowing when something is coming allows the business end of things to prepare for all of that – and sometimes to placate customers and prospects who similarly want to know when their request will get fulfilled, their bug fixed, or their pain relieved.

Many of the practices and techniques around estimating software projects also come from consulting practices – where there is a gap between the folks doing the engineering and the folks making the business or product decisions.

In any software project, we have three areas to play with – scope, timeline, and resources.

The mythical man month tells us that adding resources to a project tends to make the project run later still, so we’ll set that aside for a later chat.

In a consulting arrangement, scope is dictated by the customer. There can be some negotiation, but they’re ultimately paying for a thing to be delivered. So, the negotiation hinges much more around timeline and resources – both of which translate to money.

In that sort of an arrangement – when scope is relatively fixed – there is a tremendous amount of pressure on relatively accurate estimation. And once the engagement begins, there’s back pressure on keeping that scope fixed. If you’ve done any consulting, you’ve had the conversation with your client about not changing the scope or to ask for a change order.

In startups, though – especially early stage startups – scope is not fixed, but fungible. Or should be – the very nature of a startup is figuring out what the market wants.

Empowered engineering teams aren’t being dictated with what to do but should have a very large say in the shape of the thing they’re working on.

They’re not contractors, they’re colleagues.

The way I’ve always put it to engineers I’ve managed is that they are there because I want their thoughts. If I just wanted to tell someone what to do, I’d hire an offshore contractor.

A suggested better way

In my recent career, I’ve worked in the scenario I described at first – what I like to call the estimation death spiral – and they hadn’t shipped anything of note for quite some time.

I’ve also been in a startup where we left timelines fungible to the extreme, and ran our process as straight Kanban. That resulted in a situation where new, “urgent” things kept pushing out the timelines for larger things the business cared about. We chased new, shiny things until leadership was changed.

What I changed in the wake of that was to lock down timeline rather than scope.

In something very close to, but not as regimented, as Shape Up, we worked with the business in the opposite fashion than the scenario described above.

We asked what they wanted to release to market in two months.

We spent some time going over ways we could make that true, that could fit in that timeline. We talked about which corners we could cut and which we could not.

Essentially, rather than negotiate on the timeline, we set that in stone and negotiated on the scope of the work.

The first few cycles for this were rough as we figured out what fit in that time frame, but things got better over time and we always shipped something in each release cycle.

Over time, we got better at estimating while not actually estimating anything with any precision at all.

Rather than looking at work and figuring out in detail how long it might take to do, we imagined what we could accomplish in eight weeks time.

The next time you’re asked to estimate something, stop and ask which is more important: the timeline or the scope.

You might be surprised by the answer.

Leave a Reply

Your email address will not be published. Required fields are marked *