In the last video you learned how to tie your user stories back to the work you've done, to understand your users and what they care about, so that you can drive constantly to sources of value in your software. Here in this video, we're going to look at how to write user stories. We talked in the last lesson about epics and child stories. We're going to look through some examples and learn how to decompose our ideas about user experience into nice, soluble pieces that continue to tie back to that central narrative that we have about the user. Fun fact about the history of mathematics. Especially in the early days, it turns out that the really breakthrough mathematicians had to have two things. One was these incredible ideas about how the universe works. But the second thing was the notation so that they could describe those ideas and hand them over to other people, to move this body of practice forward. So, in mathematics you have these various types of notations that turn out to be really important. And in software development, we have the agile user story. So, you've seen this, you've seen it's three clauses. We've talked about the relationship between the epics and the stories, and we'll talk more about test cases as we go through this. Let's talk about these three clauses that you see for a minute, and why they're important, and how you can do really well on each of them consistently as you write user stories. So on this first one, we want to make sure we're constantly tying back to who is this user that we're going to to build something for. What makes them tick, what do they care about, who's an example of this person? We want to make sure we're constantly humanizing them. And that's not just because it's good to be humanizing and design says so, it's because that turns out to be the most consistent. The most actionable, and the most testable way to create really good software that users like and find valuable. And then, in the third clause, we have this clause, realize a reward. Now that sounds kind of abstract. We're not talking about the California lotto here, we're talking about a simple discrete, ending to the user story. So what did the user want to achieve in this story? We want to make sure we know that. And how will we evaluate whether they got that or not? So let me give you a specific example. Let's say I'm a salesperson. I'm walking out of the airport, and I want to update a lead about an account I was just visiting on my phone. The reward for that story will be as simple as, I put the information in and hit save and the software tells me, all set, you're lead's been saved. Or, there's a problem here, fix this and I loop back and I save it. So that's what we mean here by reward. It's a discrete, successful conclusion to the user story. Now, the stories, as we have discussed, they decompose into epics that then have child stories that create more detail for them. And you can see an example of a user story about HVAC in a hurry here, decomposed in that fashion. Let's look at that in a little more detail. But first, let me give you a caution about writing epic stories. Now, this is a standard term, so we're using it here, but it can be a little bit misleading. And most learners who first start to draft user stories, draft them too broad. And we'll look at what that means and how to coach our way through that as we go along here. But an epic story isn't for instance, something that encapsulates the whole idea of your product, or even the whole idea of your feature in most cases. It's still relatively specific and discrete. And the reason we want to make sure our stories aren't too big and too general. Is that if we don't have nice discrete specific stories about all these different facets of user experience, we're not going to have a nice tight linkage with what we're building, and the sources of value that are going to be important to the user. So epic sounds big, but they're still, should be very specific and discrete, so let's look at some examples here. These are all about HVAC in a hurry, and some of the problem scenarios that we looked at in module one. They want to identify a part. They want to understand how to arrive at their next job prepared so that, they avoid delays and they avoid having the customer repeat themselves what they wanted. So, if you though these, they're relatively specific. And these are epics, and we're going to decompose these into even more detail with child stories. So let's look at an example, we'll look at this first one here about Ted. How would this break down into child stories? Well, here are some examples. Now, as I thought through this with the HVAC in a hurry team, we saw that really there are sort of three things that can happen initially. Ted the technician, he either knows what the part number is and he just needs to find the part that he wants in the HVAC in a hurry system. Or he doesn't know the part. And thinks that he can figure it out from the reference materials. Or he really has no idea what the part is, and he needs some help. And we've observed Ted in module one going and doing all these things, or rather research subjects that tie back to the persona of Ted the technician. So he figures the part out, and then he wants to find it and understand some things about it, so he can move the job forward. So here you've seen how an epic decomposes into child stories that describe it in more detail. Now we may have even more detail than this. Specifics of these various stories that we want to make sure of in the software. And in the next video we will look at to layer a little bit of supplemental detail on to these individual child stories with an item we call test cases.
