Wednesday 30 May 2018

True Confession: I don't enjoy estimating

But I do it anyway...

I haven't blogged in a while. I read a book, did the crossword. It was good.

I'm going to add a new story into my NoEstimates Blogging Backlog. This is it – you're reading it now. It's a backlog, I own it, and I'm allowed to do that :)

Estimating is no fun

I defy anyone in this game - Dev or Scrum Coach or BA or Programme Manager or even business client - to admit that they enjoy estimating. It's always based on incomplete information (that's why it's an estimate not a report), and we always feel like we're sticking our finger in the air and our butt on the line, at least a little bit.

If there's anyone out there who truly enjoys estimation, please teach me your special sauce!

Why I estimate anyway

I use two kinds of estimate: for the customer and for the team.

For the customer should be obvious, for most readers. Can I afford it? Will I get it in time?

I know the diehard NE set deny the value of this kind of estimate. They maintain that the customer is paying for software not for estimates, so let's give them valuable software and not waste time on estimating it. I also know that almost every business I've ever worked in has wanted answers to these questions before committing to a SW project. And since it's their money I respect that.

For the team, estimates are a mechanism for sustainable pace.

I facilitate estimates because I tend to coach Scrum. Estimates - generally story-point estimates - are key to Scrum's mechanism for managing sustainable pace.

I'm aware that other approaches to sustainable pace are available, most obviously Kanban (a lot of observers note a close relationship between NE and Kanban). So I could ditch team-oriented estimates by shifting to Kanban, but my experience is that teams are much more comfortable in Scrum. The Sprint cycle, which is (necessarily?) estimates-based, gives them an opportunity to come together, take stock and agree where they stand.

But not on this project!

I'm in an interesting position on my current piece of work: starting an Agile project that interfaces to a much larger Waterfall programme. We should be able to deliver results faster than the programme, which is an external dependency.

If we can do that, then the limiting factor will be the programme not the project. And with a bit of luck, in this specific luxurious circumstance, the customer will quickly consider that estimates from my team are irrelevant.

Can I eliminate estimates for the team too?

No.

"The Sprint cycle, which is (necessarily?) estimates-based..."

Necessarily?

Some years ago, Vasco Duarte tweeted a burnup chart comparing a trace of estimated stories, and one of equal-sized stories. He saw a negligible difference between the two. I found it intriguing.

There are important questions to ask about this:

  • Did the estimation process contribute to the stories being sufficiently similarly-sized for this to work?
  • Did the estimation process generate important conversations that would not have happened without attempting to estimate?
  • Were the statistical methods used robust?

I think the first important question for me is can I reproduce these results? Seems like a good time to try :)

Then there's that guy who bucks the trend

There's always one! In this case, that guy who sells software projects without providing customer estimates. Seems he acquires new work based on recommendations from existing clients, and his new clients respect and accept this.

That's one hell of a hard-earned reputation! And/or the guy could sell snow to Alaska. Either way, he has my respect and not a little envy!

Proponent? Opponent? Who the hell is this guy?

I think NE set consider me an oppositional pro-estimates traditionalist, while the traditionalists consider me a hopelessly naive borderline NE advocate. They are two highly oppositional camps. I'm please to sit in neither, though it means brickbats from both.

I hope this post demonstrates a more nuanced position. Estimates do not make me feel all warm and fuzzy. They're not why got into this game, as either a Dev or a Scrum Coach. If I see a circumstance in which they're not necessary, I'll happily jettison them. And for those particularly talented practitioners who are able to run their businesses without estimates - all strength to them!

At the same time, my clear experience and that of many others is that many businesses, most of the time, require estimates of one sort or another to invest in SW projects. I respect that and I'm not about to throw mud in their face for their financial diligence*.

(Yes, I know that financial diligence and governance can be misguided, even pathologically so. There may be a future post on this.)

An experienced practitioner has a varied toolbox. I came to NE looking for a new tool for mine. It's been tricky to find, obscured by a rancorous debate with little middle ground. Finally I've found one. The kind of middle position that doesn't generate Twitter followers and speaking engagements.

Sometimes some estimates are important, and sometimes they're not.

No comments:

Post a Comment