Chapter 23. A Case Study: Bomb Shelter Studios
The flight was a long one, but the conference had been a success. Flights back from the East Coast were always the hardest, but on this flight Frank had upgraded to first class, exchanging some of his frequent-flyer miles for a bit more room and comfort. Reflecting on the week’s events, Frank settled into his seat.
As a product manager for Bomb Shelter Studios, Frank knew that the company’s latest game, Deep Black & White, would do well. It played a game called Go that was extremely popular in Japan, China, and Korea but had only a moderate following in Europe, North America, and the rest of the world. The programmers on his team had come up with artificial intelligence breakthroughs that allowed Deep Black & White to play at a level known as 5-dan. This was still far from the 9-dan level of the best professional players, but it was far ahead of where any of Bomb Shelter’s competitors were.
Frank was ecstatic that Deep Black & White would be released and marketed in Asia through the distribution deal he’d negotiated with a publisher at the conference. The revenue from sales in those markets would really help Bomb Shelter. Frank knew that the additional six months it took to complete Deep Black & White had almost been the end of the small, privately held game development company he had co-founded.
From its inauspicious beginnings three years ago, Bomb Shelter Studios had become recognized as a high-end developer of thinking and strategy games. In addition to the newly finished Deep Black & White, Bomb Shelter had developed games that played chess, backgammon, reversi, bridge, checkers, mancala, and similar games. Once a game was developed, distribution rights were sold to a publisher that would take care of all production and distribution, allowing Bomb Shelter to focus entirely on developing new games.
While Frank had been at the conference, his analyst and small team back in Santa Barbara had been thinking about the new game, Havannah, that they were nearly ready to start. Because of the problems with Deep Black & White—not just the six-month delay, but also finding too many bugs and uncovering some usability issues late—Frank knew that they had to find a different way of planning and developing projects. Sasha, the company’s lead architect, researched some ideas the team had. She suggested using what they were calling an “agile process” for the next project. Frank wasn’t exactly sure what that meant, but he was sure they needed to do something different. Being six months late on the next game wasn’t going to work. Everyone on the team was excited to give an agile process a try, and they all knew what was at stake.
Day 1—Monday Morning
“Good morning, everyone,” Frank said as he entered the conference room. It was still a minute before nine, and almost the entire team was already waiting for him. That was a good sign. Even though the team was tired from the final push on Deep Black & White, it looked like they were ready to get right back in it for Havannah.
“Good morning, Frank. I saw your email about Deep Black & White. That’s great news on the distribution deal,” said Allan, the C++ programmer who had coded the artificial intelligence engine that let Deep Black & White play such a strong game.
“Have a donut, Frank,” Sasha said as she pushed the nearly empty box across the table.”
“Thanks,” Frank said, taking a maple bar from the box.
“Frank, this is Carlos,” Sasha said. “Carlos is an experienced agile coach. We’ve brought him in to help us as we learn to work in this new, agile way.”
Frank and Carlos shook hands and exchanged greetings.
“It looks like everyone is here except Rose,” Frank said. “Let’s go ahead and get started. We can fill her in later. We probably won’t talk about the artwork much in this meeting anyway.”
“We can’t start, Frank,” Carlos said. “This is important. We need the whole team here. A big part of the benefit we’re after from trying an agile process requires everyone to participate. Rose may not have much to say about the artificial intelligence in the move engine. But even so, we need her perspective if we want to plan the best possible game we can.”
“She always gets here about five minutes after nine on Monday. She drops Brooke at school on Monday, Wednesday, and Friday. She’ll be here,” Prasad said, finishing almost exactly as Rose opened the door to the conference room.
“Sorry. Traffic,” Rose said, quickly sliding into a chair.
“So, Delaney, you’ve been doing the product research on Havannah,” Frank said to the analyst. “It’s been a while since I’ve thought about that game. I’m sorry to ask, but can you tell me how to play it again?”
“Sure, Frank. First, the board looks like this,” Delaney said as she pulled a wooden board from her bag and placed it on the table. The board looked like Figure 23.1. “There are two players who take turns placing a piece on the board. Each player has different colored pieces. Once a piece is played on the board, it can’t move.”
Figure 23.1. An empty Havannah board.
“Just like in Deep Black & White,” Frank said.
“Right, but unlike in Go, pieces cannot be captured. The goal in Havannah is to be the first player to make a ring, a bridge, or a fork. Whoever does that wins the game.”
“And what are rings, bridges, and forks?” Frank asked as Delaney grabbed a handful of pieces and began to arrange them on the board.
“A ring is the simplest. It looks like this,” Delaney said as she drew Figure 23.2. “A ring is a set of connecting pieces that encloses one or more points.”
“OK, that sounds easy enough. What makes this game hard?” said Allan, who was already thinking ahead to the work of writing the artificial intelligence engine that would select moves.
“Remember, a ring is just one of the ways to win. You can also win with a fork or a bridge,” Delaney continued as she arranged the pieces as shown in Figure 23.3. “A bridge connects any two corners. The bridge could run in a straight line along an edge from one corner to an adjacent corner. More likely, though, a bridge will look more like this.” She pointed to the bridge on the right of the board in Figure 23.3.
Figure 23.3. A ring and a bridge.
“Does a player have to say which shape he’ll be trying to make before the game starts?” Allan asked.
“No, that’s part of the fun and part of the challenge. You can start out trying to make a bridge, realize that’s not going to work, and maybe try a fork.”
“So what’s a fork?”
“It’s like this, Frank,” Delaney said as she added some more pieces to the board, as shown in Figure 23.4. “A fork connects three edges, not corners. Corners aren’t edges, so they can’t be used in a fork—just in a bridge.”
Figure 23.4. The winning shapes in a game of Havannah: a fork, a ring, and a bridge.
“Programming the move engine is going to be a challenge. With so many possible ways to win and so many spaces on the board, the options are tremendous.”
“You’re right, Allan,” Delaney said. “Many people think this game is harder than chess because there are more options and because we can’t use a huge endgame book, like we can in chess. In chess, once we get down to a few pieces left, it’s possible to use a book of the best moves to play. At that point we don’t need to rely on just the move engine to select a move. With Havannah, there are too many pieces and too many positions.”
“You didn’t want an easy game to program, did you, Allan?” Sasha teased the other programmer.
Allan looked like maybe he did want an easy game to program this time.
“Don’t worry. The good news is that because so few people play Havannah right now, we don’t need as strong an engine as we did with Deep Black & White,” Delaney said, noting the slight look of relief on Allan’s face. “We’ll want to get there eventually, but we won’t need it in version 1.0. A decent engine that beats most humans most of the time will be fine.”
“OK, Delaney. Are there any other rules we need to be aware of?” Frank asked.
“No, that’s it. The rules are simple, but this game really makes you think. That’s why we think it will do well with customers who’ve bought our other games.”
“So, do you have a requirements document written?”
“Not yet, Frank. From what Carlos has taught us about agile software development, we want the whole team together to figure the requirements out collaboratively.”
“Right,” Carlos added. “We’re going to start today’s meeting by writing user stories. They’re brief statements of functionality but told from the user’s perspective. For example, As a user, I want to save a game I’m in the middle of. Stuff like that.”
“That sounds easy enough. What do we do with those once we’re done with them?”
“We’ll estimate each one, prioritize them, and then figure out the best tradeoff between features and schedule,” Carlos said.
“So how do we get started writing the user stories?” Frank asked.
“We’re going to use these note cards,” Carlos said as he tossed a package of cards to each person in the room. “I like to write user stories in this template.” Carlos picked up a marker and wrote “As a <user type>, I want to <goal> so that <reason>” on the whiteboard. “Delaney, you’ve done the most thinking about Havannah; can you get us started?”
“Sure,” the analyst said. “Let’s start with, As a player, I can undo a move so that I can take back a big mistake.”
“Is that our first story?” asked Prasad, the tester.
“Yes, so I’ll write it on a note card so we don’t forget it,” Delaney said as she wrote Story Card 23.1.
As a player, I can undo a move so that I can take back a big mistake.
“Do we estimate that story now?” Allan asked.
“Not yet, Allan. It will be easier if we write a bunch of stories first and then estimate them at the same time,” Carlos said.
“My turn. If we’ve got an undo story, we need a redo story. As a player, I want to redo a move that I’ve undone so that I can replay a sequence,” Frank said.
“Good story, Frank. Write it on a card,” Carlos told the product manager.
“Wouldn’t it be better if we typed these into a spreadsheet?” Frank asked.
“Perhaps later. But in a meeting like this, it helps to have the physical cards. You’ll see,” Carlos said. “We can each write any story whenever we think of it. We don’t need to wait for whoever is typing.”
“And when we get to planning, the cards are even more useful,” Sasha added. “We can stack the cards by priority or into what we’ll do in each iteration.”
Frank began to see some other advantages to using the note cards. He could write additional notes or draw on the cards. He couldn’t do that in a spreadsheet. He still hadn’t learned much about the team’s new “agile process,” but he liked what he’d seen so far. With growing enthusiasm, he wrote Story Card 23.2.
As a player, I want to redo a move that I’ve undone so that I can replay a sequence.
“A good way to get all the stories is to…” Carlos began.
“Do you really mean all, Carlos?” Sasha asked the team’s new coach.
“Yes. Kind of. I’d like to use this meeting to write as many story cards as we can. Undo and redo are pretty small. We don’t need our stories to be that small. In fact, we should probably combine undo and redo.”
“OK. I’ll do that,” Frank said as he wrote Story Card 23.3. “How do we indicate that this card is related to the other two cards? Do we number them?”
“No, just rip up the first two,” Carlos said. “We won’t need them.”
Frank ripped the first two cards in half.
As a player, I’d like to undo and redo moves.
“Carlos, Frank didn’t include a reason on the reason card. There’s no ‘so that.’ Is that a problem?” Allan asked.
“Hey, it’s only my second story!” Frank mockingly defended himself.
“Actually,” Carlos clarified, “we don’t always need a ‘so that’ clause. If it helps make the story more clear, use one. But it’s not worth worrying about, especially on a story like this one, where it’s obvious why a user would want to do that.”
“Carlos, you said we want to write all the stories today, even if some are written at a high level. I assume we can add more later. Right?” asked Rose.
“Absolutely. Ideally we do think of some additional stories later. Otherwise, it means we’re not thinking creatively enough about the game. I’d hate to think that we don’t come up with some ideas later that are better than the ones we start with today. The purpose of writing ‘all’ the stories today is so that we’re all aware—again, just at a high level—of what features are likely. This especially helps Sasha and Allan as they think about the architecture of the game and even how they’ll design the move engine.”
“OK. That sounds great, Carlos. Let’s keep going. Do we all just start writing cards?”
“We could,” Carlos said. “But it works best if we apply some structure to it. Let’s talk through what a user may want to do at various times in the game—before a game starts, during the game, and even after the game.”
Various nods and comments of agreement came from the rest of the team as Carlos continued: “Right when Havannah loads, what might someone want to do?”
“Start a game.”
“Restore a saved game.”
“Select the computer’s playing strength.”
“OK, let’s get those written,” Carlos said. A few minutes later, the team had produced the stories shown in Table 23.1.
Table 23.1. Stories Thought of While Thinking about What Users Want before a Game Begins
“Carlos,” Frank asked, “if these stories are things a player may want to do before the game starts, why do we include As a player, I want the system to play background music? Isn’t that something the player wants while playing the game, rather than before?”
“We’re just brainstorming the user stories,” Carlos answered. “We won’t keep track of which stories happen before the game starts and which happen during it. I’m just using that approach to help us think through what we need in the game.”
“OK. What do we do next?”
“Now we think about what a user might want to do during a game.”
The team answered Carlos’ question by writing the stories shown in Table 23.2.
Table 23.2. Stories from Thinking about What Users Want to Do during the Game
“OK, I suppose we should move on to things that a user may want to do after a game is finished,” Frank said.
“There isn’t much a player would want to do after a game is over. We didn’t think of saving a game earlier, so we can add that,” Prasad said.
“A player may also want to go back and annotate moves. Deep Black & White supports that,” Rose said. “I can put a note on a move like ‘I also thought of playing on hexagon A3.’”
“OK, let’s get these written as stories,” Carlos said, which resulted in Table 23.3.
Table 23.3. Stories Thought of While Thinking about What Users Want after a Game
“What next, Carlos?” Allan asked.
“While you put the finishing touches on Deep Black & White over the next two weeks, Delaney is going to do some more product research.”
“Yes,” Delaney added. “I want to validate with prospective users the features they think are the most important.”
“But before we finish today, we should create a high-level estimate for each story,” Carlos said.
“OK, let’s estimate. But let’s take a ten-minute break first, though,” Allan said.
Estimating the User Stories
“What we’re going to do,” Carlos resumed the meeting, “is estimate each story as a number of story points.”
“What’s a story point?” asked Frank.
“A story point is a unitless estimate of the size and complexity of a story,” answered Carlos. “Suppose we decide that saving a game is three points. If we think that restoring a saved game will be the same effort, we’ll call it three points. If we think restoring a game will be a little less, we’ll call it a two.”
“So the numbers don’t mean anything?” Frank asked.
“Only relatively. A two is twice a one. An eight is four times a two. Like that. That’s all that matters,” Carlos clarified. “We’re going to estimate by playing planning poker.” Carlos handed each person a set of cards with the values 1, 2, 3, 5, and 8 written on them. “The way this works is Delaney will read us one of the story cards. We can talk about it and ask questions. Then we’ll each pick one of the cards I just passed out. Those numbers are our estimates. When we’ve each picked a card, we’ll turn them over at the same time. If we all agree, that’s the estimate. If not, we’ll discuss our estimates and the story for a couple of minutes, and then we’ll do it again. We’ll keep doing it until we agree on an estimate for the story.”
Carlos answered a few questions about the technique and then asked Delaney to read the first story: “As a player, I can start a new game.”
“The first story or two are always hard to estimate,” Sasha added. “Because we’re estimating stories relative to each other, it’s hard when there’s nothing to compare with. We mostly just need to decide whether this initial story is one of the smaller ones or one of the larger ones we’ve got. If, after we’ve estimated four or five stories, we decide we need to change the estimate on this first one, we can.”
“What do we mean by this story?” Allan asked. “It’s not clear what starting a new game means.”
“We wrote this story when we were thinking about what a user might want to do after first starting our software,” said Delaney. “We said she’ll probably want to start a new game or restore an old game. That’s all we meant.”
“Does this story include drawing a blank game board and setting things up so that the computer is ready to play a game?” Allan asked.
“I think it does. I don’t think the board needs to be pretty for this story. We’ve got another story about making the screen aesthetically pleasing. But this story does require that we draw the Havannah board on the screen.”
Carlos waited a few more seconds to see if there were any more questions. “OK, everyone pick a card with your estimate on it.”
“It’s a one,” said Allan, showing everyone his card.
“Not yet, Allan,” Carlos said. “Everyone needs a chance to think about it without seeing anyone else’s estimate. Doing it that way prevents any bias.” He paused. “It looks like everyone has picked a card. Turn them over.”
Cards ranged from Allan’s and Rose’s ones to a five from Prasad.
“Why a five, Prasad?” Carlos asked.
“I think this story will be one of the larger ones we’ve got to do,” he replied.
“Not even close,” argued Allan. “All this story needs is a user interface where a player can choose a Start New Game button and then have it draw a blank Havannah board. The board doesn’t have to be pretty, and it doesn’t need to let the user place any pieces. We have separate stories for those. This story is easy.”
“OK, I hadn’t thought of it that way,” said Prasad.
After allowing the discussion to continue a little longer, Carlos again asked everyone to select a card representing his or her estimate. Most estimates were now ones, with a two shown by Prasad. Carlos encouraged another short conversation and then asked Prasad if he could support an estimate of one. He said he could, and the first story was estimated at one story point.
“On to our next story,” said Delaney, who read, “As a player, I can restore a saved game.” After two minutes of discussion about how this story would work, Carlos asked each team member to select a card. There was no consensus on the first round of cards. Sasha argued that this story was twice as big as the first story because it involved setting up a blank Havannah board, reading the saved game from a file, and placing the pieces that had already been played on the board. Convinced by Sasha’s arguments, the team agreed on an estimate of two for the story.
“OK, next is As a player, I can select the computer’s playing strength. Let’s estimate that,” said Sasha.
“That’s the whole move-selection engine,” said Allan. “That’s going to be hard. Can we skip this one for now and come back to it after we’ve estimated some of the other big stories?”
“That’s OK with me,” Sasha said.
“Wait, though,” Rose said. “I thought this story was about letting the user pick a playing strength, not about the computer playing at that strength. This is easy; it’s just a field or two on the screen.”
“That’s how I meant the story when I wrote it,” Frank said.
“That’s fine but then we need a story like, As a player, I can play against the computer at different playing strengths,” Rose said.
“Can we split that up, though?” Allan asked. “I think that’s going to be hard. How about As a player, I can play against a weak computer opponent? And then As a player, I can play against a strong computer opponent and a medium computer opponent?”
“Sure. Let’s do that,” Sasha said. “Let’s start with the player selecting the computer’s playing strength. Everyone pick one of your planning poker cards. OK? Ready; turn them over.” Everyone turned over a one. “That seems reasonable to me. We’re saying this is about the same size as As a player, I can start a new game.”
There were nods of agreement that the two stories were indeed about the same size.
“Let’s move on to the As a player, I can play against a weak computer opponent story,” Allan suggested, eager to talk about the move-engine stories that he’d probably be the one to program. “How strong does our weak engine need to be?”
“It can’t play randomly,” Delaney said. “But it doesn’t have to be very strong. This game is deceptively hard, and it takes most people a while to figure out what’s a good move. But even our weak level needs to know whether it’s best to try to make a ring, a bridge, or a fork, based on what the human player is doing.”
“OK, let’s estimate it,” Allan said.
“Wait,” Prasad said. “How are we going to test this? It seems like it’s going to be really hard to test.”
“Good question,” Carlos said. “Any ideas?” He looked around the room.
“One way would be to identify a bunch of positions, see what the engine suggests, and ask a good human player if those are decent moves,” Rose said.
“That’s good. Can we automate that, though?” Delaney asked. “We need to automate the tests so that if the engine starts making weird moves, like Deep Black & White did in April, we know about it immediately.”
“Absolutely,” Prasad answered. “We can have a file that describes a board position and then says how the computer should respond.”
“There may not be just one acceptable move,” Allan said. “That file should allow us to specify multiple good responses.”
“Great answers. We don’t need to design that file now, though, as long as we know there are some options. Let’s estimate the story,” Carlos said.
The room grew quiet as each person thought about all that would be involved in this story. When each had selected a card, they all held them up at the same time.
“Allan, I think you’re supposed to hold up only one card, not all of them. Did you have a hard time making up your mind?”
“No, I don’t have a card big enough. So I’m holding them all up. All these cards”—the programmer indicated the 1, 2, 3, 5, and 8 cards—“add up to 19. That seems about right.”
“I’ve got some bigger cards—13, 20, 40, and 100,” Carlos said. He passed a set of the additional cards to each person. “I was hoping we wouldn’t need them, but we might.”
“Why were you hoping we wouldn’t need these?”
“Considering the stories that we’ve estimated so far, any story we estimate at 100 story points is not going to fit into a single iteration. It’s going to be too big. The same is probably true of the rest of the numbers I just passed out. It’s OK for us to have some big stories, and it’s perfectly fine for us to estimate them with big values. But we need to remember that we’ll have to split them up before working on them so that each fits into an iteration. And we need to remember that estimates of very large features are likely to be less accurate. That’s why the ranges get bigger.”
“So, Allan, you think this is a nineteen. Really?” Sasha asked while double-checking the eight in her hand.
“Absolutely. First, I need to learn more about this game. The engine is going to need to recognize whether the player is trying to make a ring, bridge, or fork. It’s going to have to decide which shape it should try to make. It needs to decide whether a move should be offensive or defensive. Even a first, weak engine is going to take a while.”
“Well, you’d know. But nineteen is huge,” Sasha said.
“Prasad, why do you think this is a three?” Carlos asked, focusing the discussion on the estimators with the outlying values.
“The testing just doesn’t sound hard. I don’t think I’ll have that much to do. I’ll create those text files for the tests, and that’s it.”
“Sure but we’re estimating the full story, not just our own parts of it. Testing may be a three, but Allan’s time needs to be in there, too,” Carlos explained.
“Oops. Yeah, then, Allan’s right,” Prasad said. “This one is going to be big.”
“Let’s see if he’s right. Pick up your cards, and re-estimate based on what you just heard,” Carlos instructed. He paused a few seconds to make sure everyone had time to think. “Turn them over.”
All cards showed twenty this time.
“It looks like you convinced everyone, Allan,” Carlos said. “A twenty is probably too big for one story, though. Allan, is there a way to split this story up? Maybe have an even weaker engine the first time? Then improve it before you ship.”
“I don’t see any good ways,” Allan said. He thought for a moment and then continued, “We could have the engine play an offensive move every turn, always trying to make its own pattern, ignoring the human’s moves. I don’t think that’s a good idea, though.”
“What if a first engine recognized only rings?” Rose asked. “We could take away bridges and forks—just for now. Allan, couldn’t you write an engine that played offensively and defensively but that tried to make—and block—only rings?”
“Absolutely. That could work. So let’s split this into three stories—one for each shape.”
Everyone agreed, and they estimated the three stories as shown in Table 23.4.
Table 23.4. Three Smaller Stories Split from the Weak-Engine Epic
“When those were one story, the estimate was twenty. Now it’s twenty-one. Should we take a point off of one story so it’s still twenty?” Frank asked.
“No. The estimates are what they are, and they’re not meant to be that precise,” Carlos answered. “Breaking stories up helps us see more of what’s involved. The sum of the estimates doesn’t need to equal the estimate of the larger story.”
“Allan, what should we do about the medium-strength and strong engines? Do you want one story for each, or do you want to split those up by rings, bridges, and forks as well?”
“One story each. I think that we should define our medium-strength engine as one that never makes an outright blunder,” Allan said. “It may not always play the absolute best move, but it never makes an outright mistake. We can test that the way we described, and we can have some good human players test it. As long as it makes moves that they would consider reasonable, it’s OK. For the strong engine, we can strengthen that condition and have it play the best move it can find. Based on performance, we can set how far ahead the move engine looks.”
“So how do you want to write those as stories?” Frank asked.
“I think As a player, I can play against a medium-strength engine is fine,” Delaney answered.
“Yes,” agreed Carlos. “You can note on the story card that ‘Always plays moves a good human player thinks are reasonable’ is one of the conditions of satisfaction for that story. That will help you remember what a ‘medium-strength engine’ is without having to make another story about reasonable moves.”
The team discussed this story a bit more, played planning poker, and then agreed to estimate it as eight story points.
“And then we’ll have As a player, I can play against a strong engine as well, I suppose,” Frank said.
“This is at least twice as big as the medium engine,” Allan said. “We called that an eight. I don’t have a sixteen, though. Do we use thirteen? That’s the closest. Or do we make up a sixteen?”
“What you want to do,” Carlos said, “is think of the cards as buckets. If this story is a sixteen, it won’t fit in a bucket that holds thirteen. We don’t want to make up new values because it starts to look too precise. We don’t know if this is a thirteen or a sixteen or a nineteen. It’s important to remember that these are estimates, not guarantees.”
“OK, I think this is two to three times as big as the medium engine,” Allan said. “That means it’s sixteen to twenty-four. Because twenty-four won’t fit in a twenty bucket, should I estimate it as forty? That seems high. It’s not five times as big as the medium engine.”
“No, I wouldn’t,” Carlos answered. “They’re buckets, but think of the contents as sand, not water. You can overfill it a tiny bit at the top.”
“Let’s estimate, then,” Allan said.
Based on the discussion they’d just heard, no one disagreed with Allan, and everyone held up a twenty.
“So we’ll call this story a twenty,” Carlos said. “That’s OK for now. We’ll probably need to find a way to split it into at least two discrete pieces of work later.”
“We don’t need to break it up into smaller stories, like we did for the weak engine?” Allan asked.
“No, we can do that later, when we’re closer to working on that story,” Carlos said. “We’ll know more then, and there’s nothing to gain by splitting it today.”
“Good. Let’s move on,” Delaney suggested. “The next story is As a player, I’d like to be able to use the system to play against another human on my computer. This referred to two of us sitting at one computer passing the keyboard or mouse back and forth and making moves. All we want is for the computer to tell us when someone wins.”
“The other features we identified still work, though, right?” Prasad asked. “Two human players may want to use undo and redo, or they may want to ask for a hint.”
“Sure,” Delaney answered.
“I think we should add a story: As a player, I want the computer to recognize a winning shape,” Allan said.
“Isn’t that part of the move-engine stories?”
“Yes, but if we pull it out we could do it separately and that would let us write a human-versus-human version of the game really quickly while we get the move engine working.”
There were no objections, and the new story was estimated as two story points.
“Allan, does that lower any of the estimates for the weak move-engine stories?” Frank asked.
“Not really. I would still estimate each the way we have. We could lower the eight-point stories to seven, if you want.”
“No, we don’t want to do that,” Carlos said. “That makes the numbers look too precise. If we want to lower it to a five, we can. Otherwise, let’s leave it as an eight.”
“No, five is too low,” Allan said.
“OK. So we’re back to estimating As a player, I’d like to be able to use the system to play against another human on my computer.”
After two rounds of planning poker they reached agreement to call that story a three.
“Next is As a player, I’d like the appearance of the game to be aesthetically pleasing,” Delaney read.
“Finally. One of my stories,” Rose, the artist, said.
“Yeah, except I don’t like the way this story is written,” Sasha said. “It’s kind of vague, and it’s big. I like the next story: As a player, I’d like to be able to choose between a wooden board and pieces and a metal board and pieces. What else did we mean by ‘aesthetically pleasing’?”
“It had to do with the overall look and feel of the game,” Frank answered. “We probably won’t have many menus, but we want them to look good. We want the menu items to be in logical places. We want an attractive splash screen when the game loads. The board and pieces are the entire user interface. There will probably be some background art behind the game board. Rose needs time to do that.”
“Those are good. Can we split some of those out as separate stories?” Sasha asked.
“We could,” Delaney said, “but it might be hard. I think the menu items need to be developed in the context of whatever features introduce the need for a new menu or menu item. Rose, what do you think of having one story for a splash screen and another for background art?”
“Fine with me. Obviously, I’d do them separately anyway.”
The team made quick progress through the next set of stories.
“What do we do about this story?” Prasad asked, pointing to a card that read As a player, I’d like to ask for a hint sometimes.
“What do you mean?”
“If we’ve done the move engine, this story is really simple. All you do is ask the move engine to suggest a new move, but for the player instead of the computer. That would be trivial. But if we don’t have the move engine written, this story has to be at least as big as writing the whole move engine.”
“So we have a dependency that we can do hints only after we’ve done the move engine,” Allan said.
“Yes, but I don’t think that’s a problem in this case,” Sasha said. “Developing the move engine before the hint feature seems like the natural way to program those stories. The dependency won’t be in our way. We can ignore it. Or if we’re worried about forgetting this dependency, we can note it on the card. Either way, the story can be estimated with the assumption that the move engine exists.”
Everyone agreed, and the story was estimated at one story point.
“What would we have done if we really wanted to have hints before the move engine?”
“Sometimes you can’t get rid of a dependency and you have to live with it, just like before you started using an agile process,” Carlos explained. “Most of the time, however, you can get rid of it. If we wanted to get rid of this dependency, you could write the code that lets a user ask for a hint, displays that hint, and makes the move for the user if she likes it. To get the hint, you would have an object in the system called HintGenerator. Eventually, HintGenerator would call the move engine to get a good hint. But for now, you could have it return either the first open space or a random open space. That way, you’d be done with the hint story before even starting the move engine.”
“We’d have to remember to come back later and make HintGenerator actually call the move engine,” Allan said.
“Yes,” Carlos said. “We could make another story that was something like As a player, I want to get good hints, rather than just hints.”
“That’s probably a one-line change,” Allan said. “We’d delete whatever HintGenerator does to find an empty space and call the move engine instead. We’d have to estimate that as a one, the same as the original story. It doesn’t seem like we’d gain anything.”
“Ah,” Carlos said, “this is where it’s sometimes useful for us to have cards that say zero instead of just the numbers we have now. Because we have to come back and hook HintGenerator up to the right code, we want a story card so that we don’t forget. On the other hand, it really is so simple that we want to call it a zero.”
Carlos gave each person another planning poker card, this time with a zero on it. “I’ve been holding on to these because I didn’t want you to use them before we talked about what a zero-point story would be.” Each person now held a deck of cards containing 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
“In this case, though, we’re going to add support for hints after the move engine is finished, though. Right?” asked Frank.
“Yes, we’ll just keep that as a one-point story,” Sasha answered.
Estimating continued in this fashion until the team had estimated each of the stories they had written. The stories and their estimates are shown in Table 23.5.
Table 23.5. Estimates for All Stories Written So Far
“So where do we go from here? We need one more two-week iteration on Deep Black & White before we send it to the publisher,” Frank said.
“While everyone else is working on that, I’m going to interview some likely buyers of this game,” Delaney said. “I want to see what features are the most important.”
“Will that take long?”
“No, I’ll be done before the end of the iteration,” Delaney said. “Let’s meet again in two weeks, right after we ship Deep Black & White and after Frank takes us all out to celebrate finishing it.”
“Sounds great. I’ll get right on that celebration. Are hamburgers OK, Delaney? Or should we splurge for pizza?”
Preparing for Product Research
In the quiet of the early morning of the next day, Delaney sat at her desk in the team’s new open space, preparing the questionnaire she would use to interview prospective game buyers. Frank had asked to meet with her sometime during the day so she could explain to him how she was going to prioritize features. As the product manager, Frank would make the final decisions about what would be in the product, but Delaney knew that he would rely heavily on her research. She wanted to be prepared for meeting with him. By the time Frank arrived, Delaney had nearly finished the questionnaire.
“Good morning, Delaney,” Frank greeted the analyst. “Do you still have time to get together this morning?”
“Absolutely. I came in early to finish the questionnaire I want to send. I’d like to show it to you.”
“Let’s do it,” Frank said as he pulled up a chair. “Show me what you’ve got.”
“I printed this about a half-hour ago,” Delaney said as she handed Frank the page shown in Table 23.6. “I’ve added more questions since I printed that. But it’s enough to give you an idea of what I’ll send.”
Table 23.6. The Beginnings of Delaney’s Questionnaire
Frank reviewed the page Delaney had given him and then asked, “You seem to be asking each question twice. Why is that?”
“The first form of the question is called the functional form; the second is the dysfunctional form to indicate it means a feature is not present. Asking these two questions gives us a better understanding than just asking ‘How much do you want this feature?’ It tells us how the user will feel if the feature is there and how he’ll feel if it isn’t.”
“Can you give me an example of how that might be important?”
“Sure. Suppose we ask, ‘How do you feel if you can undo and redo moves?’ and a user says that she expects to be able to do that. We then ask her, ‘How do you feel if you cannot undo and redo moves?’ and she says she would dislike that. That tells us that feature is mandatory for this user. She expects to be able to undo and redo; she dislikes it if she cannot.”
“OK, I’m with you so far.”
“Now suppose we ask the same user, ‘How do you feel if there is an interactive tutorial to help you learn the game?’ She likes that idea. We also ask the dysfunctional form of that question, ‘How do you feel if there is not an interactive tutorial?’ and she says neutral on that. This is what we call an attractive feature, or an exciter. We’ve found a feature that the user didn’t expect to get or could live without. But she’s told us she’d like the feature. So we’ve learned this feature isn’t mandatory, but because it’s one she’d like, she may be willing to pay extra for it.”
“But couldn’t we get that by asking users to rate the importance of features from one to five, like we did on Deep Black & White?” Frank asked.
“Not really,” Delaney said. “A single scale like that just tells us how strongly a user values a feature. It doesn’t tell us how strongly the user would react to the absence of the feature. I wouldn’t prioritize wheels very highly if you asked me about features on a car, but I’d be mad if you took them away.”
“Who are you going to give the questionnaire to?”
“I’m going to email about 500 members of some game clubs I know where they play Havannah. Many are in Europe or in the larger U.S. cities. We’re offering a coupon for $10 off one of our existing games to anyone who responds. I expect to get fifty or so responses. I’m going to do some phone interviews as well.”
“Isn’t this going to be a lot of questions for people to answer if you have two questions for each user story?” Frank asked.
“Not really. I can group some of the user stories we identified into themes. For example, we’ve got two user stories about background music. They can be combined into a background music theme. I’ll combine the background-art and splash-screen stories into one theme about the game being aesthetically pleasing. Similarly, I’m not going to waste time asking about saving games and restoring games. We know those are mandatory features.”
“That’s great. I want to make sure this stays lightweight and easy. How will we use the answers you get?”
“I want to separate our features into three categories. First are features we must have. These are cost-of-entry features like saving and restoring games. The second category is features that the more we have of them, the better. I suspect things like playing levels will be in this category. The more playing levels—like strong, medium, and weak—the better. The third category is the exciters. These are features that most users don’t expect, but once they see them, they want them. The right mix of features from the latter two categories plus all the necessary must-have features can add up to a compelling product.”
Before Frank could respond, Allan rolled his chair next to Frank and Delaney. “Good morning,” he said. “I couldn’t help but overhear part of that. It sounds really interesting. Will the rest of the team have access to the results of your interviews?”
“Absolutely, Allan.”
“Good. You know, I might even want to listen in on one or two of your phone interviews to hear what users have to say. Would that be OK?” Allan asked.
“Absolutely,” said Delaney. “Understanding our audience is something the whole team really benefits from. The more that you or the other techies want to be involved in this, the better from my perspective. I’ll benefit from your insights, and you’ll benefit from hearing what the customers say.”
“I agree,” Allan said. “I can’t do any calls with you today. I need to fix a bug in the scoring engine of Deep Black & White. But any other day this week when you’re making calls, let me know.”
“I’ll do that,” Delaney said.
“It sounds like you’ve got a solid plan worked out,” Frank said. “This is exciting. Will you still have some results next week?”
“Definitely. The IT group is going to put the questionnaire on our website tomorrow. We could start getting preliminary results any time after that.”
“Great. Thanks for showing this to me,” Frank said as he got up and excused himself.
Iteration and Release Planning, Round 1
Two weeks after the meeting in which they wrote and estimated user stories, the team again assembled in a conference room adjoining their open workspace. By nine, the whole team was present, even Rose who had begun dropping Brooke at preschool five minutes earlier so that she would be in the office by the time the team started their daily standup meetings.
“We have three goals for today,” Carlos began. “First, we’re going to plan your initial two-week iteration. After that, Delaney is going to tell us what she found during her product research about what prospective buyers want. Finally, we’re going to take an initial very rough guess at what your release plan and schedule may look like. Any questions?”
Sasha waited a few seconds to see whether there were any questions. There weren’t.
Planning the First Iteration
“So what should we develop first?” Rose asked.
“I want to get started on the move engine,” Allan said. “That’s our biggest risk.”
“No argument from me,” Sasha, the other programmer on the team, said. “Are there things I can do to help, Allan? Normally, all of the artificial intelligence work is yours.”
“Yeah, there are things you can do. Thanks,” Allan said. “That would help me a lot, because I’m worried about how hard it might be to do the strong engine.”
“So let’s start with the story As a player, I can play against a weak engine that recognizes rings. Isn’t that the one you want to do first, Allan?” Delaney asked.
“Yes, it is. The first thing we need to do is code the classes that will keep track of the state of the board, keep track of whose turn it is, and stuff like that. Sasha, you can definitely help there.”
“OK. How long do you think it will take? A couple of days?”
“A couple of solid days. Let’s say sixteen hours,” Allan answered.
“Allan, we want to capture each task on a note card. Write that on a card, and put sixteen in the corner of the card so we don’t forget the estimate,” Carlos said.
Allan wrote Task Card 23.1.
Code state management classes.
16 hours
“Should I put my initials on it so we remember this is my card?”
“No. It sounds like you’ll probably be the one to do it. But it works better if we don’t assign work to specific individuals right now.”
“I’m going to need to test this,” Prasad said. “It shouldn’t take long, but this is the first code on this project, and I want to make sure I set it up right. I’m going to say testing will take ten hours.”
He wrote Task Card 23.2.
Write automated tests for state management classes.
10 hours
“Carlos, you told me earlier I need to break my work up into small pieces,” Allan said. “I can’t just say that writing the move engine for rings will take two weeks, can I?”
“No, you can’t. When we’re identifying tasks, we want them to be around one to sixteen hours. Ideally, you should be able to finish one each day, which means the average should be like five or six hours, because we always have a few other things to do each day.”
“In that case,” Allan said, “the way I plan to write this is to first have a move engine that will be smart enough to play six hexagons in a row to make a ring. There won’t be an opponent trying to stop the engine. I’ll have the engine start in a random place on the board and figure out how to make a ring in six moves. Next, I’ll write it so that it tries to make a ring even if an opponent tries to block the ring. Then I’ll switch to the defensive side of rings. I’ll have the engine try to block another player that is trying to make a ring. That’ll be it for this story for me.”
“OK, I wrote a task card that says Have move engine pursue an unblocked ring. That’s what you said you wanted to do first,” Sasha said.
“That’ll probably take me most of a day. Put six hours on that card, please,” Allan said.
“Allan, no offense, but you are always optimistic at the start of a new engine,” Rose, the artist, said.
“Yeah, you’re right. You’d better double that,” Allan agreed.
Sasha crossed out the six and wrote twelve hours on the card.
Carlos then led the discussion through estimates of the other tasks Allan had identified. “Are there other tasks we haven’t identified for this story?” he asked.
“We might want to include some time for testing!” Prasad said. “If Allan can give me code after each of the tasks he identified, I can define and automate tests right along with him. Any bugs I find, he’ll hear about while the code is fresh in his mind. I wrote the tasks on cards while Allan was describing how he’ll code this, but I haven’t estimated them yet. Can we do that together now?”
When they finished discussing the As a player, I can play against a weak engine that recognizes rings story, they had written the task cards summarized in Table 23.7.
Table 23.7. Tasks and Estimates for “As a player, I can play against a weak engine that recognizes rings”
“That’s about eighty-four hours in this iteration. The work is split across Allan, Sasha, and Prasad,” Carlos said. “Based on what I’ve seen after being here a couple of days, I think you should plan on six hours per day per person of productive work. The rest of each day goes to answering emails, talking to other project teams, your own daily meetings, the half day every other week we’ll spend doing this planning, and so on.”
“Six seems reasonable to me.”
“Me, too. It might be closer to five, but I can try to get six a day on this project and figure out how to make that happen by not doing some of the other little things that chew up my time every day,” Sasha said.
“Now that you’ve split that first story into tasks,” Carlos said, “the question you need to ask yourselves is whether you can commit to finishing the story.”
“The story or the tasks?” Frank asked. “Which are we committing to?”
“Good question, Frank,” Carlos said. “You commit to the story. We identify the tasks as a way of seeing how much work is involved and of helping us make the commitment. Because you’re committing to the story, not just the tasks, it’s important that you think about this as a whole-team commitment. At the end of the iteration, I don’t want Sasha to say she’s done with the state management classes but that Allan isn’t done. That wouldn’t do you any good. You can think about tasks, but you commit to stories.”
“Interesting,” Frank said. “I like the distinction.”
“I can commit to this story,” Prasad said. “I’ve got thirty-six hours of testing tasks. With six hours a day for ten days, I’ve got sixty hours available.”
“And between Allan and me, we have forty-eight hours of tasks. That won’t be a problem,” Sasha said.
“Great. We’ve got our first story planned, and we’ve committed to it,” Frank said. “Let’s move on to the next most important story.”
“Frank, before we do that, let’s list everyone’s availability for the next two weeks,” Carlos said. “We’ve said we’ll assume six hours per day, but is anyone planning any vacation or any time out of the office?”
“I’m taking two days off. I’ve got a couple of paintings in a show up in San Francisco, so I want to head up there for that,” Rose said.
“I’ll probably take one day off. Either a Friday or a Monday,” said Allan.
“My mom and dad are going to be in town next week. Too much time with them drives me nuts, so I’ll be working extra!” Delaney joked.
During this, Carlos had taken the notes shown in Table 23.8 on the whiteboard in the front of the room. “This will help us know how much we can commit to as we identify the next few stories we’ll work on,” Carlos explained.
Table 23.8. Carlos’ Notes on Who Is Planning to Be Gone during the Iteration
“Thanks, Carlos,” Frank said. “What’s the next most important thing to do?”
“I’d really like to have the game play human versus human,” Delaney said.
“That’s a good step,” Allan agreed. “It would make us program the logic that recognizes when the game has been won. We could easily add the undo and redo features while I get a suitable first move engine programmed.”
“Let’s break As a player, I’d like to be able to use the system to play against another human on my computer into tasks,” Frank said.
Everyone agreed. When they were done, they had identified the tasks listed in Table 23.9.
Table 23.9. Tasks and Estimates for “As a player, I’d like to be able to use the system to play against another human on my computer”
“So as a team, can you commit to completing this story in addition to the first one?” Carlos asked.
“Wait—doesn’t this story encompass another story we wrote? We have one that says As a player, I want the computer to recognize a winning shape. We’ve included that as part of playing against a human,” Prasad said. “Should we remove it?”
“I don’t know yet. We included it by accident. Let’s see if we can commit to the work we just identified. If we can’t, we can remove having the computer recognize winning shapes and let the players decide when a game is over,” Delaney said. “What do you think? Can we commit to this story, too?”
“Yes,” Allan and Sasha said nearly in unison.
“Seems fine to me,” Rose said.
“Barely,” Prasad said.
“What are you thinking, Prasad?” Carlos asked the tester.
“Between the two stories, I’m at fifty hours. I know we’re saying I’ve got sixty but that seems high to me. We’ll have to see how it goes.”
“Keep in mind, testing tasks are not assigned specifically to you, Prasad,” Carlos said. “Anyone can do them. If you fall a little behind, others will be expected to pick up testing tasks.”
“Absolutely. I usually do some testing,” said Rose. “I want to start on some board designs this iteration, but that can wait if I’m needed to test instead.”
“Thanks, Rose,” Prasad said. “Even without help, I think can commit to this story. But I’m starting to get close to full.”
The discussion then turned to the next story, As a player, I can play against a weak engine that recognizes bridges. By the time they finished discussing what would be involved in this story and the amount of work involved, the team had identified the tasks and estimates shown in Table 23.10.
Table 23.10. Tasks and Estimates for “As a player, I can play against a weak engine that recognizes bridges”
“Can we commit to this story, too?” Rose asked.
Frank noticed and appreciated that this was one of the team members asking her peers if they could commit. He liked that so much better than asking them himself, as the product manager, “Can you commit?”
“I’ve been adding these up as we go,” Sasha said, rising from her chair. “Here’s how I’ve added them up.” She drew Table 23.11.
Table 23.11. Sasha’s Summary of Hours for the Three Stories
“I don’t know about the rest of you, but I can commit to four hours over the next two weeks,” Rose joked.
“With two programmers each getting thirty hours a week and doing a two-week iteration, I think we’re OK on the programming side,” Sasha said.
“I agree,” Allan said.
“I don’t feel comfortable taking on any more, though,” Sasha said. “And besides, that’s too much testing for just Prasad.”
“I plan to help with some testing,” Rose said.
“Me, too,” Delaney said. “I probably can’t do any of the automation, but I can help specify good test cases.”
“With some help, I’m OK on the testing hours,” Prasad said. “I think we can commit to this.”
“Everyone OK with it, then?” Frank asked.
Everyone was.
“I’d like to add a few more tasks to the iteration, just to make sure we account for them,” Delaney said. “I really need to do a few more player interviews. We haven’t talked about my product research yet, but a few things came up that I want to follow up on. Adding twelve hours or so for me of additional product research would be great. I can still spend most of my time on testing, though.”
“And I’d like to do some preliminary board and piece drawings so we can get those circulating. It always takes a while to get enough feedback on those. I’d like to draw four board and piece sets at four hours each.”
“Those seem reasonable to me,” Frank said. “Let’s add those.”
“So with everything we’ve listed, are we all comfortable committing to this?” Sasha asked. “It’s 224 hours in total now. With five of us on the project—Allan, Prasad, Rose, Delaney, and me—this works out closer to five hours a day. But that’s if all the work and each of us is interchangeable. We’re not.”
“And besides,” Carlos said, “you’re better off adding something midway through the iteration than dropping something.”
Everyone agreed that the level of effort was just right—not too hard, not too soft, just right. Everyone committed that as a team, they would deliver those three stories in two weeks.
“Fantastic,” Frank said. “It is great to think that we’ll make so much visible progress so quickly. Normally, it takes much longer before we have anything to show.”
“Let’s take a fifteen-minute break,” Carlos said. “When we come back, I want to move on to the second goal for this meeting: release planning. I want to have some initial guess as to how long we think this project will take.”
Release Planning
When everyone returned and was seated around the table, Frank began the meeting. “Delaney, tell us about the product research and what you found.”
“What I did,” Delaney said, “was send out just over 500 email invitations to complete a web-based questionnaire. I also spoke on the phone with thirty-five likely buyers of a game such as this. In total, we got answers from seventy-eight prospective buyers. The purpose of the survey was to find out which features we’ve identified are mandatory; they just need to be in the game. We also want to learn which features are exciting. They may not need to be in the game, but including a few exciters really makes a game more appealing and may let us charge a higher price for it. Finally, there are some features we call linear. The more of a linear feature present in a product, the more people will pay for it. Examples of linear features are horsepower in a car, the number of channels on satellite TV, and the number of playing levels in a game. I won’t explain here exactly how I did the research. But if you’re interested, I can point you to a chapter in a book [see Chapter 11, “Prioritizing Desirability”]. I’ve summarized the results, though, on this page,” Delaney concluded as she distributed pages showing Table 23.12.
Table 23.12. Distribution of Results from Surveying Users
“Delaney, there are a lot fewer items here than we have stories,” Prasad said. “How come?”
“The longer the questionnaire, the lower the response rate,” Delaney said. “So I merged stories based on my judgment. For example, ‘aesthetically pleasing’ in that table covers the three stories we had about nice graphics, a splash screen, and the ability to change the board and pieces between a metal look and a wood look. On the other hand, if I combine too many stories into one question, the answers we get back may not be very useful.”
“I can relate the first three columns to your descriptions of the three types of features, Delaney. But what do ‘indifferent,’ ‘reverse,’ and ‘questionable’ mean?” Rose asked.
“Good question. Indifferent is easy; it just means that the person didn’t have a strong preference either way,” Delaney answered. “Because of how the questions are presented, it’s possible for us to not be able to interpret an occasional opinion. For example, this could happen if someone said they dislike background music but that they also dislike it when there’s no background music. That happens; people get confused or misinterpret questions when rushing. You’ll notice the percentages for reverse and questionable are pretty low.”
“Delaney, am I reading this right?” Rose asked. “It says that weak and medium-strength opponents are mandatory. But you’ve said that a strong opponent is both indifferent and mandatory. How can that be? Why not pick the answer with the highest percentage?”
“Yes, weak and medium opponents are mandatory. The reason we see two spikes in the values for a strong opponent is that we are probably selling into two audiences—those who already play Havannah and are good at it and those who aren’t. Those who are good at it consider a strong opponent as mandatory if they’re going to buy. Newer players are telling us they’ll be happy with a medium-strength player.”
“What strikes me, Delaney, is that there aren’t many features on this list that your audience considered exciting,” Frank said as more question than statement.
“True. But just because there aren’t many exciters doesn’t mean the product itself won’t be exciting,” the analyst answered. “Remember that exciters are unexpected features. If I got into a new Porsche, there’s probably very little in there that would truly be unexpected. But the car itself would still be very exciting. But I agree with the point I think you were making. We haven’t identified all the features this product needs. Every product should have at least one or two exciters—stuff that really makes the user say, ‘Wow!’ The survey seems to be saying we haven’t found that yet. This is why I asked for time in the coming iteration to follow up on this research. I want to have a few open-ended discussions with some of the survey participants. I’m hopeful that will help us find an exciter or two.”
“This is great, Delaney. Very helpful,” Frank said. “Does anyone have any more questions for her?” Frank paused before continuing. “If not, let’s talk about what we need in a release of Havannah.”
No one had any additional questions. They immediately plunged into planning the release by prioritizing features.
“Here are the stories I considered mandatory and didn’t even bother asking about in the questionnaire,” Delaney said as she arranged some story cards on the conference room table. The story cards and estimates she included are shown in Table 23.13.
Table 23.13. Stories Delaney Considered so Obviously Mandatory She Didn’t Include Them in the Questionnaire
“None of these stories should be surprising,” Delaney continued. “We see these features in every game we make. Supporting them is really the cost of entry.”
Delaney grabbed another set of cards. “On this part of the table, I’m going to arrange the stories that our customers told us are mandatory.” In that group, she arranged the cards shown in Table 23.14.
Table 23.14. Mandatory Stories Based on Delaney’s Initial Research
“Delaney, why do you include the strong engine in there?” Allan asked. “I like that. But according to what you showed us a few minutes ago, it was considered both a mandatory feature and one users were indifferent to.”
“Good observation, Allan,” Delaney said. “I’m making the recommendation that we consider that feature mandatory because I think many users will outgrow what you’re defining as the medium-strength engine. Those users will get bored with the game if we don’t include the strong engine.”
“OK.”
Frank was enjoying this. In his role as product manager and Delaney’s as the analyst, the team had often left all the product definition up to them. He liked that they were engaged in these discussions and were attentive to what was being discussed. That could only help the new product.
“The other story I’ve included as mandatory that is worth discussing is As a player, I’d like to be able to use the system to play against another human on my computer. I’ve included that as mandatory because we’ve already said it’s a good milestone. This next stack,” Delaney said as she grabbed another handful of cards, “have linear value. That is, the more of them, the better, but none is mandatory.”
Delaney arranged the stories of Table 23.15 on the table.
Table 23.15. Stories That Delaney’s Research Indicates Add Value Linearly (the More of Them, the Better)
“Art isn’t optional,” said Rose. “We need a nice splash screen and attractive boards and backgrounds.”
“I didn’t say these are optional, Rose,” Delaney said. “You’re right—we do need these. There is a certain baseline we can’t fall below, and the game does need to be aesthetically pleasing, which is how I asked the question on the survey. These are linear, because the more of them, the better. Two board choices are better than one, but three would be even better.”
“OK. That makes sense,” Frank said. “You’ve still got some story cards in front of you. What type of stories are those?”
“These next cards are exciters. Likely buyers don’t expect any one of these, but we should include a couple because they really boost enjoyment of the game. And like I said earlier, a few exciters means we can charge more for it, too.”
Delaney arranged the cards shown in Table 23.16 on the conference room table.
Table 23.16. Exciters According to Delaney’s Research
“After the exciters,” Delaney went on, “the remaining two stories were ones that prospective players said they are indifferent about. I don’t think we want to add these.” She placed on the table the cards summarized in Table 23.17. “We’re unlikely to sell more games or games at a higher price by adding features that players are indifferent about.”
Table 23.17. Features That Users Were Indifferent about According to Delaney’s Research
“Wow,” Frank said. “This is more information than we normally have at this point. Great job, Delaney. You got all this from your surveys?”
“Yes. The questionnaire is intentionally lightweight and just asks users how they’d feel if a feature was present and how they’d feel if it was not present. Because I combined some of our individual user stories into themes, the questionnaire had only twenty-four questions on it. Including some chitchat, it took only about fifteen minutes over the phone. Our website tracked the time it took each respondent to fill out the form. The average time was seven minutes. One person took forty, but I suspect they walked away from it or took a phone call.”
“So, Frank, what are our priorities?” Sasha asked.
“Well, we need to do all of the features that Delaney identified as mandatory or that her survey found to be mandatory.”
“That’s eighty-eight story points, according to our estimates,” Sasha said.
“Of the features Delaney said are linear, I agree with Rose: We need nice artwork,” Frank said. “All of those stories should be in. And I can’t see going without background music. Maybe the user can’t change songs, but that’s only one point, so for now, I’m going to say we want it. And we need online help. Not everyone who buys this game is going to know how to play it.”
“So you want all of the linear features. That’s another thirty-two points,” said Sasha.
“I know. I want it all, right? Just like every product manager in the world.”
“I don’t mind; I just know you want the product out in four months. We’re up to 120 story points now.”
“Will that take more than four months?” Frank asked, a bit concerned.
“I have no idea yet. Let’s figure out what you want, and then we can see how long it will take,” Sasha said.
“Fair enough,” Frank said. “Of the exciters, I think we need hints, and I’d like the tutorial. Maybe we could drop it or the online help, but I want to plan on both. I like the idea of telling the user when she’s made a bad move right after she makes it.”
“Remember, that’s an eight-point story,” Allan reminded everyone. “I’m programming the move engine to find good moves. I can enhance it to find really bad moves, but it’s not trivial.”
“That’s what I’m looking at. Let’s plan on going without that for now. But let’s include the story about warning the player that she’s about to lose unless she plays in a particular hexagon to block the computer.”
“That’s twelve points from the exciters list. Do you want anything from the indifferent list?” Sasha asked.
“Not really,” Frank said. “What’s our total now?”
“You’ve got eighty-eight story points from the mandatory lists, thirty-two from the linear list, and twelve from the exciters. That’s a total of 132,” Sasha said.
“And you’ll do all that in two iterations, right?” Frank asked with a smile.
“If we could, we would.”
“Seriously, how do we know how long that will take?”
“The best thing would be to wait three iterations and answer you then,” Carlos explained. “After each iteration, we can add up the story points for the stories that are finished. We call that velocity. Velocity will change from iteration to iteration, but its average is relatively stable over time.”
“Yes,” Allan jumped in, “our estimates may have been off. Or we may get lucky, or unlucky, on a story.”
“After three iterations, we should have a good measure of how fast the team is progressing. We can divide the total amount of work remaining by the velocity, and that will tell us how long to expect,” Carlos said.
“And that estimate will be pretty good?” Frank asked.
“It should be. After three iterations, you’ll have a good feel for how many story points you can do in a two-week iteration,” Carlos said.
“We do need to keep in mind that I’m going to talk to some more potential buyers and see if I can find any more exciters,” Delaney said. “As we said earlier, our exciters seem weak. We may add some more features.”
“Is there any way to get an expected schedule now?”
“Sure, Frank,” Carlos said. “You’ve planned to do four stories in this first iteration. We can add up the points associated with each and call that our planned velocity. We have no idea if it will be, but it’s our initial guess.”
“I’ve already done that,” Prasad said. “It’s eighteen. We get eight points for As a player, I can play against a weak engine that recognizes rings. We get five points for As a player, I can play against a weak engine that recognizes bridges. Then we get two points for As a player, I want the computer to recognize a winning shape and three points for As a player, I’d like to be able to use the system to play against another human on my computer.”
“How many iterations will the project take if our velocity is eighteen?”
“Just over seven iterations. We’ve got 132 points. Seven times eighteen is 126. We’re six points over seven iterations,” Prasad said.
“Can we just call it seven iterations?” Frank asked.
“We could, but we shouldn’t,” Carlos replied. “I’d prefer to give the estimate as a range. If we’re looking at enough work to go into an eighth iteration, we should probably say the project will take six to ten iterations.”
“I really don’t want this project to take twenty weeks. But you’re saying it might take only twelve, right?” Frank asked.
“It might. But it might take twenty.” Carlos remained firm. “You can help it avoid taking twenty weeks by removing your lowest-priority features if velocity shows that we’re headed toward ten iterations. Keep in mind, too, that Delaney is actively looking for more features. If she comes up with something, we’ll have to extend the schedule or take the same amount of current features out.”
“OK, I can explain twelve to twenty weeks to the other executives,” Frank said. “Let’s go with that as our initial plan.”
“Frank, I need to reiterate that the best thing to do would be to wait at least two weeks, let the team run one iteration, and then base this initial plan off at least one observation of actual velocity,” Carlos said.
“Understood. But everyone wants to know at least an idea of what the schedule looks like for this project.”
“Make sure they know that we can provide better information every two weeks. Especially after these first three iterations, we should know a lot more,” Prasad added.
“So do we need to plan what will be worked on in each iteration?” Frank asked.
“Not really,” Carlos answered. “The most important thing is to know what is going to be worked on next. We did that when we planned the iteration. The next most important thing is to know those features at the bottom of the list that may or may not make it into the release.”
“I understand why you need to know the top priorities, but why the bottom ones?” Frank said.
“It’s not very important for this first meeting, but when we get close to the end of the release, it’s sometimes important. For example, we wouldn’t want marketing to design packaging that said ‘Now with background music’ if that’s a feature that may get dropped at the last minute.”
“OK, but why not spend some time today planning what we’ll do in each iteration?”
“No point,” Carlos said. “In two weeks, we’ll know so much more than we do today. Why plan what we’ll do in an iteration until we have to? We don’t have to. On a larger project, particularly with multiple teams that need to coordinate work, we might look ahead two or three iterations. But we don’t need to do that on this project.”
“So are we done with release planning, then?” Frank asked.
“Yes. I’ll stack up the story cards you said you really want in the release, and that’s our plan,” Carlos said. “Before we get together again, two weeks from today, you and Delaney should talk about the stories and identify the ones you’d most like to see in the next iteration. In the meeting, we’ll talk about why you want those stories. The others may ask you to reconsider and move in one or two that they want to do because they’re risky or because they’ll learn a lot by doing them. But the ultimate prioritization decision will be up to you.”
“Don’t take this the wrong way,” Frank said, “but it didn’t really feel up to me today.”
“It was,” Carlos said, “but selecting the right things to work on next is really a whole-team effort. If the programmers were selecting a bunch of technical mumbo-jumbo or features you wouldn’t be able to see, I would have stopped that and had them work on other stories. I assume you’re happy with the stories that were selected?”
“Ecstatic. It will be great to see all that in two weeks.”
Two Weeks Later
“I wish we could have finished everything. Still, I’m impressed with what we’ve got,” Sasha said to the others while waiting for the meeting to begin.
“It’s unfortunate that we had to drop the As a player, I want the computer to recognize a winning shape story. But I really needed your help on the move- engine code, Sasha. Thanks,” Allan thanked the other programmer.
“Not a problem, Allan. We’re all in this together, and being able to demonstrate an engine that makes rings and bridges is more important,” Sasha said.
“So are we ready for the demo?” Frank asked as he walked into the room promptly at nine. He laid a box of bagels on the large table.
“Absolutely,” Sasha said. “Do you know if any of the other executives or other project members are coming to watch the iteration review?”
“I know Phil and Laura said they’d be here,” Frank said, referring to the chief executive officer and the chief financial officer.
“And a couple of the engineers on other teams said they’d be here as well. They’re curious about our new agile development process,” Allan said.
Over the course of the next half-hour, the team showed what they’d completed. They demonstrated the game engine making rings and bridges. They showed how two humans could play against each other, trading the keyboard between them to make moves. They’d even hooked the two pieces of functionality together so that a human could play against the computer. The human usually won, but that wasn’t surprising against the easy move engine.
The graphics were rudimentary—just Rose’s quick illustrations. But Phil, the CEO, was ecstatic to see that after only two weeks, some small part of the game had been developed and was functional. He was even more pleased when Prasad handed him the keyboard and he was able to play the game himself, barely winning the new game.
“This is fantastic, everyone,” Phil announced, rising from his seat. “Every two weeks, you’ll show more?”
“Absolutely. Every other week, right here at nine,” Sasha said.
“I’ll be back next time. I’m going to put these meetings on my schedule. This thirty minutes of seeing the actual software working is more useful than any status report I ever read. And how’s your schedule? Can I ask that now?”
“You can,” Frank said. “Right now, we’re sticking by our estimate of twelve to twenty weeks. We’re going to plan the next iteration after this meeting. We’ll know more in two to four weeks. At that time, we should be able to commit to a schedule that we can tell publishers about.”
“Great,” Phil replied. He and Laura left the conference room. So did the half-dozen others who had come to see the project.
Planning the Second Iteration
“If I recall correctly,” Frank said, “we planned a velocity of eighteen story points.”
“Correct,” said Delaney.
“But we couldn’t finish the story about recognizing when the game had been won. So our velocity is less than eighteen. Do we give ourselves one point for doing half of that story?” Frank asked.
“No,” Carlos said. “In general, we want to apply an all-or-nothing approach to the story points. It’s too hard to give ourselves partial credit, because we really don’t know how much work is left. Rather than guessing, we don’t get any credit until we get it all.”
“So our velocity was sixteen, because we originally estimated the unfinished story as two points,” Rose said.
“We have to plan on the project taking longer. Right?” Frank asked.
“We’re still within the twelve to twenty weeks you told the executives,” Sasha said. “We started with 132 story points. We finished 16, so we have 116 left. Dividing 116 by 16, our velocity, gives us 7.25. To be safe, let’s call that eight more two-week iterations. Including the two weeks we just spent, that’s a total of eighteen weeks.”
“That’s two weeks longer than four months, Frank. Does that matter?” Prasad asked.
“Not really. The release isn’t tied to any specific date. We just want it out as soon as possible,” Frank said. “I haven’t had a chance to tell you this yet: We still haven’t finalized the contract for Deep Black & White with the Japanese publisher. They still want to publish the game. And we’re this close to signing the final contract.” He held his fingers millimeters apart. “But they don’t want to release it until they have time to gear up a big marketing campaign, with ads in all the major magazines. That’s probably four months. And the way that works, we won’t see any royalties until the quarter after the game is released. We could be looking at eight months before Deep Black & White brings any real money in the door. Ideally, Havannah could be a quick win for us. Not on the scale of Deep Black & White. But because it won’t need the marketing ramp-up, the revenue will be more immediate.”
“And Frank, I’m sorry, but because I had to do more testing than I expected, I didn’t do much product research during this iteration,” Delaney said.
“OK. That’s fine, but let’s make that a priority this time, even if it means you test less,” Frank said.
“So Frank, what would you most like to see finished in this next iteration?”
The team planned their second iteration in the same way that they’d planned their first. When they finished, they had committed to completing the user stories shown in Table 23.18.
Table 23.18. User Stories Planned for the Second Iteration
“So if our velocity was sixteen in the last iteration, why are we planning for eighteen this time?” Frank asked.
“We use velocity as a guide for measuring progress against the release plan,” Carlos said. “We don’t automatically plan each new iteration to have exactly the velocity of the last iteration or the average velocity of the last few iterations. We plan each iteration based on how much work we can commit to. We add up the points only after we’ve figured out what we can commit to. When we do, the velocity should be somewhere close to our historical average, but it will vary.”
“Why?”
“Two primary reasons,” Sasha began. “First, we’re making more effective use of Rose this time. She’s primarily an artist, not a tester. It was great that she helped with so much testing last time, but this time, she’s going to draw the art for the wooden and metal boards and pieces. I’ll do the coding to let a user choose between them, and Prasad will probably be the one to test that story. But other than that, most of that eight-point story comes from Rose. Second, we’ve got a bit of a head start on the story about recognizing a winning shape. We started it last iteration but didn’t get far. I feel pretty good about the stories we selected. Even though it’s eighteen points again, it added up to fifteen total hours less than the last iteration.”
“I’m convinced,” Frank said. “Let’s do it.”
Two Weeks Later
At the next iteration review, the team again demonstrated good progress. They had completed each of the stories they’d planned. And Delaney had time to complete her product research. The executives, Phil and Laura, attended again. Because the news had spread about how much had been accomplished in their first two weeks, even more people from other teams attended the second review.
“The game is coming together. I can’t believe your move engine can already beat me,” Phil said. “And Rose, those first two boards look fantastic. Are we still looking at the same schedule? That would be eight to sixteen weeks from now.”
“Our rate of progress is right about where we expected it to be,” Frank said. “So we’re good there. Delaney did some more product research during this iteration, and she’s found some interesting features we may need to include. I’ll make the call on that, but I need to hear the team’s view first. I may suggest changing the schedule. We’re confident the new features will bring in more money. Now I need to weigh that against the extra development cost and the extra time.”
“I like the part about bringing in more revenue,” Laura, the chief financial officer, said.
“Me, too,” Phil agreed. “But I’m not wild about a possible slip already.”
“It wouldn’t be a slip, Phil,” Frank said. “If you want to deliver the product in the originally planned twelve to twenty weeks, we’re feeling pretty good about that. What we’re going to discuss after this meeting is how much longer it would take to create a more valuable game. And then we’ll see if there are features we can drop that would get us that more valuable game in close to the same twenty weeks we gave as our upper end.”
“I’m always interested in more valuable games. Let me know what you recommend,” Phil said as he stood and left the conference room. The rest of the guests left as well, leaving only the project team.
Revising the Release Plan
“Frank has already told you that I found some new exciters,” Delaney said. “A couple of you heard me talking on the phone with potential buyers about these. The good news is that our target audience really wants two features we haven’t thought about. First, they want the computer player to have different personalities who each play the game differently. One character may be very aggressive; another, conservative. A character that a lot of people asked for is one who taunts them. It says mean things after a bad move, laughs at them when they lose…stuff like that.”
“That does sound fun,” Allan said. “It’ll change the move engine, but probably not much. It’s already configurable to allow me to tune it for more aggressive or more conservative play.”
“That’s the first new feature,” Delaney continued. “The second is online play. People want to play this game online against other humans.”
“That’s huge,” Sasha said. “We’d need to get space in a data center, acquire the hardware, and hire the staff.”
“We could partner for all that,” Frank said. “It’s not out of the question, but you’re right that’s it’s big. Delaney, do you have any sense of which feature is more important?”
“The characters. Good characters would be a big exciter. That is a feature that people really like but that they don’t expect,” Delaney said.
“Delaney, you just told us that we’ve got scope creep. And we were already at the upper end of our twelve- to twenty-week estimate,” Prasad said. “Why did you say you have ‘good news’? Do you have something else to tell us?”
“No, that’s it, Prasad,” Delaney said. “But this is good news. We just found two new features that could help us sell more units, and at a higher price. Yeah, if we do them, the schedule will change. But that’s a good problem to have. We can ship the product based on today’s schedule and make a certain amount of money. Or we can change the schedule and plan on making more money. Plans are always point-in-time predictions. We just found a better future to aim at. I’ve already written the user stories for both features. We should estimate them and decide if we want to change the plan to include either or both.”
“Let’s do it,” said Frank. “I’m completely willing to change the date of the project if we can make enough more money and it’s not a big delay. It sounds like these features could be very lucrative.”
“But Delaney, why didn’t the questionnaire you sent out identify these features?” Prasad said.
“Questionnaires are good for prioritizing what we already know,” Delaney said. “They obviously aren’t good for discovering features we don’t know about. Some of the questionnaires we got back did mention characters and online play, but not enough that I thought there was a trend. I spent this past iteration talking to more likely buyers to confirm that these are good ideas and adjusting my financial models to show how much more revenue these features are likely to bring in.”
“I like the sound of that,” Allan said. “If the game makes more money, maybe Frank will take us somewhere more expensive than Fatburger to celebrate this release.”
“I liked burgers to celebrate the release of Deep Black & White,” Prasad said.
“Not me. After this one, I say Frank springs for sushi,” Rose said.
The team estimated the new stories Delaney had written. In doing so, they split some of her original stories and combined others. When they were done, the stories for online play added to thirty story points. They estimated creating the first character as fifteen story points. Each character after that would be five additional points. The team discussed it and agreed that five characters would be a reasonable number. This meant an additional thirty-five story points for developing the characters.
Because Delaney’s financial forecasts showed that characters were likely to generate more revenue than online play, everyone agreed that they should adjust their plan to include characters but not to include an online version.
“In the first two iterations we finished sixteen and then eighteen points. We just added thirty-five points. We’re going backward!” Allan joked.
“You’re right, Allan,” Carlos said as he reached for a calculator. “We’ve got 133 points. With our current average velocity of 17 points per iteration, that’s 7.8 more iterations.”
“Eight more iterations, plus the two we’ve already done, and we finish in ten iterations,” Frank said.
“It’s cutting it awfully close, Frank,” Sasha said. “Yes, it seems like we’ll finish in ten iterations. It’s a good thing our original schedule was a range and that we didn’t just tell people ‘eight iterations.’ However, if anything goes wrong—if a story is bigger than we think, or if we slow down, or if someone gets sick—we could take longer than eight more iterations.”
“Are you saying we should change the schedule?” Frank asked.
“Not necessarily,” Carlos answered. “If we want to keep the schedule at ten iterations, though, we should make sure we’re willing to drop some low-priority stories if we start to run out of time. If you’re not willing to do that, we should convey the expectation that it may take longer than ten iterations.”
“I can probably drop a few stories, if necessary,” Frank said.
“Good. Remember how I told you it’s important to know the stories at the top of your priority list and those at the bottom? This is a time when it’s important to know those at the bottom. I’ll feel more comfortable keeping expectations at no more than ten iterations if you can point out at least seventeen points of stories that you could live without if it meant going longer than ten iterations,” Carlos said.
“Here are a couple I could live without: As a new player, I’d like to be warned after making a horrible move and be given the chance to take it back and As a new player, I want to be able to view an interactive tutorial for the game. Each of those is eight points. I’ve already said I could live without the six points of background-music stories.”
“So you should work on those last. If you start to run out of time by the tenth iteration, drop one or more of those,” Carlos said.
“And if we’re on schedule and choose not to implement those stories, we could release at least an iteration sooner, right? When would we release if we left out those stories?” Frank asked.
“We’ve got 133 points planned. You’re willing to drop twenty-two points. That gives us 111,” Carlos said as he reached for the calculator. “With a velocity of seventeen, you need seven more iterations. You could be done in eighteen instead of 20 weeks.”
“Let’s keep those stories in the plan for now. I’ll drop them if we need to, but they’re probably worth two additional weeks,” Frank said. “I want to go run the new plan by Phil, because he asked to hear what we decided. Does anyone want to join me?”
Delaney and Allan both said they did. It wasn’t a surprise that Delaney did. As the analyst, Delaney was often involved in product and schedule decisions. Frank was surprised by Allan’s interest, though. Normally, Allan, one of the most hardcore technical people in all of Bomb Shelter, wanted nothing to do with business discussions. He’d really engaged in those discussions, though, since starting this project four weeks ago. Frank appreciated that. It was leading to better product decisions all around.
“I’m going up there now,” Frank said. “Let’s do it.”
“Shouldn’t we prepare anything for Phil first?” Allan asked.
“Nope. He’s got a whiteboard. We’ll just draw on that.”
Presenting the Revised Plan to Phil
“Hi, Phil. Do you still want to hear what we’ve decided about those new features in Havannah?” Frank asked.
“Absolutely. These are the features Delaney mentioned this morning?”
“Yes.”
“I’ve got about fifteen minutes now. Will that work?”
“It should be plenty,” Frank said. He then asked Delaney to explain how her research had led to the discovery of the new ideas for online play and characters.
“Phil, do you remember a few weeks ago when I told you how we are estimating in story points?”
“Sure.”
“And that story points are a measure of size. We started out with 132 story points. In the first iteration, we finished sixteen. In the second, we finished eighteen. Allan, can you draw that?” Frank asked, pointing to an empty space on Phil’s whiteboard. Allan went to the whiteboard and drew Figure 23.5.
Figure 23.5. The Havannah release burndown after the first two iterations.
“What you see here,” Frank continued, “is what we call a release burndown chart. From looking at it, you can see our rate of progress. After two iterations, we’re down thirty-four points. If you extended a trend line from this data you’d see that we are on pace to finish during the eighth iteration. That’s sixteen weeks total.”
While Frank was speaking, Allan drew the trend line shown in Figure 23.6.
Figure 23.6. A trend line based on the burndown of the first two iterations.
“The whole Havannah team thinks that adding the characters Delaney identified is a good idea.”
“How long will that take?” Phil asked.
“We think we need five characters. It’s a total of thirty-five points,” Frank said.
“That means that our burndown actually moves back up to here,” Allan said. He drew a vertical line up to 133 points on the whiteboard, as shown in Figure 23.7.
Figure 23.7. The Havannah release burndown with the character features included.
“Hmm. That doesn’t look so good. After two iterations, you’re no better off than where you started.”
“We’re actually much better off. We’ve made four good weeks of progress,” Allan said, pointing to the progress on the chart. “We’ve eliminated some of the riskiest parts of the project, because I’ve demonstrated how I’m pursuing the move engine. I’ve only done the weak game engine, but I’m starting to see how we’ll write the strong engine. We’ve also learned a lot. We learned about a new feature that Delaney says is ‘exciting’ to our target audience. Normally, we’d find that out much later. If I look at where we’re at, yes, we still have as much work to do as we thought four weeks ago, but now I’m more confident in the plan than I was four weeks ago. And every time we put a new data point on this burndown chart, I get more confident, even if not every new point is good news. It will be news I can trust about the progress we’re making.” Allan paused. “We’re much better off than we were four weeks ago.”
“So how long will the project take if we add the characters?” Phil asked. Frank was surprised, but pleasantly, that the question had been directed at Allan.
“Probably eight more iterations, or a total of twenty weeks. We’re completing seventeen points of work per iteration. We call that our velocity. If we draw a trendline showing seventeen points of progress per iteration, we finish in eight more iterations.” Allan drew the trend line shown in Figure 23.8. “That cuts it pretty close, so we’ve identified a few low-priority pieces we could drop if we start to get behind or if we decide to release after eighteen weeks instead of twenty.”
Figure 23.8. An updated burndown chart showing the predicted completion of Havannah.
“And the game would sell more or be at a higher price?” Phil asked.
“Yes, I’m certain of that,” Frank said. “I want to do a bit more research and modeling to determine if we should sell more copies at the current price or if we should increase the price by $5.”
“I’m sold. Thanks for showing this to me,” Phil said.
Allan started to erase the chart he’d drawn.
“Don’t. Leave it there,” Phil said. “I want to update that every two weeks.”
“Thanks for your time, Phil,” Frank said as he, Delaney, and Allan left the office.
Eighteen Weeks Later
“Great job, team. The game looks wonderful,” Frank said at the end of the final iteration review meeting. “I don’t see anything that’s missing. The engines play very well. And Rose, I love the characters. The way that each character is tied to an engine is great. Players will select a character to play against rather than a level to play at. I admit I was skeptical of cartoonish characters rather than real characters at first, but they’re great. I like how the pirate taunts the player and how you hooked a friendly mermaid to the easy move engine. Her dialogue is definitely going to help new players learn the game. I think we’re ready to ship.”
“I admit the game is great, but I still don’t like the feeling that we’re late. We originally thought we’d be done in just over fourteen weeks. But we told everyone twelve to twenty. Now we’ve slipped two weeks past that,” Prasad said.
“Yes, and here we are done in twenty-two weeks,” Sasha said. “We never said we’d be done in fourteen weeks. After the first iteration planning, we told everyone twelve to twenty weeks and that a more accurate estimate would come after six weeks.”
“And Prasad, keep in mind that we could have shipped two weeks ago if we’d wanted,” Frank said. “We chose to take time to incorporate additional changes into the characters based on the positive responses we were getting from beta testers. They loved the characters but gave us some great suggestions we wanted to incorporate. We made the pirate taunt a little more often, based on their feedback. And we gave the rap singer more dialogue. Sure, the initial schedule was wrong, but so was the product design. That game wouldn’t have made us anywhere near the return that this one will. You’ve played the new version. You know how much better it is now, only two weeks off our initial high-end estimate. If we could have released a version 1.0 without characters and then added characters later, I would have done that. But we can’t do that in our industry. I’m ecstatic with the product. It’s more than we expected and only two weeks later than an estimate given at the start of the project.”
“And don’t forget Deep Black & White was six months late, not two weeks.”
“So Frank, are you buying us burgers again to celebrate this release?”
“No, this time I’m buying whatever you want.”