User Stories

When you were a child, did you ever play the game of telephone here in the US in elementary school. It's kind of a popular game for kids to play or. Well, I don't know. But it still, as it used to be, one person whispers in the ear of another person, a sentence or a phrase, and then that person whispers in the ear of the next person and so on, right around the circle until the message comes back to the original person. And it never sounds at all like what was originally communicated? No, it's sort of. The message is lost. And as it moves around through the handoffs and the interpretation, it just gets confused. Shared understanding is difficult. So what are some techniques to get to better shared understanding? Well, we want to introduce you to user stories. They're the industry standard term for how we deliver the smallest unit of value within a sprint. They're derived from the product backlog and each story will comprise a component of the product we're working on. Who can write these user stories? Well, anybody. The product owner will typically accept them into the backlog and prioritize them, keep them in order and probably write quite a few of the user stories. But anybody can write them. Developers, Scrum masters, any business analysts, whatever role we have on the team, anybody can write user stories. When will we write them? Well, they can be written before we start development and maybe a Sprint zero type activity. What I would say is we want the least amount of stories written so that we can begin. We don't want to try to build out a whole backlog of all the stories we can possibly think of. That's kind of like what we were trying to do with requirements, but then they continue. We continue to write user stories throughout the, throughout the life cycle of the product. So what's included in a user story? Well, there's, there's three components. There's a title and a description and acceptance criteria. Those are the three pieces of a user story. So let's, let's look at each of those. We're going to start with the description of the user story. Now, this is written in a certain format as a. I want. So that seems a little strange, but bear with me as a user of the product, maybe as a system, whatever the, whoever is going to consume this story, whatever is going to consume the story as a I want to do something, I want to see something, I want to display something, I want to secure something. What is it you want to do? And then so that. Why, why do you want to do that? And really focusing in on what's the value that will be released in this user story so that we're going to talk about acceptance criteria. Acceptance criteria is the component that helps the team know how they will be able to be done with this, how will be accepted by the product owner? How will the developers know that they're. They're done building? How will the testers know how to test it? How will the product owner know how to accept it? And the title? The title is derived from the description. It's a short summary of the user story itself. So let's take a look at an example. Here we have the title, new music recommendations and the description. As a frequent streaming music listener, I want to have new music recommendations when I start the mobile music app so that I can expand my musical palette. Take a look at some of our acceptance criteria recommendations from the most recent listening activity. No more than three recommendations displayed multiple genre options and ability to see more recommendations. Now, a couple things to note about that user story. One is the acceptance criteria is really focused in on helping us define, okay, this is how we'll know this will be finished. This is how we can test it. This is how I can accept it. And the description is focused a lot on the. The what, what is this user trying to do? Not how this is. This is a very important piece of user stories. They're focused on the what we want to build, not how to build it. So, so the, the development team now has some freedom to think through how they might, how they might build out and complete this user story. Now, there are some, some guidelines to writing user stories. I want to introduce those to you. Really. I want to introduce the INVEST acronym. This is very popular. And is it independent? Is the story independent of other stories in the backlog? Is it negotiable? Negotiable meaning like is there opportunity to have discussion with the product owner and negotiate this story as we begin to work on it? Is it valuable? What's the value that we're going to release? Each story should have defined value that can be released. Can we estimate it? It's got to be small. Smaller batches go through systems faster. So small is a story small enough to be completed within this brand and then testable? How will we test it? How do we know how to test it? So the INVEST oftentimes when I am talking to teams and listening to their stories, I'll take some sample stories and just run it up against this INVEST mnemonic and sort of say, well, are they independent? Is it testable? What's the value being released Very, very helpful to do that. Another component to take away when thinking about user stories is the three Cs. Now back when we first started doing this, the first C card meant that we would write the user story on a card, usually like a three by five index card. And the user story get written on the front and the title and the description. Then the back would have acceptance criteria. Well, what's the point of that? Well, it's got to like, we don't want big verbose requirements, we want to fit on a card. And then the second C is conversation. I'll tell you the best description I've heard of a user story. A user story is a placeholder for a conversation. Yeah. That's how we get to shared understanding. It should be a conversation that's occurring now. That doesn't mean that we don't document anything. Of course not. It means that I want to have that conversation, I want to have that negotiable part of invest, I want to be able to negotiate with my product owner. And then lastly, confirmation. This is where acceptance criteria really helps us. Like how will we confirm that we're done with this? So the three Cs of user story writing and sort of one more piece here to talk through. When we think about techniques for shared understanding, user stories fit within a sprint. Sometimes there's larger pieces of work there. Lots of times there'll be larger pieces of work. Just in simplest terms, we call those epics. Epics are comprised of stories. Stories are delivered in sprints. Epics can span sprints. So it might be a larger component of a product we're working on. So in that music streaming example, an epic might be, you know, write the mobile app, create the mobile app, Create a new release for a mobile app that could be an epic that gets delivered over sprints in user stories. Epics might be, in addition to being big, they might be highly complex and there might be a lot of risk in those that need to be sort of researched and found out through user story delivery. And these epics should be decomposed into user stories. And we might do like a user story workshop where we break those things down to put into the product backlog. So that's a little bit on epics, techniques for shared understanding, epics and user stories. User stories are the primary value delivery you'll spend most of your time with at the team level. So really important that you get good at writing user stories.