Lean Thinking

Dave Martin  

Dave Martin

Last time we started to look at relative estimates and the most common method of relative estimation using story points. We looked at why they work well but also at some of their limitations. The biggest limitation is the fact that they are numbers and we have some built in cognitive biases when it comes to numbers. We mistake precision for accuracy and tend to agonise for ages over the story point numbers which turns story points from a fast, lightweight and accurate method of estimation into a slow, heavyweight and accurate method. It's still accurate but we waste a lot of time.

There is a way to keep the accuracy of story points but remove the cognitive biases we have around numbers. It’s a simple as not using numbers in our estimates. The usual way to do this is by using T-Shirt sizing – stories are small, medium, large or extra-large. Some teams go a bit further and add Extra Small and XXL but we’re getting into false precision there so I would recommend against that.

Last time we looked at the concepts of accuracy and precision and how getting the two mixed up can lead to all sorts of problems. We also looked a little at our cognitive bias, that has us assuming that precise numbers are also automatically accurate. The upshot of that is that we humans are absolutely terrible at estimation. We mistake precision for accuracy and our accuracy is really bad to begin with.

That last statement is only half true. We are really, really bad at things like guessing how many jelly beans are in a jar, or how tall that person is, or how much does that thing weigh. What we are bad at is absolute estimates. To make up for that, we are really, really good at relative estimates.

Last time we looked at why we estimate and why there is always pressure to make our estimates more accurate. We have come up with a vast number of methods for estimation all of which aim to improve accuracy. The problem is that most of them don't. What they improve is precision instead.

Most people think of accuracy and precision as being the same thing. But they aren't. My nerdy and pedantic engineering background tells me that accuracy is how close to the true value a measurement is, while precision is a measure of how reproducible the measurement is. A more formal definition (thanks to Wikipedia) is -

In the fields of science, engineering, industry, and statistics, the accuracy of a measurement system is the degree of closeness of measurements of a quantity to that quantity's actual (true) value. The precision of a measurement system, related to reproducibility and repeatability, is the degree to which repeated measurements under unchanged conditions show the same results.

A couple of posts back I mentioned Estimation and my desire to poke a stick at the hornet's nest that estimation can be. Estimation is always a controversial topic. It's often at the heart of serious conflicts within organisations. There are a huge number of estimation methods and techniques but nothing seems to prevent these issues from coming up. Before I poke a stick into the hornet's next (well, not so much poke as take a full bodied swing with run up and follow through), I'll spend a little while looking at why we estimate in the first place.

Any time we have two parties involved in something there is estimation happening. Right back from prehistoric times -

Ogg - I estimate that this stone axe is worth the same as that reed bag filled with nuts so let's trade.

Ugg - I estimate that this reed bag filled with nuts is worth at least 2 axes so let's not.

Ogg - Seriously? You're taking food away from my family... these axes are the finest workmanship. Maybe one axe plus a flint scraper but that’s the best I can do.

And so on.

 

10 February 2014

To Task Or Not To Task

I have noticed a trend recently in the Scrum community of de-emphasising, or getting rid of entirely, the concept of Tasks. Teams are encouraged to just run with stories and no finer grained level of detail. I’m not sure this is a good idea. I do have to say here that when I say "tasks", I am not necessarily talking about technical tasks. A task (to me) is something of less than a days duration that needs to be done in order to get the story done. It could be a sub-story, a technical task or a single acceptance criteria, or whatever the team uses to break down the stories into smaller chunks.

One of the arguments for cutting out tasks is that it saves time in sprint planning. One scrum coach told me that “we can cut sprint planning down from 3 hours to just 45 minutes” by essentially cutting out the entire second part of the sprint planning meeting and just work out a list of stories to be done. That implies that the time spent breaking those stories down is waste. I don’t agree.

Calendar

« December 2018 »
Mon Tue Wed Thu Fri Sat Sun
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31