Agile Case Study (2/5): User Stories

By Jose Barato

May 17, 2021

31 minutes read

Let’s continue reading chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In this second post you will realize about the convenience of writing down physical cards and how to conduct a brainstorming session to make team members infer requirements, a.k.a. user stories. A piece of advice: try to follow thematic areas during the brainstorming to cover all requirements.

Team members can also estimate size and complexity of requirements in a game named planning poker: user stories can be sized using non dimensional units known as story points. Later on, big user stories will have to be broken down into more manageable ones.

One basic rule to follow: Good defined user stories should be INVEST –Independent, Negotiable, Valuable, Estimable, Small and Testable.

Now you can read how is a session to collect requirements in an agile project. At the end of the session, that could take between 2 and 4 hours, team members of the Havannah project will have agreed on 32 user stories and the project sizing of 146 story points.

Do you want to know how to do it? Just keep on reading…

[…]

“So how do we get started writing the user stories?” Frank asked.
–Vamos a usar estas tarjetas –dijo Carlos, a la vez que le daba un paquete de tarjetas a cada persona–. A mí me gusta escribir historias de usuario con esta plantilla. –Carlos sacó un rotulador y escribió en la pizarra:

“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 on the white board:

“As a [], I want [] to so that []”

“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. “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 his story card: 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: “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 and wrote: 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. Hopefully 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.

Brainstorming to write User Stories

A few minutes later the team had produced the stories shown in this table.

“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 are 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 want to do during a game.” The team answered Carlos’ question by writing the stories:

“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 this other list:

“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 with Story Points

“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 3 points. If we think that restoring a saved game will be the same effort then we’ll call it 3 points. If we think restoring a game will be a little less, we’ll call it a 2.” “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 continued as he handed each person a set of note cards with the values 1, 2, 3, 5, and 8 handwritten 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 to. We mostly need to just 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 1,” 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 avoids any bias.” He paused. “It looks like everyone has picked a card. Turn them over.

Cards ranged from Allan 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 1. He said he could and the first story was estimated at 1 story point. “Onto 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 and 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 2 for the story.

Breaking big user stories down

“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? 1-2-3, turn them over.” Everyone turned over a 1. “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, anxious 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 awhile 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 only supposed to hold up 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 19. Really?” Sasha asked while double-checking the 8 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 awhile.” “Well, you’d know. But 19 is huge,” Sasha said. “Prasad, why do you think this is a 3?” 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 3, 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 20 this time. “It looks like you convinced everyone, Allan,” Carlos said. “A 20 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 it’s own pattern, ignoring the human’s moves. I don’t think that’s a good idea though.”

“What if a first engine only recognized 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 only tried to make—and block— 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:

“When those were one story the estimate was 20. Now it’s 21. Should we take a point off of one story so it’s still 20?” 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 8 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 8. I don’t have a 16 though. Do we use 13? That’s the closest. Or do we make up a 16?” “What you want to do,” Carlos said, “is think of the cards as buckets. If this story is a 16, it won’t fit in a bucket that holds 13. We don’t want to make up new values because it starts to look too precise. We don’t know if this is a 13 or a 16 or a 19. It’s important to remember that these are estimates, not guarantees.” “OK, I think this is 2–3 times as big as the medium engine,” Allan said. “That means it’s 16–24. Since 24 won’t fit in a 20 bucket, should I estimate it as 40? 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 20. “So we’ll call this story a 20,” 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.

Making User Stories Independent

“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 vs. 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 2 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 8-point stories to 7 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 5, we can. Otherwise, let’s leave it as an 8.” “No, 5 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 3. “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 to do with dependent User 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 then this story has to be at least as big as writing the whole move engine.” “So we have a dependency that we can only do hints 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 1 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 1, 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 onto 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.

Brainstorming Outcome: 32 user stories and 146 story points

The stories and their estimates are shown bellow:

next previous

# Tag # agile # Agile project management tool # Construction project management software # Digital Project Management tool # Gestión de proyectos sin procesos # Online project management solution # Professional Project Management Tool # Project collaboration tool # Project management tool # Project Portfolio Management Software