What are User Stories?

January 30, 2020

Jake Anderson

In our software development process we utilize a deliverable called “user stories”. These user stories help to provide shape to oftentimes complex or involved development features. They help to break down what needs to be done into manageable (ie digestible) units that the client can understand, the project manager can understand and of course the developers can understand.

User stories provide the end goal of what needs to be accomplished, leaving room for unknown variables that might come up, but not enough “space” that shared meaning is lost. Each of these stories is then efforted and tied to a dollar budget. 

They are a crucial component of making sure expectations are aligned and a software project goes smoothly. 

Tony: In our process we use something called user stories in development. Talk to me. First, what are user stories?

Jake: Some people think of user stories and they think of agile. Of, “Oh, well we’ve got a milestone or a group of things that we want to try to do and there’s these individual tasks (what are known as user stories) of trying to complete those. As a user, I should be able to do this.” And while we do like that approach, that’s not necessarily how we think of user stories. Now, the definition and the way that we write them is very similar, but it’s a little bit more granular and it’s more upfront when we start working on the scope of the project. And its main purpose is to understand what you value for each aspect that we’re building out. We might say, “Hey, we’re going to build a way for people to log into your system.” “Okay, what’s that worth for you?” “How many days do you want us to spend on it?” “Okay, call it four days.” “Okay, cool.” And so from that day amount, we can now give you a cost and you can better understand what value you’re getting versus what you’re trying to achieve. And what’s great with these user stories is if all of a sudden we accomplish this story in two days rather than four days, now we have some flexibility and we have some creative freedom within this. So all of a sudden you say, “Hey, we want someone to be able to sign in with Google or sign in with Twitter.” “Great. Well, we have a couple extra days, let’s see if we can get that in there.” And you just got something really great at no additional cost to you. So, the benefit is that you as a client get more. And for us, obviously, we get a little bit of protection in terms of the time. So it is kind of this nice balance between the two. But in order for you, as a client, to get the most out of it, you’ve got to be more engaged and you have to maybe make — and be more upfront with some of the sacrifices that you’re making. And for us, we have to be more flexible and willing to just [?contend 02:18] and continue and work even though we’ve kind of completed the scope of the project. So if all of a sudden we got login done in one day, cool. That’s great for us. Now we can launch this product one day sooner. But if all of a sudden you’re like, “Oh, I want to spend three more days on this,” well, we have to go to ourselves and say, “Well, we told them we’re going to do it for four days and so we’re going to keep going another three days and see if we can accomplish.”

Tony: So you covered a lot of ground there. To pull a couple of key points out, user stories for the laypeople is really a story about the user, and it’s a story about the user that we tied to efforts. And again, like you mentioned, typically used in an agile fashion while we might be kind of doing a hybrid approach on that. There might be something such as, “User needs to be able to login to the site. A user needs to be able to create an account on the site and enter these key details.” And then it’s efforting that out. And so, it’s giving some shape — talking kind of about building the right thing — to what we’re trying to do. Because there is so much ambiguity around some of these ideas — like you said it’s, “Hey, what is the user — what are we needing them to do to tie to this value? And then, what does that effort look like? Do you value that effort as a business? And then, “Okay, we’re going to go execute that. If we’ve got more time, we can do other things. If we’ve got less time, it’s at least going to help provide as a stopgap to have that discussion with you as a client. Good summary?

Jake: Yeah. No, exactly. And I think that there’s one more thing to kind of point out here, and it’s the fact that when we have these stories — we’re trying to take a concept or something that you’re trying to build, and like you said, shape it. And maybe at your company, it’s just been a whole bunch of meetings that have made this idea. And it’s just people talking together, it’s all in someone’s head. But as soon as we write down every single piece that makes up this application that you’re trying to build, well now we’ve taken something abstract and made it a little bit more concrete. And so, when we ask you, “Are we missing anything?” you as a client are more easily able to be like, “Okay, this is something that I had as an assumption in my mind. There it is, there it is, there it is. You know… perfect. So now we have everything and we’ve extracted all the assumptions that you’ve had. Or if all of a sudden there’s something in there that — that’s not in there, well now you can start talking about it and saying, “Hey, we didn’t have this in here. This was my assumption. Let’s get that on there.” Or later down the line, you’re like, “Oh, we really need to add this in here. Does this fit in any of these stories?” And we can say yes or no. And depending on that, we can figure out what do we want to do moving forward.

Tony: Yeah, definitely. I think it helps lay the foundation and create the pipeline and flow for accountability and shared meaning, which when we’re dealing with ideas and thoughts and concepts that could change so rapidly in a person’s mind, it’s about kind of understanding those from the start, agreeing to those, and utilizing that as the strategy forward, because the biggest risk is that changing mid-development, at any point.

Start a Project