Coaching for Better User Stories

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 you get a sense in how that might work in the real world in your own practice of writing great user stories. As 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 this second clause, I want to fix a unit quickly. I mean sure, he wants to 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 HNH, let’s say. We want to have that happen.

But how would we observe this reward with a user using the software on a very specific atomic basis, the kind of testing that we’re going to learn how to do. I don’t think you really could. It’s just too general and too vague. It has echos of the kind of silly corporate speak that so many of us feel obliged to use in a corporate 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 decompose it into problem scenarios because yeah it’s important to satisfy the customer.

But that’s something that we would put over in these kind of 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. Where we think software might be pertinent, and it’s so that he can finish the job, okay.

It’s somewhat better, why don’t you take a minute and take a look at this improved version of the 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 removed 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, we think they have 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? 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. And 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, how might we make this story more testable. How might we bring some of the things that we saw out in the field into this user story. Your colleagues will just be starting, so try to remember back to the first story that you wrote and how 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.