By Rebecca Jones
In Episode 42 of The Board, we talk about:
Read our Introductory series on user stories.
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.
Learn what Scrum Product Owners need to know about user stories.
Gavin Coughlan: Hello, and welcome to another episode of The Board. I am Gavin Coughlan, agile coach here at Boost, and I’m joined by…
Jesse Stegmann: Hi, I’m Jesse, also an agile coach here at Boost.
Gavin: This is episode number –what episode number is this, Becka? 42? Wow.
Today we are going to be talking about user stories. The reason that we’re talking about user stories today, is it’s just come up a lot for me personally over the last couple of weeks from a variety of different situations. People find the user stories difficult to write, and people misusing the term “user stories” a bit recently as well.
For example, I was in a pub, just speaking to somebody who is a new scrum master. They were saying to me that, “User stories don’t have to follow that template. It’s ridiculous.” I said, “Well, actually they do, otherwise it’s not a user story, it’s something else.”
I suppose sometimes it’s simple. It annoys me sometimes when people get a hung up by the terminology, but I got a fear that if you’re going to misuse the terminology, “User story,” people are going to get confused. What we are going to talk about today is what is the user story, some of the common problems that you might find with user stories, why it’s difficult for some people, and the importance of breaking down your user story. We’re going to finish up talking about job stories which is a concept that Jesse came across recently.
For anybody who isn’t aware about user stories, I suppose we better describe what they are first of all. A user story is a way of getting a requirement across or expressing a requirement. And you really take that word requirement out of the situation altogether. It’s written in a template. Every single user story is written in a template and expressed from the user’s point of view.
What is a template, Jesse?
Jesse: The template is as a persona, I want an action so that I can achieve an expected outcome or benefit. For example, as a new customer to an e-commerce website, I want to be able to sign up to the newsletter so that I can find out about weekly deals or any specials that might be on the site.
Gavin: I was first introduced to user stories as a…I found it just a really, really valuable thing because we have to really think about the end user and we are making sure what we are building was actually going to benefit those users. And as many people watching will know — many people may not — it’s quite easy to drop off that last bit of the template.
You might say, “As a frequent visitor to Hannah’s Shoes Store I want to sign up to a newsletter.” You might just stop there if you can think of the benefit. I that case the benefit might be so I can keep up-to-date with daily deals and save some money.
If you can’t think of the benefit at the end of the user story, I found you have to revisit and rethink about why you’re actually building this in the first place. Just thinking about everything that you’re building from the point of view of the person who’s actually going to be using your software, website or whatever it is, I think is really, really valuable.
Jesse: Sort of dropping the [inaudible 03:27] that can actually be a very valuable tool for a scrum master to have, I suppose, coach product owners and have conversations about, “Are you building this because it’s actually going to benefit your end user?” Or, “Are you just building it because you think Facebook integration is really cool?” “Everyone’s doing it so we need it too.”
Gavin: Yeah, exactly. Kristen Donaldson has left a message. She said, “You’re in a pub. No way.” Yes, it’s my first time in a pub. Didn’t like it. I don’t think I’ll be back.
[inaudible 04:02] stories will have something called acceptance criteria within them as well. They’re the points that need to be met so that the developers know that the story is actually complete. It can be tested. Data is complete, measured and the products [inaudible 04:12] looking at the acceptance criteria and say, “Yes. Check, check, check. They are complete.”
For example, as somebody sign up to the newsletter example, the acceptance criteria might be that user must supply name and email. User’s details must be added to a database, user must receive a confirmation email that they have successfully signed up to the newsletter. They might be the acceptance criteria for that story.
Jesse: I think the important thing again is this is where sometimes people turn user stories into a big list of requirements again. Acceptance criteria, again as with all things, we want to leave solutions up to the team and just use acceptance criteria to make sure that whatever solution they provide is meeting the value for the business.
We don’t want to start saying things. Again, using the newsletter example, we don’t want to say, “It should be stored in MySQL database using these types of field and send confirmation email using X or Y tool.” We want to leave those open for the team to be able to find their own solutions.
Gavin: That’s right. People often talk about the three Cs of user stories. Three Cs being card, conversation and confirmation. What do they mean to you those three Cs?
Jesse: I think the conversation is the most important bit. Is not relying on the user story to cutout the conversation between the team and the product owner, because we talk a lot about individuals and interactions in agile, and the user story is another way to encourage an interaction between the product owner and the team. That conversation, I think, is the really most important, in making sure that the product owner can communicate their vision to the team. And a written document is not the way to do that.
Gavin: That’s right. And user stories, they’re never set in stone. They’re to launch a conversation, and they go through these stages of conversation, right from backlog grooming to sprint planning, to your sprint review, and all the way through the sprint itself, as well. It’s always being discussed. It’s not just a requirement that’s there, set in stone, and people go in, build it, and that’s that.
Jesse: Yeah. And again, you can have quite a big feature written as a user story, with maybe two acceptance criteria. But as long as those acceptance criteria capture the value, and you’ve had a really good conversation around the story, and the team knows exactly what the product owner expects, I think that’s enough.
Gavin: Yeah. I did sit an exam for one of my agile certifications, before, and one of the questions was, which should have more letters in it, the user story or the exceptions criteria? I thought that was a very strange question. I think the right answer, apparently, was the acceptance criteria should have more letters, but I completely disagree with that. I think that’s nonsense, though, actually …
Jesse: [laughs]
Gavin: So, user stories. That’s basically what they are. We’ve been using them for many years. I suppose we’re lucky, in our situation, because we are always creating sites or software, and apps that people are going to be using. It’s not easy, but it’s easier than it is for people in other situations, for us to write stories written from the user’s perspective.
I suppose that brings us on to, what are some of the common problems that you find with user stories?
Jesse: First of all, I think paid people can sometimes get lazy with user stories. I think sometimes they can say, “As a user, I want to just say user,” which is very easy. It’s nice to come up with a fully flesh-out persona, somebody who has certain traits that the teams understand. But a lot of people just write, “As a user, I want to, say, sign up to a newsletter, so I can have signed up to a newsletter.”
Gavin: [laughs]
Jesse: And the benefit is just the action. Not even reworded. I’ve seen that happen quite a lot. That’s just people getting lazy about writing that benefit. These are just some of the issues I’ve seen. But I also see people find it incredibly hard to write user stories when they’re in certain situations.
Gavin: Yeah. I suppose, I think one thing that people do find, or sometimes find hard, from the product owner side, is when they’re writing a user story, and they’re thinking about a really large feature, they can sometimes struggle to, they just write sort of a long letter, of a user story, that kind of rambles along, and they’re not really sure of the exact benefit. Those can often, I suppose ambiguous user stories are also, we’re talking about succinct, really well-structured user stories as being great, but you can get these really long, rambling, very unclear user stories, as well.
Jesse: It’s like that, to paraphrase a Mark Twain quote, “I didn’t have the time to write you a short letter, so I wrote you a long one, instead.” It’s sometimes easier to ramble on than to keep things a little bit succinct. I do see people struggle with user stories if they’re, for example, a team that’s largely concentrating on infrastructure, or something that the user isn’t really going to see, themselves. It’s really difficult to write a user story when you’re in that situation.
Gavin: Yes. Yeah. I’m working with a team, and we’ve been on a project, I think it’s now six years old. We’ve been running scrum for the entire six years. And in those situations, we do, do a little bit of what you talk about, of just sort of writing as a user, “I want stable infrastructure.”
Jesse: Yes.
Gavin: Where, that’s not really, as a user, they don’t really care about that, and it’s not a clear benefit. But I suppose we find that keeping those things in user stories helps the team manage the work.
Jesse: Yes.
Gavin: And they’re not a regular occurrence in the sprint.
Gavin: Mm-hmm. And just another question, here. Do more detailed specs have their place in story creation?
Jesse: It depends on what you’re talking about. If you are interfacing with an API or doing some sort of integration, obviously, I don’t know that it needs to be an acceptance criterion per se.
Gavin: No. Sometimes you see attached to stories. Say you have something that has to talk to an API. You might have some of the specs attached to the story for reference from the team.
I’ve seen stories as well which might have some just high-level UI work done on it as well attached to user story. In that situation, it’s OK, but, yes, not to list out all these specifications as an acceptance criteria there.
Jesse: Often, those specifications are implied by an acceptance criterion.
If you were — trying to think of an example of an API integration that you might be using — say, for example, using Google to do all your user management, and the user can update their details in your app, if your acceptance criteria were, “All changes are reflected in the user’s Google account,” then you could spec out exactly what needs to be sent to Google and what needs to come back.
But that first acceptance criteria, if that happens, what’s the point in all the other specs? Yes, it does have its place, but we tend to use attachments to the stories or something like that to keep those sorts of more detailed specs rather than acceptance criteria.
Gavin: An interesting thing about user stories that it is worth mentioning as well is that it’s not specified to be used. In scrum assist, people choose to use them. Sometimes people feel like, “Oh, we have to use the user stories,” but you don’t have to use the user stories.
If you really want to try something else, absolutely try something else, whatever actually works for you and helps you to work in an agile way. For us, we find that user stories are really, really useful.
One of the other common problems that I find is people having difficulties breaking down user stories. That’s probably the biggest issue I see people having. It’s really difficult when, if they have a job that’s going to take somebody four weeks to do, they think that cannot be broken down.
This is a really common thing that, when we work with new teams, they invariably think, “Yeah, none of the stories can be broken down.” I’m sure a lot of people who are watching now, but for those who don’t, the INVEST model is something that’s really useful. It’s an old acronym in agile, but it’s still a very, very useful and valid one.
The INVEST acronym is I for independent, trying to keep those stories’ dependencies out of them, if possible. They’re all negotiable. N for negotiable, so you should be able to talk about them. They’re not set in stone. V, they should be valuable. Each story should create some value.
E for estimable. They have to be estimated by the team. If they can’t be estimated, there’s something wrong with it. S, they should be small and really important so they can actually be completed within a sprint and flow through the sprint. T for testable. You have to be able to test them.
That acronym has been around for a while. It’s hard to make a story fit in all there. It’s not always possible to make your stories independent. Just, in a perfect world, try to make them…
[crosstalk]
Jesse: I suppose that’s occasionally where you have that conflict of having independent stories and small stories. As people are trying to make their stories independent, they include all the dependencies in one story, but that makes it really large.
What I tend to find is the team often has the ability to break down stories really easily. If the product owner can provide their overall value proposition in one large story, then the team often knows how to say, “All right. Well, why don’t we do this little bit first, and that second, and then the third bit after that?”
Unfortunately, yeah, those three stories will be dependent on each other. But, like you said, it’s very hard to have that INVEST model all the time.
Gavin: I think it’s more important to have it small than independent, if you have to choose one over the other — that’s just my personal opinion — because you want the stories to be able to be completed and accepted within a sprint, or else it’s going to fall apart a little bit, and people are going to get demoralized.
People sometimes say, “How small should you break down the story?” That’s an interesting one. There’s some common sense applied there. You don’t want to get too [inaudible 15:55] . If a story is longer than, say, six other sprints, you might want to look at that. That’s going to be problematic. If you really don’t think it’s going to fit into a sprint, it absolutely has to be broken down.
Jesse: The same team I was talking about before, we have a rule that’s sort of loosely applied that no stories come into the sprint that are greater than five points. Preferably, three is our maximum. That’s worked really well for us. The product owners understand why, and the team.
We’re a relatively small team. We worked out that a five is approximately one person for pretty three quarters of the sprint. If there was any variation in the story, if it was slightly bigger than a five, then we got into massive trouble and had no hope of finishing the sprint.
Often, larger stories, there is more uncertainty with them just because of the size of the work. You are more likely to have that underestimation, so we try and break those down wherever possible.
Gavin: People do find it very difficult to break down user stories. There’s many different ways to do it, whatever makes sense to you. Sometimes you look at the acceptance criteria, and they can be broken out as separate stories. Sometimes certain agiles might have workflow steps that you can break stories down into.
Sometimes there are business rules surrounding those things that can help you break them down. There’s quite a few different ways. There’s actually a very good article about breaking down user stories with a flowchart attached, which we’ll add the link to the bottom of live stream for you. It’s pretty useful.
That’s the user stories, but, recently, you’ve come across a different concept of stories, which is moving away from user stories a little bit. We haven’t actually put it into practice ourselves. For us, it’s just a concept. We thought it was worth discussing.
Jesse: Sharing. As we’ve said before, lots of people do struggle with user stories. Sometimes it’s not the only way to break things down. I came across an article by Alan Klement on Medium. We’ll post the link on live stream after this. He was talking about a new concept, job stories, and covered that out quite succinctly in his article.
The assertion with job stories is that user stories make too many assumptions. You have a persona, so the [inaudible 18:56] , which, again, unless you’ve done lots and lots of market research, is probably your best guess at what your users are like.
Gavin: Absolutely.
Jesse: There’s an assumption there, and then the “I want a…” is another assumption. What he says is those two assumptions leave way too much ambiguity in actually delivering value to our users.
Job stories take a slightly different approach and focus on events. When something happens, I want something else, and that captures your motivation, why are you building the feature, and then so that I can get an expected outcome.
Gavin: It’s similar to user stories in a way. It still has that template. It’s just that, rather than as a user, “I want to, so I can,” it’s, “When I want to, so I can.”
Jesse: Yeah.
Gavin: What about that removes the ambiguity? Why does a contextual situation remove ambiguity that a persona may cause?
Jesse: I suppose by using an event you know that these events happen within your system. For example, when a user forgets their password, they want to so that they can get an outcome, you know that this is happening. You’re not making an assumption about who that person is or what the background to that person is.
I think it could be a lot easier for people to write those stories, because you’re talking about events. For product owners it could be a useful tool.
Gavin: Interesting. My only concern about that would be that you are getting away from thinking about the benefit to the users. You’re thinking about situations, which is obviously easier to do. If you had a wish list of features, you could quite easily think up situations of those and then the outcomes of those situations. But if you had a wish list, you’ll have to think about users and the benefits to those specific users. That’s a lot more difficult, but possibly more valuable.
Jesse: Yeah, absolutely. It’s actually really interesting. In the article, Alan says personas provide too much ambiguity, but in a lot of the examples he uses persona-like wording, when a customer does something or when a seller does something else. You definitely can still include personas in there.
Gavin: He does mention that these have to come out of interviews with people. You can’t really come up with a job story without actually interviewing people about some of these situations, which is interesting because you could interview people for user stories. But I do like the idea about interviewing people and getting real contextual situations out of that. I think that’s quite useful.
I do see how job stories might be better used or of more use for a team that’s in a purely infrastructure space than actually creating software for end users, and might be better for that sort of situation. Because you do see some stuff shoehorned into user stories when it seems a little bit crazy. Like, why are we sticking to this template? It doesn’t really seem relevant to this situation.
Jesse: Yeah. Again, infrastructure would be a great use of job stories. When server one dies, I want to know that the rest of our website won’t go down so that we can maintain a reliable service. Taking out that persona in that situation would be really useful. I suppose maybe what I might look to try to start with is writing job stories for infrastructure type work and keeping the persona and user stories for user-focused work, could be one way to…
Gavin: Yeah. Just to refer back to my pub conversation a while back, that person who was talking about user stories had really started writing job stories without really calling them job stories. They were saying that these were user stories, and that stoked my ire a little bit, because it wasn’t.
Jesse: [laughs] Yeah.
Gavin: It was a story. It’s just people throwing around terms willy-nilly a little bit. But they had naturally fallen into writing job stories and it seemed to be working for them. User stories are there to help people create value with each bit of work that they do. That’s something that you really have to keep in mind every time you’re working on a piece of functionality, a feature, or whatever it is you’re working on.
If you can keep that in mind when you’re writing job stories, that you’re still trying to create some actual business value or user value there, then it’s OK. My only concern would be that people write job stories because they’re easier and they don’t have to think so much about the value. It’s just too easy to manipulate them into your wish list, basically.
Jesse: Yeah, absolutely. As with anything, give something like this a go, but, again, if you’re working in the scrum environment, remember that the goal of your sprint is to produce a potentially shippable product at the end of it. If job stories help you do that, then great. If they don’t, then user stories might be what works for you.
The one great thing about user stories is it does force you to take that slice, that thin slice of product that you’re trying to deliver, whereas like you say you could just build really disparate features using job stories.
Gavin: Yeah, you could apply, say if you’re working in a waterfall way, you could apply job stories to it really quite easily and nobody would know the difference. [inaudible 25:23] .
Jesse: Yeah, I suppose they are in quite a use-case template. Yeah, absolutely.
Gavin: Cool. I think the job story idea is really interesting, and I know we’re probably going to try them out here. It’ll be really interesting to see how that goes, and we’ll let you guys know how that goes, too. If it’s a huge success or a massive, massive failure, we will let you know.
Jesse: [laughs] Or somewhere in the middle.
Gavin: Or somewhere in the middle, yeah. That’s us for this episode. See you in two weeks’ time. Thanks very much for watching.
Jesse: Cheers.
