The Bucket Theory

Over a year of presenting agile fundamentals to teams has taught me that the topic of estimation seems to strike fear and horror into people. The process of estimating seems to go something like this:

1. Pick a story
2. See the code base
3. Talk about how you would implement the story
4. Get the BA and beat them for exact details of how the solution should look
5. Get the QA and beat them for exact details of how they are going to test it
6. Wring hands for a bit. Panic a little
7. Assume because it’s in component A and Jeff is the component A guy, and he is pretty quick - maybe a few days?
8. Stick a finger in the air and say “Well 3 days X 8 hrs. is 24 so 24 hrs.!

Alright, maybe its not quite as painful as that for all teams but what if I told you that on at least one project I worked on we estimated a years worth of stories in a few days without actually knowing too much about them? In itself not that remarkable, After all we could have just randomly assigned numbers to them, but the really remarkable bit is we delivered almost exactly to schedule!

So, how should true agile estimation be done?

Focus on people? On your team, pick who you think is the best developer (A) and the worst (B). Now pick a story. How many hours would it take A to deliver it and how many hours would it take B?  Do we put two estimates on it? If yes, how do we forecast work? If no, how do we deal with the disparity between who is doing it? This often leads to last-minute estimation during iteration planning based on who is going to actually implement the stories – which short changes the business.

Or on time? Story 125 might be interesting to do if it takes 3 days, but not if it takes 6.  So immediately we have a problem with estimating in time. Though it is seductive and all teams try it for a bit.

Or a better way? Let’s say I am a voracious eater of fruit and let’s say my mate is slower than me. If it takes me 2 minutes to eat an apple, it takes him 4. Let’s suppose delivering your project is similar to us trying to eat all the fruit in a bowl. The pieces of fruit represent stories and I have some plums, apples, bananas, mangos and some melons.

I know a plum is about half the size of an apple and a banana takes about as long to eat as a plum. A mango will take me about twice as long as the apple and the melons about 4 times.

So I can allocate them into buckets that represent the relative size and complexity of the fruit:

Plum/Banana=1, Apple=2, Mango=4, Cantaloupe=8

But I hear you say – “Surely this is just working out relative size using time so why not just use time?” Because relative size remains the same no matter who eats the fruit. My mate who takes 4 minutes to eat the apple will take 2 minutes to eat a banana and 32 minutes to eat the cantaloupe but the relative size stays the same.

This approach is often easier, as teams can look at two stories and very quickly see one is half as complex or twice as complex as another. Without all the painful processing at the beginning! I have seen teams do this with hundreds of stories in a matter of hours. So, we now have a unit of size we can agree on, we’ll call them Story Points.

“But that doesn’t change the speed you and your mate eat fruit, right?” Well, this is the best bit, it doesn’t matter what speed the members of the team work at. If I break our fruit-eating task into iterations of 10 minutes, my mate and I can eat 15 points worth of fruit per iteration (I eat 1 point/minute and he eats 1 point/2 minutes) We’ll call this 15 our “team velocity”. As this looks at the team as a whole, it thus absorbs differences in speed between developers. In agile as always it’s all about the team! (If you are trying to work out individual velocities, stop immediately – it is the path to madness and creates underperforming teams.)

So let’s now take a look at the fruit bowl:

• 12 plums x 1 = 12 points
• 6 bananas x 1 = 6 points
• 6 apples x 2 = 12 points
• 3 mangos x 4 = 12 points
• 2 cantaloupes x 8 = 16 Points

The scope of our fruit bowl is 58, which isn’t divisible by 15 (our team velocity). As iterations are a bit like movie tickets (i.e. it doesn’t make sense to buy 0.866666 movie tickets) we round it to 4. We should thus have eaten all the fruit in the bowl in 40 minutes - our estimated release date.

This now empowers our product owner to work with the scope to adjust the release date. Add 6 apples and the delivery gets pushed by an iteration or remove both cantaloupes and deliver an iteration earlier, or take out all the bananas and 10 plums and add two more cantaloupes and we should deliver at the same time (though probably with an abiding hatred of cantaloupes).

Enough with the fruit!

How do we apply these techniques to our projects? 

• To start with, always estimate stories against each other, not individually. We thus need to have a frame of reference, to relatively “size” the stories. Pick a story that feels smallish (but not the smallest) and call it a 2. Use this as a reference.
• Relatively size each story against the bench mark story by discussing only the implementation details that affect its size. For e.g., if the decision to use SQL Server vs. Oracle doesn’t alter the story’s relative size, don’t discuss it. Capture all assumptions.
• Put each story into a bucket 1, 2, 4, 8 or 16.
• Try to keep your story size small. Ideally an 8 should be able to be delivered in one iteration. Anything bigger, and it’s best to use an “epic” to indicate that it needs to be broken down. 
• For each story bucket, do a quick review of the stories in them and their estimates. Are they all reasonably close in “size” to each other? Shift buckets if required. 
• Then work out your current understood scope just by adding up the numbers.

FAQs:

Q Why these buckets? What if we have a 100 point story?

It goes into the 16 Bucket. The 16 bucket is also a catch-all bucket for stories too big or too poorly understood to estimate. 

Q Why do we have such strict limits on the sizes of stories?

Primarily for the sake of accuracy. I can be reasonably accurate relatively sizing the fruit in the fruit bowl but once you start asking me “How many apples in the empire states building” I pretty much have no idea. So having stories that don’t size isn’t useful. They can’t be delivered in an iteration and inevitably turn into mini waterfall projects.

Q But, surely some of the estimates will be wrong?

That’s true, but once you have your estimates don’t re-estimate the stories. There is a simple reason for this. On most projects you’ll have a couple of 2 pointers that turn out to be 8’s and a couple of 8’s that turn out to be 2‘s. 

What happens when we permit re-estimation is probably pretty obvious – The 2 pointers become 8’s and the 8’s ….. stay 8’s. So by not allowing re-estimation we pay back the debt of the bigger than expected 2 with the smaller than expected 8 and everything just kind of works.