How Caveman Size Big Work
TLDR: Estimating the size of things is hard. Saying if one thing is bigger than another is a lot easier. You can use this to rapidly size a backlog of work.
When you are a caveperson roaming around, away from the safety of your family group’s cave with its strong walls and roaring fire, the ability to assess comparative risk is essential. Luckily, evolution provided humans with exactly that ability.
Whilst we’re less likely to find ourselves in life or death situations where we need to rapidly assess risk these days, we can leverage this capability to help with software development using a technique called relative sizing.
Why would I want to do that?
Well, when you’re making product and software development decisions, it’s useful to have a rough idea of scale.
From a product perspective, a feature with some business benefit might be worth prioritising or pushing back depending on its size.
From a software development perspective, it’s a good agile practice to tackle the hardest and riskiest areas first and the size of a feature may be a good indicator of difficulty and risk.
Sounds great, but why wouldn’t I just estimate a time?
If you need to do time estimates, that’s fine, but be aware that it will take you longer, you will tie yourself up in knots trying to be accurate, and worst of all you’ll be wrong.
For the purposes of a quick overview of a whole bunch of work for prioritisation purposes, you are best off keeping the sizes abstracted away from time estimates. You don’t need to have a detailed estimate for prioritisation purposes, so why maybe your life difficult?
Oh, and if you write down time estimates against a bit of work, you’re likely to be held to it, and you have no idea if it’s any good, so why create a hostage to fortune?
OK, I’m sold, tell me how to do it
Get people in a room - gather as many people as makes a good diverse team into some kind of room or online call. You need a mixture of disciplines to get the full benefit of the exercise.
Get everything out in the open - Lay out all your components and features out in some kind of shared workspace. Cards on a long table or a virtual whiteboard will work. You need somewhere were a bunch of people can gather together and handle the cards at the same time. Be careful about using the floor as some people may not be able to reach down and this is supposed to be an “all play” activity.
Rank the cards - Get everyone to order the cards from smallest to largest. This is a “forced ranking” activity, where everything is laid out in a stack, smallest through to biggest. This is the point where someone will say “so what is a small then?” and you get to say that it doesn’t matter; all you care about is whether any given card is bigger or smaller than the other cards. At this point I normally take one obviously huge card and put it at the top of the stack and say that it looks like the smallest; someone will immediately intervene to stop your madness!
This stage of the process comes with rules. It is forbidden to put two cards side by side. If people say they don’t know,, once again, be provocative and say that it must be really small and see whether that unsticks the thought processes to allow people to guess.
This is the hardest bit of the process, but the moment someone touches a card it will start to flow. Reassure the team that it’s OK to guess; this is a quick and dirty exercise to establish an initial order.
Check for outliers - Next ask the team to look around the ordered list and tilt any cards that look like they’re in the wrong place. Then, after a couple of minutes, work through the tilted cards and reorder them as necessary. This review helps to tease out any misperceptions about the features and gets everyone comfortable that the ordering is about right. This stage should result in some cards being moved up and down within the order.
Split the ordered list - Arbitrarily split the list into the sizes you want. Most people think about a scale of “extra small” through to “extra large”; there’s a reason they sometimes call it t-shirt sizing! Just divide the stack into some equally sized sections and call them Extra small (XS), Small (S), Medium (M), Large (L), Extra large (XL).
Review the sized groups - Get the team to look for any cards that are obviously a different size to the other sin the group and move them into a better group. the idea is to get to a point where each group has cards that are of similar scale.
And there you have it, a full backlog sized in the kind of session that can be done in a focussed session. If you’re planning one of these sessions, I’d reckon on about an hour and a half to get through the steps above.
Now, armed with these sizes, you will now be in a better position to prioritise the work and the fun really begins. Good luck!
