In the last lesson, you learned the basics of how to write user stories and tie them to a strong narrative about your user. In this lesson, we're going to look at some more advanced techniques to improve the quality of our users' stories. So let's go back to this epic that we've been playing with from the H and H team, and we're going to think about it in these terms: trigger, action, and reward. These are a set of concepts from psychology that I first learned about in this context working with Nir Eyal, and the trigger is something that initiates the problem scenario. What is it that happens where we think the user wants to go do whatever it is we're thinking they want to do at this point? And that could be an external thing, like the software tells them to do it or it could be an internal thing like oh, geez, I want to check ax or do that or whatever. And then the action happens, so what is the user actually doing? And this is where we're trying to do a good job on the X axis of our fault curve. We're trying to make the most usable possible experience for the user and minimize that action. And then finally, we have the reward here. Where the user has some kind of conclusion to this story even, if it's really small and discreet. So somehow the persona is gratified, they understand that they're done and can move on to the next thing. So let's look at how this would play out for this epic here. It would look something, I think, like Ted completes a problem diagnosis that requires a new part. So, he moves on and he wants to go find the part in the H and H system so that he can see how long it's going to take to get it and how much it'll cost so that he can go talk to the customer. And that's the reward. Does Ted walk away with that understanding or not? And that's how we would test it. So one technique I like to use to think through epics and just really escalate the volume on the quiet screens of all the little details that we neglect to deliver to our users is story boarding. Now, dear learner, if you're thinking this looks kind of puerile and silly and I don't really get the need to do this. Well I would say two things. One, I understand. Almost everyone that first story boards a user story thinks it's unnecessary, it feels childish, thinks why, do I really have time to do this? But I'll also say that everyone who tries it out, just about everybody finds that it helps them write much better epics and identify the important details that accumulate together to make a really great, valuable product. So let me take you through this and you can see what you think. I showed Ted here, finding this part that he needs to identify and potentially order. We have our first case. Okay, I need part number XYZ. He knows the part number, or maybe it's printed on this thing somehow, somewhere. And the second case, this is sort of a parallel case, is he doesn't know what the part number is but he thinks that through the reference materials that we're going to make available for him, he can figure it out. And then the third case is he's stuck. He doesn't know what this part is. And one thing the H and H team saw the technicians doing out in the field is snapping a photo with their phones and then emailing their colleagues back in the office to get help on identifying the part. So this concludes, and we know that Ted now wants to know how much is thing going to cost, and how soon could I get it, so that he can conclude and talk with his customer about what they want to do next, and how soon he can fix their HVAC. Now, this may look particularly self-evident because we've already gone through this epic a bit, but remember the tapper problem. We really communicate a lot less to our collaborators than we think we do. Storyboards are not only a good way to think through your ideas but to bring them to life for your collaborators. Now, one thing that you'll notice is that this particular epic doesn't have a nice, simple happy path here. And it's important not to force your epics into a simplistic view of users always doing what you expect. One of the skills that really good product designers and software leads have is that they understand In the building, it feels like we got lots of control over what our software is going to do and what's going to happen. But that control is an illusion. We really don't know what's going to happen when our software encounters users, even if those users are inside the building somewhere and external to us, there were, let's say rolling out some enterprise software internally. We really have very little control over what actually happens. And it's just important to acknowledge that. So a good epic will often be more of a web, something like what you see here. In fact, if we look at the epic we just went through for H and H, it kind of has this thing where it fans out in the very beginning depending on does Ted know the part, does he not know the part, is he going to look it up? And then it moves forward to kind of a more we think linear set of conclusions. In this video you learn how to use storyboards to think through your narrative in more detail and really bring out the details that may turn out to be very valuable to users. Or another of looking at it is you learn some techniques so you don't force your users into a simple path that really doesn't accommodate the reality of the things that they want to do. And as we move forward here, we'll look at some other techniques to coach yourself through writing better user stories. Stories that are more vivid, more actionable, more testable and also, how to make those more consumable and more interesting for your team so that you all can really drive that narrative collaboration that's at the heart of successful agile practice.
