High-Low Story Showdown, Deal and Slide, Developer Guts, and Customer Guts

It’s sprint zero and you have a stack of stories needing their first estimate? You need an initial release plan. What should you do? It’s kind of hard to start on day one with Planning Poker. There is a missing baseline to estimate against.
Mike Cohn briefly describes Analogy as an estimation technique. With analogy, stories are sized by comparing relative size. This is the basis for Planning Poker, and the games introduced here as well. It’s hard to get analogy started just looking at individual stories; they have to be looked at in a group.

I’ve used analogy for years, probably since my first XP planning game. It must have been Ron Jeffries or Kent Beck that first showed me this estimation technique. We did not call it analogy. Lowell Lindstrom, my colleague at Object Mentor, called it affinity.

The way I have coach this is in two steps, call the steps High-Low Story Showdown and Deal and Slide. I know, Deal and Slide sounds more like a dance than a card game. Once the stories are estimated, you need to form an initial release plan playing two more games: Developer Guts, and Customer Guts.

Back to the problem at hand, you have a stack of stories to estimate so you can get an initial release plan together. Start with a game of High-Low Story Showdown.

Poker planning is a powerful tool to make faster and more accurate estimations. Most important of all, it is used to make the boring meetings fun again! This app can be used in scrum poker planning sessions anywhere.

If you’ve ever played poker, you may have played showdown. The way we play showdown, the dealer deals out cards face up, seeing who gets the best hand. Cards play themselves. It’s total luck. It’s how we divvi up the white and red chips that don’t add up to a dollar at the end of the night.

High-Low Story Showdown is totally different, it’s based on the skill, experience and intuition of the players. The dealer holds a stack of stories. The stories have already been explained to the developers around the table. Stories are dealt face up one at a time, just like in real showdown, except not to each participant. The stories are dealt to five different stacks on the table. Lay out five cards, marked like this:

• Low
• Medium
• Hard
• More info
• You must be kidding!

• Planning is essential for managers at all levels, yet many wrongly perceive it as a costly, time consuming, and difficult activity that provides only a marginal return on investment—in other words, a waste of time. But the fact that decisions can be made without any planning is no revelation; if it does not matter what is to be achieved or what.
• Welcome to pointing poker (aka planning poker)! Online, virtual and co-located agile teams use this application during their planning/pointing sessions to effectively communicate points for stories. Online, virtual and co-located agile teams use this application during their planning/pointing sessions to effectively communicate points for stories.

The markings represent the relative effort for the stories placed under that heading. The table looks like this. It helps to have a real poker table too. Click the image for a better view.

Objective of High-Low Story Showdown

To quickly sort a batch of stories, by relative effort.

Mechanics of Story Showdown

Dealer reads a story, quickly the participants suggest which pile the story goes in. There should not be a lot of debate. There will be time for that later.

After positioning all the stories during Showdown, you can play Deal and Slide.

Objective of Deal and Slide

To lay out all the estimable stories in columns of similar difficulty.

Mechanics of Deal and Slide

Someone grabs the stack of relatively Low effort stories and deals them out randomly on the table. The other stacks are moved out of the way. The More info and You must be kidding! stacks are given back to the customer for splitting at a later time.

You will probably need a bigger table for the Deal and Slide and subsequent games. A pool table works, and can be used for other purposes too. Have team’s manager get the a pool table with some of the extra time he’ll have because the team is self-managing :-).

Developers, in silence, start sliding the story cards around the table, putting the easiest stories to the left and the hardest to the right, forming columns of similar difficulty. Anyone can slide any card any number of times, but if a card won’t settle down, a Nervous Nellie, it should be taken out of play. Once the cards that can settle down, do settle down, talk about the Nervous Nelly cards and see if you can settle them. If you can’t it is a sign that more info is needed, or someone is kidding, so give those stories back to your customer for refinement.

The resulting arrangement looks like this, with the easier stories on the left, and harder stories on the right. As you can see, you may need a pretty big table.

Repeat the process with the next stack of cards. Don’t worry if you find some Lows in the Mediums, Mediums in the Highs or vice versa. It will all work out.

With all the Low, Medium, and High stories laid out, it is probably not a bad idea to go back and look over the columns and decide if the stories are placed correctly. Next, the columns need headings.

Planning Poker Round

In this round, label the headings of the columns with their relative estimates. Use Planning Poker to estimate the columns. Don’t use a time based unit, use Story Points. It is likely that the first or second column should be labeled difficulty 1 story point, to use as an estimate baseline. Check the column to the right of the 1’s, it will probably be labeled with a relative effort of 2 story points.

Going from easier to harder, play a hand of Planning Poker for each column of similar difficulty. Use the normal Planning Poker rules:

• Each player has a hand of Planning Poker cards. Use a sparse set of numbers that shows that the precision is reduced as estimates increase in relative effort.
• Each developer selects their estimate for the column from their hand.
• All at once, the estimates are shown.
• Discuss differences.
• Continue until convergence.
• It is fair to move cards between columns if it breaks an estimation log jam.

Notice that this perspective is a good representative of each column’s estimation accuracy. Things that are smaller are better understood and closer. They are easier to see, like the 1’s, 2’s and 3’s. The bigger things are less clear and more distant, like the 10’s, 15’s and 20’s.

Write numbers on the cards

Write the story point estimate on each of the cards in a column.

Objective of Developer Guts

To make a decent educated guess at the teams velocity (number of story points completed per iteration).

Mechanics of Developer Guts

This does not play anything like any of the variations of Guts I know of. But you need some guts to play. It takes a well developed gut feel and some real guts to estimate a decent initial velocity.

Look in the backlog of estimated stories for the ones that are better understood. Choose a set of stories that the team thinks they could complete in a two week period (assuming a 2 week iteration). Add up the numbers. That’s your first velocity guessimate. Grab another set of stories that add up to the newly guessed velocity. Does the team think that those stories can be completed in a two week sprint? For more confidence, take the selected stories and break them into engineering tasks. Do you still believe it?

Oh, yeah. Once you have completed a few iterations, you will stop playing Developer Guts and use the measured velocity (the actual number of completed points in the last iteration).

Planning Poker Baseline Games

Objective of Customer Guts

To put together a release plan that delivers the most value for the effort expended.

Mechanics of Customer Guts

The customer (team) forms groups of stories to deliver each iteration. The total of the story points per iteration cannot exceed the velocity. The iterations are ordered in time, with the first iteration to the left. The stories in the first iteration must be well enough understood to work on them. Stories in the later iterations are likely to contain more vague stories. No problem though. This is not THE plan, but the best plan we know right now.

BTW: By getting the development team started on the first iteration, the customer buys time to work out those bigger estimate, More info, and You must be kidding! stories.

The customer needs guts, skill, vision and authority to play this game.

When to play a second game

Planning Poker Baseline Meaning

You will want to play the planning game regularly. You will play on demand, a little every iteration and a bigger game every few iterations. This helps keep the plan fresh, taking advantage as new knowledge is acquired. Straight Planning Poker, right out of the box, will work fine once you have a backlog to estimate against.