Agile Estimating. Why Bother? IV

Previously...

We stripped things right down. Right back to first principles. To see what happens if we take an item from the top of the product backlog, and get straight to work. Without Estimating.

And to see happens if we do some estimating, and use that information to make more intelligent decisions about the build order.

It's been all very clean. All very precise.

But real life isn't like that.

In the real world, estimates can be wrong.

We've come a long way...

This is uncharted territory for me. I've never made a "Part 4".

I almost brought things to close at the end of Part 3

... but I thought it was important to cover just one more thing:

what happens when estimates turn out to be wrong.

Which is, of course, almost all the time.

1, 2, 3

I want to put yourself in the place of the Product Owner.

You've decided - perhaps unwisely - to build these three features in this order:

• 1, 2, 3

The development team sets to work.

Time passes....

And at this point, the Development Team runs into a problem.

It's going to take longer to build than originally estimated.

This much longer.

How do you - as Product Owner - feel about that?

Perhaps you're feeling that had this feature been correctly estimated at the outset

you might have chosen a different feature to build first?

Hold that thought.

We'll be coming back to this picture in a moment.

2, 3, 1

In a parallel universe, you're also a Product Owner.

And in this universe, you've decided to build the features in this order:

• 2, 3, 1

Make sense: features 2 and 3 together deliver more value that feature 1, and they can be delivered in the same time.

The Dev Team sets to work.

Time passes.

The estimate for Feature 2 was spot on: it's delivered right on time.

Ah now. It seems that things can go wrong in this universe too.

The Dev Team reports that Feature 3 is going to be delayed - by about this much.

Again, Take a moment to thing about how you feel about this?

Your big value item - Feature 1 - has just been pushed back.

That's not ideal.

Sunk Cost

Two situations. Two delays.

But which is better?

Are you familiar with the concept of Sunk Cost?

In economics, a sunk cost is any cost that has already been paid and cannot be recovered.

Put it another way, we should be making decisions based on the present and the future ONLY.

Easily done. I'll just rub out everything in the past.

Does that change your feeling about either of the two cases?

In the first case, your highest value feature is also your smallest feature.

Had you been planning work today, you'd have picked it for development in a heartbeat.

So the fact that it's already in progress is amazingly good news!

What about this case.

Item 3 is a relatively low value feature.

If you were planning now, there's no way you would have scheduled item 3 ahead of Item 1.

Can you pick Feature 1 now?

Alas no. In all but exceptional cases, the I've-started-so-I've-finished Directive trumps the Sunk Cost Directive.

You're committed to continue with the development of Feature 3. You'd be invoking the wrath of the agile gods to even THINK about putting it on hold.

Epilogue

It's been a game of three halves.

Building in order of value - without estimating - worked reasonably well.

Adding in a touch of estimating gave us the ability to re-order the features to provide more value more quickly

But real-world delays may have left us wishing that we'd hadn't tried to be clever with our ordering.