Previously...
A combine harvester.
Today...
There might be another combine harvester...
Here's the picture we started with way back in Part One.
When I cleaned it up and moved there guys and girls around, I was careful about where I positioned them.
Notice that each of the players have a very specific view of this Feature.
It's the feature that we pulled from the top of the Product Backlog.
It was at the top of the backlog because the Product Owner judged it had the potential to deliver a ton of VALUE to the customer.
From this position, it's the Value "dimension" of this rectangle that the Product Owner is looking at.
The Development Team have estimated the time it's likely to take to build this feature.
From this position, it's the "size" dimension of the rectangle that the team is looking at.
Of course, things aren't quite as one-dimensional.
I'd like to think that the Development Team has some interest in the VALUE of the thing they are developing.
And the Product Owner is going to be VERY interested in the time dimension
Why? Because it has a number of implications for planning; Not least: "When will this be live?"
The customer, on the other hand, is one-dimensional.
From here, she has no view of the size dimension.
And that's as it should be: she has no knowledge - nor interest - in how long a feature takes to build.
No, it's VALUE that she's interested in.
And she's looking right at it.
Except...
She can't see it. Not yet.
As a backlog item - even as a work in progress item - It's value is POTENTIAL.
It's not yet actual.
On the left, it's the world of the Product Owner and the Development Team
On the right the world of the Customer.
This funny green line represents the level of value that she (the customer) currently experiences from our service.
And here's our old friend the combine harvester.
When a new feature goes live - ONLY when a new feature goes live - there's an up-tick in the level of VALUE.
The delivery of these three features - in this order - results in this value "profile".
The SAME three features delivered in a DIFFERENT order result in a different value profile.
The order that we looked at last time - 2,3,1 - results in a profile that looks like this.
Same features, different order.
But which is better?
There only one way to find out!
Superimposing one on the other.... it's perhaps not super-clear, but I hope you can see that there's a larger area "under the curve" for the second case than for the first.
I went to the trouble of getting out my graph paper and counted the squares.
The second case delivers actually delivers around a third more value than the first case.
Remember the question we started with? "Estimating, Why bother?"
It looks like we've found a good reason to estimate:
knowing the size of a feature gives us the POTENTIAL to deliver more value more quickly.
There's a couple of other things I'd need to say about this, so we'll pick it up there next time.
Watch "Agile Estimating. Why Bother? III" on YouTube.