Agile Estimating. Why Bother? II

Previously...

We took a Product Backlog.

Prioritised it.

Added some funky colours...

... and delivered some serious value (to the customer).

Today...

We'll finally get around to a spot of estimating.

No bad system

Starting with the most valuable feature, then moving on to the next most important feature - and so on and so forth - is no bad system.

But it does make an implicit assumption: it assumes that each of the each of the features is roughly the same "size".

(I'll say more about what I mean by size in a moment.)

Let's bring this this feature front and centre.

As you'll remember, I'm using the vertical dimension - this one - to indicate VALUE.

I'm going to the horizontal dimension - this one - to represent its SIZE. (Where size is some indication of how long the feature is likely to take to build.)

Let's bring back the backlog, and get the Development Team to do some estimating.

There's a fair bit of work in this one.

This one looks like it'll be quick.

And this one is somewhere in between.

Three features are enough for our purposes today, so I'll hide the forth one.

Estimating done, it's time to set to work.

I need some way of indicating the passage of time as the Development Team works on the items.

Have we had a combine harvester before? Don't think so.

The the first item is a big one...

Working, working, working... Delivered.

Straight on to the next item

Working... Delivered

One more:

Working... Delivered.

What I've just done with the aid of a combine harvester is not much different to what we did in the last episode.

The features have been built in descending order of value.

But this time the Product Owner has more information at his disposal - thanks to the estimating work done by the Development Team

He may decide that the features should be built in a different order. 2, 3, 1 might be a good choice.

Let's give that a go.

Working... Done

Working... Done

Working, working, working... Done.

Comparing the two there's a lot that the same:

• The total time taken is the same in both cases
• The total value delivered is also the same in both cases.

Is the second an improvement on the first?

And if so, is it enough of an improvement to justify the effort that went in to estimating the tasks?

We'll turn our attention to those questions - and others - in the next episode.