Estimates are bad (and I mean it!)

Recently I wrote about my belief that it is a good thing to estimate. After all thats one of the differentiators that distinguishes us from other forms of life on this planet.

There is a huge number of quotes one can draw from to see the difference:

“Plans are nothing, planning is everything”

-- D. Eisenhower (maybe)

“In preparing for battle I found that Plans are almost useless, but planning is indispensable”

-- perhaps D. Eisenhower or Moltke

“No plan ever survives the first contact with the enemy, but no one survives the first contact with the enemy without a plan”

-- probably Moltke or Clausewitz

It's not so easy to find out who really is the originator of each quote – and I haven't found one yet from Sun Tsu, although I am sure there is one. But the important thing is that all those quotes make a very clear distinction between the act of planning and the actual plan. And there seems to be a common understanding, that the activity is important while the artifact itself –“The Plan”– is very brittle. And has to be adjusted accordingly. Often.

In my experience the same is true for estimates: don't hesitate to adjust them to adapt to a changing situation, but gather enough information and do enough planning to start with estimates that seem plausible to yourself.

Think about harvest planning in the middle ages – having leftovers at the end of winter didn't kill villages, stretching the food for the second half of the winter didn't kill villages. Not knowing how much demand for food there is and living in splendor until Christmas would have been disastrous.

So here the art of the possible would be to do “just enough” estimation.

How much effort would that be? :-)

till next time
  Michael Mahlberg

Estimation is good (and I mean it!)

I am a huge fan of Pavel Brodzinsky's estimation poker cards and the whole “#NoEstimates” movement. But then again I think at last the amount of estimation Pawel suggest is necessary. And as even the long time proponent J.B. Rainsberger said farewell to #NoEstimates I find it helpful to distinguish between “harmful estimation” (my esteemed friend and colleague Tom Breur recently wrote about these) and helpful estimation.

Harmful estimation

Estimation can become harmful for a lot of the reasons pointed out by the followers of the #NoEstimates movements or – for example – by the reasons Tom states in his article I mentioned above.

In my opinion estimation becomes especially harmful when

• it is used to put pressure on people
• an effort is made to get “exact estimates”
• estimates are treated as “exactimates”

Helpful estimation

But – and it is a very strong "but" – just because it can be misused (and often is), it doesn't mean that there is no good in estimation.

A little while ago I wrote about planning already – how planning is what made it possible to evolve from hunter-gatherers to modern men.

And for me the same holds true for estimation. If there is no estimation, then there is no way to know whether it makes sense to even invest the effort to work on something. Planning and estimation go hand in hand. Even in "predictable" environments things sometimes only go partially according to plan. We have estimation all the time:

• estimated time of arrival
• estimated miles on this tank
• estimated payout
• etc.

We couldn't possibly handle our world in all its complexity without “estimating.“ Estimating if the car will fit into the parking spot. Estimating the width of a creek to jump over (or not).

So yes, I think we do need estimates. We just have to make sure, that we know where we need them. And why.

till next time
  Michael Mahlberg

The difference between a sprint-backlog and a product-backlog

Those who learned about scrum the old fashioned way might call me names for the title of this articles, but since I run into more and more people out there who mingle both terms I think a clarification might be beneficial.

A product backlog is about what you plan to accomplish

“The Product Backlog is an ordered list of everything that might be needed in the product[…]” (Scrumguide 2013)

And it is good practice to keep these things in the bounds of the INVEST properties. This implies that the product-backlog does not prescribe how the requirements are met, but what should be achieved.

A sprint backlog is about what you plan to do

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.“ (ibid, emphasis added)

Big difference!

So yes, sorry mates, if you want to do scrum (and not scrum but) you'll have to do what used to be called ”Sprint planning 2“: Sit down and plan your work.
There are some options to handle things differently – like breaking down the board and “kanbanizing” that part of the workflow – but then these approaches might no longer be exactly what should be called scrum.

Cheers
Michael