I typically ignore planning in this blog. Not because it isn’t important, but because it isn’t important until later. You need to be able to deliver if you want your plans to mean anything.

However, there is one topic that I think worth discussing: estimating your work. I find this worth discussing because I see so many people do it wrong and suffer massive pain that they could have avoided.

Which causes deadline pressure. Which prevents them from making the improvements that would help them deliver.

Key concepts

Start by reading all of James Shore’s Art of Agile Development. It is on Amazon; most of it is also online at http://www.jamesshore.com/Agile-Book/.

The key ideas are in 3 chapters. However, they are in section 8 and build on the stuff that came before. So read the book. This particular topic is covered in:

• http://www.jamesshore.com/Agile-Book/stories.html
• http://www.jamesshore.com/Agile-Book/estimating.html
• http://www.jamesshore.com/Agile-Book/iteration_planning.html

The big idea is to stop trying to estimate in actuals. Humans are bad at that (see the Planning Fallacy, a recognized psychological bias).

Instead estimate in relative units (I use inches), and then measure your velocity (number of inches delivered per week). This uses the brain for the part we do well and uses data for the part we do poorly.

What about #NoEstimates?

Hush. I’m ignoring you (for now).

Yes, I do believe in #NoEstimates. That whole Naked Planning thing (one of the ideas that merged to become Kanban) was all about replacing estimates with data and always working in order of value / risk.

But working in a #NoEstimates style requires one key skill: vertical decomposition.

Vertical decomposition takes a long time to learn. Learning it requires feedback. Making estimates is a great way to get feedback. Difficulty agreeing on an estimate indicates that our story is too large or too vague.

That’s our test for decomposition: it is trivial to estimate and we all agree on the size.

So before we eliminate that feedback, let’s make sure we’ve learned the skill. Once we no longer need that test in order to always have good stories, then see if there is any other reason you need a per-card estimate (as opposed to a data-based projection). There probably isn’t, and so #NoEstimates makes sense.

A fast way to estimate

The fastest way to estimate in relative units is:

1. Generate all the stories. Make a big deck of cards.
2. Clump the cards by size
   • You are going to place all the cards into a line of piles.
   • Each card in a given pile is about the same size.
   • Each card in a pile is bigger than the ones in the piles before it and smaller than the ones in the piles after it.
   • Accomplish this by going around the table. Each turn, the current player makes one of the following moves:
     1. Read a new card and place it into any pile.
     2. Move one card from one pile to another.
     3. Move one card from a pile to a “contested pile.” Basically, this is saying that we seem to disagree on the size of this card and will need to discuss it separately.
     4. Pass.
   • No talking during the placing of the cards, except to read what is written on the card. Just set them down. Go fast.
   • Play ends when everyone passes.
3. Now go through the contested pile. Discuss them. Most often, the reason you can’t agree on a size is because they are too big and too vague. So break them into pieces and try to place those. Repeat until all cards are placed.
4. Now we will assign estimates.
   1. Pick one random card from each pile. These are your canonical samples.
   2. The card in the smallest pile is defined to be 1 inch long; assign this size to every card in that pile.
   3. Ask how many inches long the next sample card is; assign this size to all cards in that pile.
   4. Repeat until all cards have a length.

You are done. You should be able to estimate a year’s worth of work in about 30 minutes (if the cards are mostly right and small).

Because your cards/stories will initially be way too big, you will spend longer—but all that extra time will be spent doing useful work: breaking stories down so that you can understand them, narrowing the scope, and finding a way to deliver the easy parts without the hard parts.

Keep your sample cards around after the first week. In later weeks you start each pile with the one sample card, which includes its size. You sort the cards into these piles.

This keeps your estimates consistent over time: 1″ measured in June is 1″ measured in September. We just may move faster (more inches / week) in September than in June.

Estimate value too

BTW, the same process works for estimating value. Just have the customers play the same game. Use some other unit; I like martinis.

In fact, have them play it first. Disconnects found while estimating value lead to vertical decompositions. They break a story into the more and less valuable bits.

This lets us measure value velocity (in martinis / week!) and do the most valuable work first.

Planning guidance

Here’s the sum total planning guidance I will give to a team until it has mastered delivery:

• Plan the same way you always have. Waterfall is perfect as long as you still have execution phases. Don’t listen to us Agile twerps.
• Oh, and stop having phases in your execution. Plan waterfall and execute with simultaneous phases. Once the phases are gone, waterfall is iterative planning.
• Estimate in relative units to avoid the planning fallacy. Use concrete units to avoid fuzziness. Inches and martinis are great because everyone knows what they are.
• If you can’t agree, then break it up. Vertical decomposition is the key skill to learn; the rest of planning is just feedback on, and taking advantage of, your skill at vertical decomposition.
• Estimate value always. Estimate value first. Once everything has a value estimate, do a cost estimate if you are still learning to decompose.
• Generate relative estimates using the above approach. It is the simplest and fastest that I have yet found.
• Don’t worry too much about planning or estimates. The big gains come from working as a team, from execution, and from customer interaction. Planning is a small lever that aids discussion and makes it easier to have the whole team work together.