Back to Blog
Management Frameworks

Agile Case Study (3/5): Planning the First Sprint

By  Jose Barato

May 24, 2021

20 minutes read

Third post on the chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In the previous post the Havannah team had written 32 user stories, totaling 146 story points.

In this post, team members are working on another project, while analyst Delanie start a market research performing a survey with potential customers. At the end of the two weeks, the team meets again with Carlos, the agile coach, to plan the first iteration and commit as a team to finish the stories with the most priority. As a result, the team commits to finish 4 stories, totaling 18 points.

Do you want to know how to plan the first sprint. Keep reading…

“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 met 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 the 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 the following table. “I’ve added more questions since I printed that. But it’s enough to give you an idea of what I’ll send.” 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. Asking it these two ways gives us a better answer than just asking ‘how much 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, since 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 1–5, 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 50 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 –linear– 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 are 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. 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 9:00 the whole team was present, even Rose who had begun dropping Brooke at pre-school five minutes earlier so that she would be in the office by the time the team starts 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?”

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 16 hours,” Allan answered. “Allan, we want to capture each task on a note card. Write that on a card and put 16 in the corner of the card so we don’t forget the estimate,” Carlos said. Allan wrote the task card: 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 10 hours.” He wrote task card: 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 2 weeks, can I?” “No, you can’t. When we’re identifying tasks we want them to be around 1– 16 hours. Ideally you should be able to finish one each day, which means the average should be like five or six hours since 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 6 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 better double that,” Allan agreed. Sasha crossed out the 6 and wrote 12 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 for this story.
  1. Code state management classes (16)
  2. Write automated tests for state management classes (10)
  3. Have move engine pursue an unblocked ring (12)
  4. Write automated tests for unblocked rings (12)
  5. Have move engine pursue a ring even if the human player tries to block it (8)
  6. Identify test cases for trying to make a blocked ring (4)
  7. Automate test cases for making a blocked ring (4)
  8. Have the move engine try to block a human player who is trying to make a ring (12)
  9. Identify test cases for blocking a human player making a ring (4)
  10. Automate test cases for blocking a human player making a ring (2)
“That’s about 84 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 5 but I can try to get 6 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 36 hours of testing tasks. With 6 hours a day for 10 days, I’ve got 60 hours available.” “And between Allan and I, we have 48 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 on the white board 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.
  • Frank
  • Allan (1 day)
  • Rose (2 days)
  • Sasha
  • Prasad
  • Delaney
“Thanks, Carlos,” Frank said. “What’s the next most important thing to do?” “I’d really like to have the game play human vs. 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 bellow:
  1. Very simple board and graphics (4h)
  2. Draw empty board (2h)
  3. Clicking on a hexagon adds a new piece of the right color (4h)
  4. Computer knows when a piece completes a winning pattern (6h)
  5. Design tests (6h)
  6. Automate tests (8h)
“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 50 hours. I know we’re saying I’ve got 60 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 get started 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 bellow.
  1. Engine can find path from one corner to another (that is, form a bridge) (4h)
  2. Identify and automate tests for simple bridge design (6h)
  3. Engine can form a bridge around obstacles (12h)
  4. Identify tests for forming a bridge around obstacles (6h)
  5. Automate tests for forming a bridge around obstacles (4h)
  6. Engine knows when to give up on a particular bridge (8
  7. Identify tests for giving up on a bridge (4h)
  8. Automate tests for giving up on a bridge (2h)
  9. Engine tries to prevent a another player from forming a bridge (4h)
  10. Identify tests for blocking another player from making a bridge (4h)
  11. Automate tests for blocking another player from making a bridge (4h)
  12. Engine can choose appropriately between placing a piece that leads to making a bridge and one that leads to making a ring (16h)
  13. Identify tests for choosing between making a bridge or a ring (6h)
  14. Automate tests for choosing between making a bridge or a ring (2h)
“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 him, as the product manager, asking them, “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 the following table:
“I don’t know about the rest of you, but I can commit to 4 hours over the next two weeks,” Rose joked. “With two programmers each getting 30 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 12 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 awhile 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 mid-way 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.
  1. As a player, I can play against a weak engine that recognizes rings (8)
  2. As a player, I’d like to be able to use the system to play against another human on my computer (5)
  3. As a player, I can play against a weak engine that recognizes bridges (2)
  4. As a player, I’d like to be able to use the system to play against another human on my computer (3)
“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.”   next previous

Related posts