In Extreme Programing (XP), one of the key elements is planning. Planning involves both discovering what the customer wants and estimating how long this will take to do.
Customers divide up the work to be done into a set of stories, each of which can be written on a 3 by 5 card in a few sentences. The developers then estimate how much effort is required to build each story. The customer then chooses which stories she wants built in the next cycle, based on the time available and the estimates from the developers. This is a brief outline of the Planning Game.
At OOPSLA 2000 Educator's Symposium Kent Beck led an exercise that can be used in the classroom to teach the Planning Game. From this I have extracted a classroom exercise that you might use. It is an example of the Pedagogical Pattern Icky Poo. The exercise will take about one hour of in class time.
This exercise can be done after a brief introduction to Extreme Programming, but does not depend on any programming ability or any design ability or ability to use or understand design tools. It carries out a complete iterative development process in one hour and is known as an Extreme Hour.
Divide up your group of students into teams of about 7-8 people. Two of these are to be customers and they should sit where they can talk. Two of the students are to be monitors and they are to keep everyone honest. They make sure there is no coercion in the estimates or in the requirements, for example, and they judge whether the rest of the students in the team, the developers, have actually built what the customers want. You are then left with about 5 developers on each team.
The instructor needs to provide a place for each team to work, though this may just be a corner of the class room. The instructor also provides about 20 or so 3 by 5 cards to each team. Each team will need at least one watch that tracks seconds. Even better, but not necessary, is a stopwatch.
Customers, of course, specify things, and developers build them. The idea here is to "build" a coffee maker to the specification of the customers, where build here means that the developers will draw a picture of the desired machine incrementally. The task will be carried out in two cycles, each with two parts. The first cycle is a bit different from the second. While the teams are working the instructor may be called upon to answer questions about the process.
In the first part of a cycle, the customers have 10 minutes to write one sentence specifications of some feature of the desired coffee maker on one of the cards. How simple or how complex the coffee maker is to be is up to the customers. Each card is called a story. They may have 6-10 such cards, with one sentence each. The monitors make sure that the customers specify things that can be drawn and that aren't too open to misinterpretation. The cards are passed to the developers as they are created and the developers write on each card a time in minutes that they think it would take them to draw that feature. At the end of this phase you have a few cards in each team with a sentence description of a feature and a time in minutes that the developers expect to take to draw this feature.
Of course, the developer are free to ask the customers for clarification and rewriting of the specifications if they are not understood. If the customer asks for something very big or very difficult to estimate, the developers are free to ask the customer to split the description into smaller tasks. The developers may also indicate that a requested feature can't be built as specified, and the customer can either drop it or rewrite it. The developers may also sketch to help estimate the drawing time for the final result.
The monitors assure that the customers don't estimate and that the developers don't specify. They also assure that no one tries to intimidate someone else ( "Waddya mean 3 minutes? I could do it in half that time." Or possibly "I think self cleaning is a really dumb idea. You can't possibly want that." )
In this part the developers decide on how many minutes of effective effort they think that they can deliver in a 10 minute "build" iteration. This must be a number less than 10. Then the customers spend a few minutes selecting the stories that they want developed, up to the limit given by the developers. They take the cards representing the most desirable features to implement now and the estimates on each card to do this.
The monitors assure that the sum of times on the chosen cards is not more than the promised effort number.
The developers then take the cards from the customers and draw the coffee machine described in the cards, by choosing any ONE of the cards and drawing that on a clean card, then choosing another and redrawing the machine as necessary until the time runs out. The stories on the cards are thought of, estimated, and built as if they were independent of each other. The monitors help assure this.
If the team completes early, they may ask the customer for more work. They should, and may, ask the customer for additional clarification whenever necessary. They may also get feedback from the customer as they go along as to whether the machine being drawn is acceptable. They may throw away work or redraw as they see fit, based on what they learn from the cards or from the customers.
While this is going on, the monitors again keep everyone honest. They serve as time keepers and may also announce the time remaining in this cycle. They make sure that the customers don't require things that they didn't specify. To make this true to XP, the monitors should also attempt to assure that the developers work one story card at a time, rather than trying to draw everything in a set of cards at once.
The customers should be getting questions as this goes on, but if they have time they can write additional stories.
In the second cycle, the customers may write additional stories and have them estimated. They may also discard cards. The developers again estimate the new stories and may revise estimates on any of the existing cards. But again, the customers choose a set of cards with estimates up to some effort number given by the developers.
Now the developers attempt to build the machine described on the new set of cards extending the work done in the first cycle.
At the end of the second cycle the developers should have built a machine to the satisfaction of the customers up to the level of the work effort commitment. This may not be all of the story cards, of course, but it should be the cards of most "value" to the customer. The remaining cards are of lesser value if the customer has been wise, and the machine will actually be delivered if the developers were wise.
The instructor should allow time at the end of the period for discussion and questions on the process. Did the developers build what the customers said they wanted? Were the customers happy with the result? Was everyone honest? Were deadlines met?
At the Educator's Symposium the participants actually did this exercise. If you turn the page, you can find one team's results.
At XPUniverse 2000 I did this with a small group. I used some slides and handouts. If you turn this page you can find them.
Extreme Hour on the wiki web: http://c2.com/cgi/wiki?ExtremeHour gives an outline of what we have here with some variations. Extreme Hour was invented by Peter Merel and a crew at Websense (http://www.websense.com). An extension of this can be found at http://www.c2.com/cgi/wiki?IronGeek. The Extension attempts to compare methodologies and is quite a bit more elaborate.
Planning Extreme Programming by Beck and Fowler (Addison Wesley, 2001) talks primarily about the planning game.
Extreme Programming Explained by Beck (Addison Wesley, 2000) gives a good overview of Extreme Programming.
You can read about some Pedagogical Patterns and Icky Poo in particular at: http://csis.pace.edu/~bergin/patterns/fewpedpats.html
There is another, somewhat similar, exercise called the XP Game. It doesn't focus quite so much on planning and isn't quite so comprehensive, but is useful in training customers to be part of an xp team. You can learn more at http://www.xp.be/
Last Updated: July 27, 2001