In the last couple of videos, you've learned techniques to make your stories better so you can drive to the heart of what's valuable for the user. Let's walk through some practice together so that you get a sense of how that might work in the real world in your own practice of writing great user stories. Now the story you see here. A lot of stories start here, and sadly, a lot of stories remain here. This story, people might tell you it's okay, it has all the basic components and stuff, but I think we can make this a lot better. There's a couple of things that I'd like to point out. First of all, on the second clause, I want to fix a unit quickly. I mean, sure, he wants to do that, and we want him to do it and we want to help him do it. But how is this testable, or even implementable in software? I mean, we're not there fixing the thing with him. So I think that we need to drive to something a little more specific and tangible. In the action clause, in this second clause here. And then, okay, so I can satisfy the customer. Well, this is another thing where I mean, we want Ted to satisfy the customer. We want to help him do that. We work at H and H. Let's say we want to have that happen. But how would we observe this reward with the user using the software on a very specific atomic basis; that kind of thing, the testing that we're going to learn how to do. I don't think that you really could. Just too general, and too vague. It has echoes of the kind of silly corporate speak that so many of us feel obliged to use in a cooperate environment. Take a couple minutes. We're going to pause and think about how you could improve this user story. All right, what I would do personally with this story is, I would take the kind of vague, general stuff, and I would make sure I decomposed it into problem scenarios, because yeah, it's important to satisfy the customer. But that's something that we would put over in these larger jobs to be done, things that matter, things that Ted wants to do. And then I would move forward to more specific user stories, testable narratives. And here's an example of a somewhat improved version of this story. I want to easily replace a part, okay this is a specific thing in the sequence of things that he does. That we think, where we think software might be pertinent and it's so that he can finish the job. Okay, and somewhat better. Why don't you take a minute and look at this improved version of this story, and think about if there's anything else you would do to make it better. More testable, more vivid, more specific. All right, here are a few ideas I had about how to make this story better. I made this last clause more specific. And if you'll notice, I remove the term easy. Now, is that because I want to make software that's hard for users to use? No, it's not. But, those kind of normative terms, easy, quick, efficiently, those have no place, really, in these user stories. In the problem scenarios, that's a great place to say that, well think they have a problem here, and we think if we did it quicker, well that would be a proposition that's really compelling. But, when we move forward to user stories, we're creating narrative that's supposed to help us drive to very specific software implementations. So those kind of normative terms don't have a place here and you should generally avoid them. And then I did something a little more specific in the final clause, so he can decide on his next steps. Because I didn't think that finishing the job, which is what this last clause was in the previous revision, I didn't think that was something we could really observe specifically if we sat subject down that resembles Ted and said, okay, you've found a part here, can you finish the job? Well, how are they going to know that. It's circumstantial. It has a lot of bearing on things that are external to the software. But, have you gotten the information to decide your next steps now, given the situation we put forward to them? I think that's a pretty testable narrative. This story has been approved a lot. A few tips as you're writing user stories and you're coaching the rest of your team on how to do it. First, be encouraging. Use phrases like, how might we make this story more testable? How might we bring some of the things that we saw out on the field into this user story? And remember, you're probably going to be pretty good at this by the end of this specialization, but your colleagues will just be starting. So try to remember back to the first story that you wrote and how it was probably pretty hard to get in good habits and be rigorous with yourself about what was going to make for a good story. And remember, what you want to have happen is that your colleagues can help you write really great stories so you're not the one always stuck doing it. Next, this question of how would we test this user story? This is probably the single most powerful litmus test you can apply to a user story. It really drives to the heart of whether the narrative has integrity and relevance and it's a really good way to just, a thing to constantly be asking yourself. And then finally it's really helpful to sketch what the interface might look like for some of these stories and that's not a permanent thing but it's a prototype, something that helps us think through our ideas and collaborate with others. So as we move forward here, I'll show you an example of that and you'll begin to sharpen your own skills and we'll do a lot more of that in courses 2 and course 4.
