In this video, learn how to define a user story and use case.
- Project requirements strive to be written in clear, direct language. It's usually when you turn this clear language into work that you realize that there's a lot of room for misinterpretation. Unfortunately it's almost impossible to predict how each person will interpret your language. Often a quick conversation is the only way to make sure that everyone knows the work. Agile projects don't use traditional project requirements. Instead the product owner maintains a set of user stories for the project. A user story is a conversation vehicle. It's a short story from the users perspective about what they find valuable in the product. A common user story format is as a user role, I want, need, can, et cetera, a goal so that reason. For a website there could be many user roles. Say you've created a user role called premium customer. Now you've attached some business value to that role. For this story you might say, as a standard customer, I want to see a list of benefits of upgrading to a premium customer so I can see if it's worth the cost. A user story accomplishes two things. First it uses the customers language. The product owner doesn't need to know how to build a web server to ask these questions. There's no talk about the how the website will work. The story is only about the what and the why. This will be much easier for the product owner to understand and prioritize. The story format is important because of what it doesn't say. It leaves the technical decisions up to the team. It's very important for the product owner to not swim in the developers pool. They need to leave the how to the development team. Second the story is immediately linked to some business value. You could tell from the story that the standard customer really wants to find out about the benefits of upgrading. Maybe there's a better way to do this. Maybe a window after the user logs in. A good way to create user stories is to think about the three Cs. This comes from the world of extreme programming and it stands for card, conversation, and confirmation. User stories are best recorded on a three by five index card. Many product owners are tempted to create a user story spreadsheet. If you try to do this what you'll find is that it's more difficult to communicate about individual stories. You don't want to overwhelm the group with a list of information. Instead you want to have a group conversation. Many times when an Agile team is starting out, they're very focused on the format of a user story. What they forget is that a user story is a means to an end. It's not about the format, it's about having a group conversation. The final part is the acceptance criteria. This is the confirmation that everybody knows how to deliver the story. This is typically written on the back of the card. In the language of extreme programming, this will be the definition of done. It's very important that the acceptance criteria closely match the user story on the front of the card. It should be the result of the conversation with the development team. This will go into much greater details on how to deliver the story. The acceptance criteria are a good way to keep the user story from becoming to convoluted. You can add a lot of details to the acceptance criteria without putting it on the front of the card.
- Explain how a sprint differs from a traditional project.
- Name three user roles.
- Define the acronym INVEST and explain its purpose.
- List three main sections of a project charter.
- Identify the benefits of planning poker.
- Recall the challenges associated with the sprint backlog.