Lean Thinking

Written by Published in Agile

Over the last 6 posts, I have been looking at estimation. First, we looked at why we estimate, then we looked at some of the pitfalls in traditional estimation methods - the way we mistake accuracy for precision. Then we looked at some of the Agile estimation techniques - story points and T-Shirt sizes and the way they are designed to overcome the accuracy vs precision problem. We saw that while they generally do a good job, they also have some fairly serious pitfalls of their own. In the last two posts, we looked at taking T-Shirt sizing one step further and allowing only two sizes - small and extra-large (too big). By doing this we saw how the main pitfalls in the agile estimation techniques were overcome. We also looked at some of the main objections to story counting and my arguments on how these objections can be overcome.

I'm not the only person to come up with this technique. It's doing the rounds at the moment under the name "No Estimation Movement". Apparently I'm part of a movement. Cool.

Written by Published in Agile

In the last post, we looked at estimating by essentially not estimating. To do that we broke down stories into two categories - small and the rest. Small stories were ready to be accepted into the team's backlog, the rest were too large and need to be broken down further. By doing this, velocity becomes just a count of stories completed and all the hassles involved with story point estimation just go away.

To me, this is a real no-brainer. Why wouldn't you estimate this way? But whenever I mention this in polite company, I tend to get some uncomfortable silences, strange looks and the inevitable - "but....". These buts, tend to come in three types -

Written by Published in Agile

 

Last time we looked at T-shirt sizing and some of the benefits and problems that method has. We found that its greatest benefit was also its biggest disadvantage. The use of something completely abstract (T-shirt sizes) removes all our cognitive biases around numbers but by not using numbers we can’t really compare estimates against each other and make predictions except by converting back to numbers which of course brings our biases back.

We can use T-shirt sizes usefully if we make an adjustment to the scale we use. Rather than have Small, Medium, Large and Extra Large, let's just have Small and Extra Large. Now, this would obviously never work for clothing because people come in a range of sizes. Stories come in a range of sizes as well, so what gives? What makes this useful? The trick here is that unlike people where we can’t dictate what size someone should be (outside the modelling industry and certain trendy nightclubs), we can, and should, be pretty strict about what size a story can be before we accept it onto a sprint.

Written by Published in Agile

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.

Written by Published in Agile

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.

Written by Published in Agile

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.

Written by Published in Agile

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.

 

24 February 2014

Story Smells

Written by Published in Agile

Most agile teams these days organise their backlog into user stories. The user story isn't mandatory in any agile methodology but they have become the defacto standard for agile projects. There are many good reasons for this, not least of which is that a well written user story keeps the focus squarely on delivering something of value to the user. Many user stories though are not well written. It takes more than using "story normal form" - As a I want so that I can - to generate a good story.

Many of the backlogs I see are filled with stories that, frankly, stink. Bad stories don't keep the focus on what is important. They distract, confuse and mislead. There are some criteria like INVEST that we use to assess user stories and properly applied they make a big difference to the quality of the stories. They do take some time to learn and apply though so I'll give you a few quick tips to get started. Over the years I have come across a number of common mistakes that teams make when writing stories that cause their backlogs to stink –

Calendar

« November 2017 »
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