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 the real world isn't like that.
In the real world, estimates can be wrong
Welcome to Development That Pays
My name is Gary Straughan
And welcome back to this the fourth and final part of "Agile Estimating, Why Bother?"
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 Dev 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.
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 notice about how you feel about this
Your big value item - Feature 1 - has just been pushed back.
That's not ideal.
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.
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.
Thank you very much for watching. I hope you'll join me again next week. Not sure what the
subject will be... But I promise it won't be estimating!