Agile 2006: The Planning Game – Chet Hendrickson & Ron Jeffries

Tuesday 09:00-12:30

Abstract

This is a simulation of an agile project, to demonstrate the impact in business value of releasing earlier, the importance of knowing business priorities in order to get the most value and using velocity to estimate release dates.

Summary

This was one of the highlights of the conference for me. Ron and Chet have played this game over and over, and it clearly shows – it’s funny, it works like clockwork, and the messages reveal themselves through the game without needing to be called out. If you haven’t played the Planning Game, and you get a chance to attend one of their sessions, don’t miss it.

The planning game simulates the planning of an agile project. We are told that this project must be completed within six months. There are forty five “story cards”, each numbered, with different numbers in each corner, and our first task is to arrange them in six columns to show management how we will complete the project. Ron and Chet will play the roles of Management, as well as fickle Nature.

We know this is a trick but we can’t figure it out, so we arrange the cards randomly with more at the start and fewer at the end. Along comes Nature and tells us that in our first iteration, we completed four stories. This is disasterous – we had eight planned. The team next to us have completed exactly what they predicted. This is confusing, how are we supposed to know what we can get done?

One of the other teams informs Management that they are unable to complete the project within six months. Management, understandably, is not very happy. “How long do you need?”

“Seven months”, say the team. Hmm. Management decide that one extra month is not too bad, and the team have at least been honest enough to admit that they can’t complete the project on time. “But no longer,” say Management, “or you will be fired. Now plan your next iteration.”

We rearrange the cards for the next iteration, and Nature dictates that this time we once again complete four. We aren’t doing very well here. It’s clear to most people that we can’t complete the project in time. Management are even more impressed with the team who identified this earlier. The rest of us are in the doghouse. How long do we need?

Based on our past performance, we estimate that we need twelve months. With nothing else to go on, we simply use the number of completed stories – 45 / 4 = 11, with one left over. The group average is around nine. The team who asked for seven admit that they actually need longer. Management are not happy.

We break, and try to decode the numbers on the cards, but we can’t. We discuss what Nature was looking at when he came around to tell us what we’d got done. Was he doing some complicated math? We don’t think so. We don’t know. It’s frustrating, but it’s fun, and the lessons are pretty clear. How can you plan projects without knowing how fast you can work?

After the break, Ron and Chet tell us which numbers represents the effort required for the stories, and what our velocity is. Then they give us the chance to replan the project from scratch. Now it’s easy – we can complete in nine months. We argue over which of the stories should go at the beginning and the end.

We eventually put most of the big stories earlier since they represent more effort and more risk, so we should get them out of the way earlier. Then they suggest that each story could have equal value, which would mean we’ve really messed up.

This is another important lesson, and the game drives it home perfectly. We can’t guess the business priorities. If we don’t know them, how can we effectively plan the project?

We finally get this final piece of the puzzle, and they share with us how the value of the stories is represented. Now we can plan properly, and make sure we get the most value for the least effort in the first iteration.

The final exercise is the most powerful. We need to decide when to release.

Ron has created a spreadsheet that graphs the value realized by the business depending on the release date. The logic works like this:

  • Each month, development costs the company x units
  • Each month, the released features generate the company y units
  • Y is the total number of units of value released so far
  • The highest value features are completed in the first iterations

Key points to apply

  • Focus on reducing release time – ultimate goal is to release every sprint to maximize business value.
  • To maximize business value, it’s vital to stack rank stories based on the maximum value realized for the least effort