User stories

- User stories are a common technique to help teams understand precisely what they're building. User stories provide a placeholder for conversation and continued dialogue about a specific piece of functionality from a user perspective. To provide some context as we look at what good user stories look like, let's look at one from our GoHealth app example. As a health club member, I want to view today's upcoming group fitness classes, so I can decide if I want to attend one. User stories have a who, a what, and a why. And in this story, the who is the health club member. The what is viewing upcoming classes, and the why is to decide I want to attend one. Next, let's look at a common model for determining if we have a well-articulated user story. It's called the INVEST model, and each letter stands for an attribute of good user stories. Let's dig in. I stands for independent. Each user story should be able to be implemented on its own, meaning, it can stand on its own and does not need to wait for other stories for the customer to see the value. Notice that the incremental value each story provides is from a user point of view and is independent. Creating a screen, and then a database table to support the screen, would not be an example of independent. Next is N. N stands for negotiable. Each user story should have just enough detail for the team to know what it's about, but also, it should have enough flexibility to allow discussion and evolve the design as the team learns and works. V stands for valuable. Each story must be valuable to the user or end customer, not a piece of what would be valuable if combined with other pieces, but truly, a single piece of value from a customer perspective. Next is E. It stands for estimable. The team needs to be able to estimate and have enough detail to move forward. This does not mean we know exactly how the story is designed technically in order to estimate. If it had this much detail, it would break the negotiable attribute. S stands for small. If the story is being considered for a sprint or iteration, it needs to be small enough for the team to consume, commit, and complete it. And, last, is T. T stands for testable. The story is testable from a user perspective, and has a good start on the acceptance criteria. The INVEST criteria helps the product owner prioritize, and then the team can estimate and commit. Many teams run into times where it seems like a story just can't be from a human perspective, or, they write technical stories where the who is a piece of technology, or something a technical resource needs to do for the product. Some of this is normal, especially to avoid incurring large amounts of technical debt, which we'll cover in another video. With these technical stories, there are a few key guidelines to keep in mind. First, the product owner still needs to prioritize them, so, the story must be written with an understanding of why it's valuable. To do this, I like to reframe these technical tasks into a user story that still shows the business value. So, let's say the team's technical lead recommends that the database be upgraded. To write this story and prioritize it as a product owner, I would first ask the team why they feel this is so important. Have this dialogue, and get to an understanding of value. In this case, it comes out that the database upgrade is necessary to allow for the expected number of users on the app. As a product owner, you want to be able to write the story in the following format to show this value. In order to increase the GoHealth app's user capacity to over a thousand users, we need to upgrade the database. This allows the product owner to actually prioritize how important this is in the context of other business priorities, even though it's a technical task. Communicating and writing user stories is a key skill that helps product owners keep value top of mind and communicate valuing user perspective to the team. These tips should help create user stories that generate great dialogue and move your team forward.