Menu

Agile Estimating / Agile Estimation - Why Bother?

Episode 55 - 28 Sep 2016

Agile Estimating.

It's a subject I've been avoiding.

As Agile topics go, it's emotive. It's all too easy to ruffle feathers.

It's also a broad topic. Where to start? What about right at the beginning with a pretty fundamental question:

"Agile estimating: Why bother?"

Agile Estimating.

It's a subject I've been avoiding.

As Agile topics go, it's emotive.

It's all too easy to ruffle feathers.

It's also a broad topic. Where to start?

What about right at the beginning with a pretty fundamental question:

"Agile estimating: Why bother?"

Why bother?

A couple of weeks ago, Andre Luis left this comment on a video:

'Can you do an episode on estimating tasks?'

Andre, thank you very much for the suggestion.

It's an interesting - and potentially controversial - area.

Let's start the journey by asking the question 'Why?'

Why do we even need to estimate?

Context

To get to where we're going, a bit of context will be helpful:

In a couple of previous videos, I've described Software Development as a process where...

  • the Product Owner decides what to build,
  • the Development Team gets on and builds it,
  • and the Customer uses, experiences, benefits from it some way

In Agile software development, the "value" is delivered to the customer, not in one big lump, but in a series of increments.

Feedback from the Customer - together with input from other sources - is used by the Product Owner to create and maintain a prioritised list of 'stuff to do': the Product Backlog.

It's the Product Backlog that we're interested in, so let's remove some of the clutter. And move things around a bit.

I'm also going to re-draw the Product Backlog. And spread the items out a bit. And squish them a bit

All kinds of things can be listed in a product backlog:

  • features,
  • bugs,
  • infrastructure work,
  • spikes,
  • etc.

For our purposes here today, I.m going to assume that these four items are all Features: They are all things that the customer will - in due course - see or experience.

So much for the CONTENT of the Product Backlog. What about the ORDER of the product backlog?

Well, that's ANOTHER subject that could fill a book, so we'll keep things simple and consider just one factor:

  • VALUE

The VALUE that the particular feature will provide to customer.

To recap:

  • These four Backlog items happen to be FEATURES
  • And they have been prioritised in descending order of VALUE.

Let's indicate the relative VALUE with a bit of re-sizing:

  • No. 1 has the most value,
  • No. 2 is next,
  • and so on.

A bit of a colour would be nice. Too subtle. That's better.

Development Time!

It's now time for the Development Team to set to work!

The team is going to start - as you'd expect - with the item at the top of the Product Backlog.

Once that's done, the team takes another item from the top of the Product Backlog.

And so on.

Before we know it, a whole pile of value has been delivered to the customer. Excellent.

But here's the thing:

It was done without ESTIMATING a damn thing.

This episode was supposed to be about estimating, so it's a little awkward.

Somewhere along the way, I made one assumption too many.

I'll reveal all at the beginning of the next episode.