Preparing Great User Stories

In this module, we’re going to learn about user stories. We’re going to learn how to create them and we’re going to learn how to use them to drive the narrative collaboration that’s really what’s at the heart of successful agile practice. And the user story has these three clauses that you see here. And they’re organized into epic stories and test cases. We’ll talk more about that as we proceed here. But I would like to mention that this thing that we’re doing with the user story is it’s really primarily about usability and improving usability. We talked about the difference between motivation and usability in the way they both contribute to successful outcomes in the last module.

So as we create user stories, we’re principally focused on how do we provide good experiences to the user. And the thing that we’re trying to avoid, with the stories, is this red button problem where we write user stories that are essentially just an arbitrary spec. And those stories are bad for a few different reasons. Number one, we very well may not be right that a red button is the right thing. And if we just say to our team build a red button here, we’re going to lose all the creativity and thoughtfulness that they may have about how to deliver the most valuable outcome to the end user.

And, additionally, it’s bad because when we just tell people, “hey, go do this arbitrary thing it’s your job.” Well, how do you think that makes them feel. They’re not very motivated because they don’t understand why and they feel like they’re just being made to do some arbitrary thing. It’s really important to be able to move through and tie the material that we covered in the previous module into your user stories. So the way we do that is we start with personas. We talked about those in the last module, module two.

And, problem scenarios, where we look at what are the underlying jobs to be done, habits, desires that we’re going to deliver on for our customers and how we’re going to do something that they’re adequately motivated to use. Are we going to deliver software that’s better enough than the alternatives that they want to use it? Is our value proposition better enough than the alternative? And, then, we figured that out. We move forward, we create software, and we use user stories and prototypes which is really what we’re going to focus on in this module. Stories have this structure whether its an epic story and then it’s details composed into these child stories.

So, the relationship between them is something like, I’m going to drive from Los Angeles to Boston. Well, that might be the epic. And then, I’m going to drive from Los Angeles to Phoenix, Phoenix to Denver, Denver to Chicago, Chicago to Pittsburgh, Pittsburgh to Boston. Those might be the child stories. So their job is just to decompose the narrative arc into more discrete specific components. And that’s really important because if we don’t have nice specific stories where we’re describing the nuances of the user experience at each point, then we’re going to spend less of our time and less of our effort as a software development team focused on what’s really going to make our executions valuable. Let’s look at an example.

So, our persona is Ted the HVAC technician that we’ve been playing with. And, we learn, that he has this problem that getting parts is hard and it holds up jobs. And we think that more standardized, more automated part-sorting process would be valuable to Ted. And, so we’ve validated that to our satisfaction and we’re moving forward with decomposing that into a narrative that we can then take and use to create what we hope will be a valuable software for Ted.

Another nice thing about this framing of what you’re doing and why, is that if you release a feature into the market and it encounters this echoing silence, nobody cares, or worse, you know users just don’t like it, then having the structure allows you to kind of debug that problem a little more thoughtfully and a little more reliably. So, if we have a situation where the users don’t like a feature, we might first ask, well, what were the stories and do we do a good job of implementing the interface against those. Was it usable for the users when we did testing? Maybe we need to take a look at that. Then, we might look at the sources of motivation.

I mean, how do we know that the users really wanted this in the first place? And we would look back at our assumptions about that and how did we test that. Is that something we need to spend more time on? And then we look at, was the problem really important? Did we deliver on a job, a desire that was really important to the end user? Or did we solve a problem that nobody has? In which case, we know, we’re going to get a non-reaction from the user. And, ultimately, who is this user and what makes them tick? Did we build software for someone that doesn’t exist if we misunderstand them in some important way?

These are the things that we’ll do to figure out whether, we know, what we need to do as a next step. In this video, we’ve looked at how to tie your work that you did in module two forward and backward into interpretations and user stories. As we move forward here, we’ll look more at how to create those user stories and apply them to narrative collaboration with our team.