Section 17.4. The Planning Game

17.4. The Planning Game

The next morning, the whole team got together for the planning game for the next iteration. Between them, Seth and Mitra introduced each of the new stories, as they placed the story cards on the table.

Note

The planning game is where the next iteration is planned. The Customers present a number of new stories, which are added to the old stories that haven't yet been chosen for implementation. The developers ask questions about each new story in order to estimate the time it will take to complete it.

Once the new stories are estimated, the Customers pick sufficient stories from all the stories in order to fill up the time available in the next iteration, based on the story time estimates.

Hence, both the estimated business value and the estimated development cost are taken into account in choosing the highest-value stories.

17.4.1. Previous Rentals Repeated

When the rerenting story was introduced and tabled, the testers and programmers had a few questions. "What happens if some of the rental items are not available?" asked Emily.

"I suppose, then, that the customer has a choice whether to cancel, just as with a single item," replied Mitra.

"Yes, it's not much different," agreed Seth.

"The customer may still want to rent everything else he or she needs," added Mitra. Don made a note of this test on an index card.

"Does this apply to bookings as well?" asked Sarah.

"That's a good idea," replied Seth. "Yes, it does," he added after a few moments. Don noted this on another card.

After some discussion among the programmers, Emily was ready to provide an estimate for the story. "It will take 5 days to do that, as it will require several changes to the GUI." She added that to the card.

The testers discussed the time they needed to allocate to writing the Fit tests. "Let's allow 1 day for that," Don suggested, "as I can imagine that there are several little cases." He started to write that on the card and then changed his mind and corrected it, "No, let's allow 2 days, as we often take about half the time of the programmers."

17.4.2. Templates

When the first template story was introduced some time later, there was lots of discussion about it. As Emily pointed out, "It's related to that earlier, rerenting story. Maybe they're trying to achieve the same thing."

"Possibly, in some cases," Seth answered, "but there would also be casual renters who want simple repeats."

"But if they keep rerenting and adjusting the numbers, it could indicate that a template is needed. How about generating a template from a previous rental?" asked Emily.

"Good idea," replied Mitra, "We'd simply need to know how many people were catered for."

"Of course," added Sarah, "the proportions would probably need adjusting."

"Yes, true," replied Mitra, "although that's needed anyway." With Seth's agreement, Mitra wrote a new story card:

MakeTemplate. A template can be generated from a previous rental of several rental items. Given the number of guests, the template proportions are calculated automatically.

"Once we have lots of templates, we need a way of organizing them, so that they can be found," said Emily.

"In that case, we need another story," Mitra replied.

After further discussion, Mitra wrote another story card:

FindTemplate. A template is found by name. It may be associated with a particular customer or may be for any customer.

"How many are there likely to be?" asked Sarah. "If there aren't many, we can simply list them. Otherwise, we may need something more sophisticated."

"Let's do the simplest for now," Seth suggested. "Once we've shown the new version to a few companies, we'll get feedback on what may be required. But they probably won't know until they try it out for a while."

17.4.3. CreateRentalTemplate

The group's attention then returned to the CreateRentalTemplate story. Emily was concerned about the calculations: "When we calculate the number of rental items, do we round up to the next highest whole number? For example, if there is a coffee dispenser for 20 people and there happen to be 30 guests, do we allocate one or two?"

"It will need to be two," replied Mitra, "so that there are sufficient numbers. The customer can always decide to reduce it to one."

"What if there are 21 people?" asked Emily.

"It's still two rentals," replied Mitra, "The principle still applies. We'll write a few tests that show this."

"We didn't work out what to do when a fixed number of rental items is needed, regardless of the number of guests," raised Seth.

"The simplest approach would be to say that the rental item is for 1,000,000 guests," suggested Sarah.

"Yes, that will do for now," agreed Mitra.

"It's also possible to have an item for less than one guest," introduced Don. "So the number could be, say 0.9."

"What does that mean, Don?" asked Emily.

"It means that more than one cup is needed per guest. For example, with 100 guests, we'd need 100 divided by 0.9 cups, which is roughly 110," replied Don. "So we'll need a Fit test that shows that, too," he said, as he picked up another card.

"Are the rental item numbers always based on the number of guests?" asked Sarah. "What about where the number of data projectors depends on the number of tracks of a conference?"

"Good point," replied Don. "We could have someone renting some things based on the number of guests and other things based on the number of tracks. That could mean distinguishing between people and tracks when the templates are created."

"Let's keep it simple for now," suggested Seth, "Let's see how well simple templates are used before we make it too sophisticated."

"OK," replied Don, "We'll write a story card for that as a reminder for later. Let's change the test to read better." The test in Figure 17.2 was revised, as shown in Figure 17.7.

Figure 17.7. Create a Template, Altered Again

The estimates were then made for the main story. "That'll take 7 days," Emily suggested, to general agreement. "And 3 test days," added Don.

17.4.4. Choosing Stories for the Iteration

Once all the stories had been discussed and estimated, Mitra and Seth started moving the cards into several groups on the table to help decide which were the highest priority (best cost/value ratio) and which of those would fit into the iteration period of 4 weeks. The rerenting and first two template stories were deemed to be of high priority and were included in the iteration.

Another story, on making regular bookings, was too big and wouldn't quite fit into the iteration, so it was split into two, and the two new stories were reestimated. The simpler one allowed for regular weekly bookings of the same rental items and was included, filling up the time of the iteration nicely.

It was agreed that Don and Sarah would work with Mitra and Seth to develop further Fit tests for the stories. They would call on the programmers to get involved once they started making progress.

"We'll do some spikes^[3] on the template story and a few of the others over the next few days, so that will keep us busy," said Emily.

^[3] A spike is an experiment with the software, such as to find out the best way to do something.

"And I'll have a chat with some of our clients to make sure we're on the right path," added Seth.

Questions & Answers

Q1:	Does developing software in this way lead to a narrow focus rather than seeing the big picture?
A1:	There will be lots of discussion about the big picture as well and about the vision for the software and what it will achieve. The important thing is that the feedback from the evolving system helps us to revise that bigger picture to fit the reality that unfolds. Setting priorities is very effective for using time wisely, and it's difficult to know what the best approach is overall without ongoing feedback. As John Gall says, as quoted in [Boo94], "A complex system that works is invariably found to have evolved from a simple system that works.... A complex system designed from scratch never works and cannot be patched up to make it work" (p. 13).
Q2:	Isn't it difficult to choose a few stories out of many?
A2:	It seems so, but Customers get good at it. Given that the iterations are only 4 weeks or so, it's not long before you can make your next choices. If a software feature, which comes from a story, turns out to be not useful in practice, not a huge amount has been invested in it. This is much better than having to make decisions about the whole scope of a project before it starts, as the feedback comes far too late.
Q3:	People are usually poor at estimating the time to implement software. What do you do about this?
A3:	Yes, that's true, particulary when they're asked to do so when much of the details of the requirements are unclear. The trick is to estimate in smaller chunks and to do it often. People get better at a task when they get regular, good, and immediate feedback.