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.
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!
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).
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
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.
James–
Interesting variations. Lowell Lindstrom, whom you reference, introduced me to a variation mostly of what you call Deal and Slide. I’ve used it in a few cases where we needed to get a quick sort of stories. I consider it a useful technique when getting the initial size of an entire product backlog is more important than fully understanding all the stories in that product backlog. Planning Poker itself is still best when deep understanding is critical. However, that isn’t always the case–I’ve been on projects where we’re just trying to get a very rough estimate so the Big Boss can decide if a project is worth doing at all. In a case like that, I’ll grab a few people who will be similar to the staff who may start on the project in 3-12 months and have them estimate things. They don’t need a deep understanding, just enough to put some sizes on things. Techniques like you describe here will be very useful in an environment like that. Thanks for sharing these.
I really like physical techniques for planning and estimation. This sort of activity forces more body movement and in my experience that always results in greater team focus and commitment to what-ever objective you are trying to accomplish. Using tables and the team physically moving stories around I think is an awesome way to achieve better estimates and buy in. I do look forward to trying these!
When playing the Developer/Customer Guts games how do you ensure that misunderstandings do not emerge with customers? In my experience, the estimate for any story is probably a good most likely (mode) estimate. The distribution however is typically lognormal rather than normal as usually there is considerably more down-side than up-side with any time based estimate. What can happen then is that a team will over-commit early in the project. Do you defer the Customer Guts game then to give the team a chance to learn their velocity?
Thanks James!
Pingback: Estimating stories faster and more accurately « Tiago Motta Jorge’s Blog
I’ve found those companion games just awesome! But I have one question: how should I proceed in the next release planning so that the estimates remain in the same scale? Because if I just start with no stories already estimated, the scale can change, and the mean velocity will tell us nothing. Should we use the stories of the last sprint to help us keep the scale?
Hello Tiago
The short answer is that anytime you need to baseline your estimates you can host a planning poker party using the needed games. But it sounds like your team could benefit from having a longer backlog. If the backlog is only an iteration or two in length, then it is highly likely that the most important/valuable work is not in the backlog.
A healthy backlog extends well beyond the next iteration and likely into the next release. The length of your backlog is largely dependent on the needs of the business (and maybe engineering) to see what is coming. But if it is made up of only the things that the business happened to think of just in time to get the developers something to do, then it is likely less valuable than a well groomed backlog.
With an appropriate length backlog there should be plenty of stories to use for reference.
I am glad you find them useful.
James
Pingback: Kirk Thoughts » The Road to Scrum is paved with Lego
Pingback: Kirk Thoughts » Daily post (weekly)
We used this in our planning game this week and found this method very helpful. It was much easier to assign points to stories once they were grouped by relative effort. Thanks for the great idea.
Pingback: Agile Projects and Portfolios » Blog Archive » User Story Sizing Game
Awesome article! I just have a little doubt: after grouping the stories in columns during the Deal and Slide game, I should do planning poker, ok. My doubt is: should I do a planning poker for each story from each column or should I do a planning poker session to each column?
I think that I should do a planning poker session for each story, and not for each column, it’s weird doing planning poker for a column (or group) of stories, as a column does not have a scope or something that I can measure, as size or complexity.
Am I misunderstanding something here?
You got it right Hugo. When estimating a big group of stories, its helpful to group by similar effort, then guess a point value for each story column. You could use a planning poker approach to putting an estimate for a column, or just start with 1, then discuss and decide each column after that. The point value assigned to the column represents the effort for each individual story.
Traditional planning poker is works great for smaller numbers of stories. It helps to have a relative effort baseline established. The planning poker party is about getting a big group of stories estimated and establishing that baseline.
Hi James, your initial article “Planning Poker or How to avoid analysis paralysis while release planning” is a reference. I’ve translated it in french : Planning Poker ou Comment éviter la paralysie
lors de la planification de version Best regards, Fabrice
Fabrice
thanks for the translation!
James
Pingback: camestres.com » Links for 16/9/2010
Super article and images! I’ve been looking for a thorough description of Deal and Slide for some time, feeling I was missing something. I now see it’s just one step in a series that together provides a complete view of the “forrest & the trees.”
Have you ever tried to do some variation of this in a distributed environment?
Pingback: Rapid Scrum Poker | Evolve Beyond
Pingback: Dan Greening - Bulk Estimation
Excellent article and ideas. I like anything that makes getting through “too much stuff” very quickly. I want something of reasonable potential value to work on ASAP. For me – it is only when we get something that is actually usable by a “real user” that we start to learn what we should be creating.
Your techniques are perfect for quickly moving from “have an idea” to “have something we can code.” I LOVE that. In an environment where release planning is needed, these techniques should also provide “just enough” process to continue forward motion and please everyone with only a minimal investment in time and effort.
The “High-Low Story Showdown” game is a great way to start. I think I naturally do this (in a less formal manner) and it’s nice to see it defined in a way that anyone can quickly try it. The idea is to pluck out the things we can work on, and throw back the stuff that isn’t yet small enough to work on. It’s really waste to put any time on those things except to slice off some small part.
Next – the “Deal and Slide” is great – and should quickly fine-tune our list into “the stuff we can work on right now”, and “stuff that’s a little bigger but we can start getting familiar with”. I love it.
After that, I am no longer using velocity or even “how much to take on for this iteration”. We just pick up work more or less one item at a time (in reality, it’s a bit more complicated than that, but conceptually – thats our approach) and do it “beginning to end”, and then repeat. Some people call this “kanban”, but “kanban” is starting to mean a LOT MORE than what it used to mean. Still, for others who use velocity and release planning it looks like a good approach.
When working with our “customers” in my current situation, I focus on finding something that the team can do that can be put into use right away if it were available, that the team can most likely do quickly, and that has high potential for being valuable to the users. I want working code (that is: code that is built and doing REAL WORK) as quickly as possible. And then I follow Jim McCarthy’s rule: regularly add more functionality, and never let it get broken.
All good stuff.
I participated in an agile-scrum group that implemented much of these lean methodologies. This department was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User’s Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner. They accomplished this by the following practices and some others:
An analyst prepares some ideas for a project’s features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role’s work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone’s time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role’s work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User’s Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn’t going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.
Sorry, I did not have time to explain fully as I’ve got work to do before I go home, but while we did an estimate on the entire product, [Cardiology software that was a patient record, drug-drug interaction, prescription sender, billing, ECG and other device integration, etc., etc., that is, a big product] we did not do any planning poker game or variation ever, but had ACCURATE estimates by using the Feature Blitz as our method, meaning the one who was going to program the feature gave their estimate after domain experts and others (QA & Analysts) all mentioned ramifications of the code changes.
In two and a half years (including when we first started our scrum-agile-lean hybrid), we were only later than “a single day” on one sprint and less than a day late on three sprints (once was due to hardware load testing that uncovered a need for a hardware change). All other sprints were fully completed on time, with most sprints having work from the subsequent sprint started. (Our sprints were 2 weeks.)
Hi James,
in a nutschell, Planning poker is a tool to manage KPI in an Agile environment.
Have you ever tried Delegation poker, a tool to manage relationships among members of an Agile team ?
Best regards
Tru
PS : Delegation Poker’s creartor is Jurgen Appelo, Netherlands