This is a transcript of episode 126 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
We respond to an article on user stories that has some good points (user stories are prompts for conversations) and, in our view, misses the mark on others (claiming that tasks are better than user stories for technical work). This leads us to propose “human stories” which may not involve traditional users but do involve humans who are affected by the software we’re building in some way (partners, investors, regulators, and more). Finally, we apply these ideas to answer a question from a listener on handling complex technical changes with user stories.
Show links:
Rant on non-functional requirements
Agile Manifesto episode on face-to-face interaction
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile! Hi there, Jeffrey.
Jeffrey: Hi Squirrel.
Squirrel: So this week we’re responding to a listener, and we really like when we can do that, especially when we can do it quickly. And in this case, a listener named Simon–who’s gotten in touch before, we like to hear from folks who are regular listeners–says that he has a puzzle! He referred us to an article which we found really, really interesting. And the article is by Darren Peterson. I hope I’ve got the name right. Yeah. Darren Peterson from Lullabot. You’ll find the link in the show notes. And the article is all about why Not Everything is a User Story. And Simon asks, ‘hey, have you done anything on this before?’ We’ve kind of touched on it. We’ll include at least one link to a rant I had about non-functional requirements, that might be interesting, but also was interested in our reaction to the story and a particular angle that he had on on what’s in the article. So Jeffrey, we’ve now read the article. We have some interesting reactions, I think. What were your thoughts?
Jeffrey: Well, first of all, thanks again, Simon, for sending this in. Because I did really appreciate it. And this came at a very good time for me because user stories have been a big part of my life in this past week. So this aligned very well the energy of what I was ready to talk about. And there is a lot in the article actually that I agreed with. And there’s some parts where we didn’t. Now, the title of the article was Not Everything is a User Story, and it lays out the distinction between what they’re calling, you know, actual user-based stories, and then something else that they were saying are not user stories, but that people often make the mistake of trying to force and shoehorn into a user story. And that led to a really interesting insight that you brought up Squirrel, about what it means–the feedback from the tool you’re using. Just so that we’re ever on the same page, let’s describe what we mean by the typical user story format. And I think this is somethnig that people might be used to. There’s a lot of references we could give, the good news is it’s right there in the article. So I don’t think we need to give a separate reference too. But the standard format is ‘As a’ and it says a type of user. And often I would use persona here because we use personas in our approach. So as a given persona, ‘I want to do’ this action ‘so that I can’ get some benefit.
Squirrel: So let me give a good and possibly twisted example. Here’s how to have examples. So as a–and actually we can use the one from the article if I can find it–yeah. Here it goes. As an amateur chef, I want to make delicious recipes so that my friends are impressed with my recipe making something like that. That’s not a beautiful one, but goes through the the steps or I want to look up great recipes that use potatoes because I have a lot of potatoes, something like that. Yeah. And a not so good one would sound something like this. And this is real. This is not a made up one for those who might not believe it. I have actually heard things like this. As a database! I want to store information about the user’s names so that I can tell the user what her name is. I can display the user’s name, something like that.
Jeffrey: Yes.
Squirrel: And something has gone badly wrong.
Jeffrey: Yes, I really–that’s a great example. I’ve certainly come across these and people often describe these as sort of, ‘well, these are technical user stories.’ And there’s an example from the article: in theirs they say ‘as the system, I want to verify a user’s OAuth credentials before granting access so that I can ensure secure connections.’
Squirrel: But the problem is, I’ve never met a system. I’ve worked on systems before, but none has ever come up to me and said, ‘hey, Squirrel, there’s some things I want to do. Can you help me?’ That system has never done. I don’t think we have generalised AI yet that can accomplish that.
Jeffrey: And I think this is kind of the first point of insight that you and I had in looking at this, which was: the tool when you use it is giving you feedback, and when you find yourself doing something strange and unnatural like that, what I often hear people say is, ‘yeah, this is a problem with the user stories. User stories are dumb’ because they believe they mean that we end up writing these these sort of unnatural stories.
User Stories vs Tasks
Listen to this section at 04:40
Squirrel: And that’s not the position of Darren in the article! So Darren Peterson says, ‘hey, user stories are good, but you shouldn’t use them in these cases where you have to do funny stuff.’ And I think that’s where we disagree.
Jeffrey: Yeah. It’s interesting, you know, there’s a part of it even on the path where I think we may agree because he makes a distinction between tasks and stories.
Squirrel: Mm hmm.
Jeffrey: And I would often say in structuring the work around a story, I might come up with various tasks that I kept in my head, my plan for how to implement the story could be expressed as tasks, and he talks about tasks as ‘simple, imperative statements that declare what must be done’.
Squirrel: And that seems useful to me! That those are usually children of stories for me there, if it’s in some system or written on a card. It’s like a bullet point list of stuff I’m going to do in order to accomplish the story.
Jeffrey: I agree. And so let’s take his example where he’s taking that user’s OAuth example and he said require a valid OAuth token for access to the system. Now, here’s the point: he’s now not going for that hierarchical ‘this task is a different from a story.’ He’s saying we should just get rid of that, and he gives explanation. He says ‘the imperative authority to do the work’ in this case, ‘comes from the organisation’s need to provide security or earn revenue.’ He has another example around advertising.
Squirrel: I’ve got a problem there because I’ve never met an organisation. I’ve met people. People come up to me and they say, ‘Squirrel, I have this problem, or I want to do this thing and isn’t this great?’ Organisations never do that.
Jeffrey: Yes. And this is the funny thing there, because we agree with what he says about the value of user stories. I think he makes a very good point and one that’s similar to what we’ve talked about in the past, because part of what Simon says was, have we ever covered user stories before? And we did in a couple of ways. We covered it a bit in an article where you had a bit of a rant about non function requirements, and we also covered it when we were doing our Agile Manifesto series in Principle six. And there we talked about how a story card is a promise for a conversation, quoting Alistair Cockburn. And we’ll put links to these in the show notes. And this fits very well with what Darren described as the strength of user stories. He says ‘the conversation around actual user-based stories builds understanding between the business and our development team, and it sets us on the right path. It just needs to recognise that the user story format itself isn’t magic.’ And he’s right. It’s not the format. And this is where I think people go wrong when they try to shoehorn things unnaturally into the format. But there is magic in this, and it’s the conversation part! And what I think we don’t like so much about his proposed solution, which is to go directly to the task, is that he he seems to be dropping that conversational element.
Squirrel: And there are interesting humans who are benefitters of the system, and you could make a semantic argument about whether they’re users. But for example, in the OAuth example, it could be that there’s someone who has to ensure that there’s auditable requirements. You know, that you’re not showing personal data of the amateur chef to somebody else. And so that in Europe, we have GDPR and there are similar rules around the world. So it could be that that person is actually the person with whom you want to have a conversation, because that’s the person within the organisation who is saying, ‘hey, we have to have a log-in here. We can’t just let people see each other’s recipes because you might see my recipe for lemon meringue pie, and I sue the recipe site becuase you saw my secret recipe. You weren’t supposed to do that.’ And I’d like to understand that when I’m building that story! He has another example, which is a very good one and a typical one which I’ve seen many times. ‘As a user I want to see advertisements so that I can see things that might interest me.’ Of course not. Users don’t want that. But there’s somebody who does. In that case, it’s probably the advertiser. And so it’d be really useful if I’m going to show some advertisements to talk to the advertiser. That person might have some needs and wants and wishes, which may be in conflict with those of the users of the site, the people who are logging in and making the recipes. But understanding those conflicts would be really useful and making sure that you make clear trade-offs about them. If you simply make a task which says show adverts, you’re going to miss all that conversation.
Jeffrey: You know, the funny thing for me, and I’m going to stick with this example because, I think this supports for me the idea of the value of a conversation, he makes the insight he says, ‘take our example from above. Maybe traditional Web advertising is a substandard way of generating revenue for your business. But you’ll never have that conversation if you paint over it with false user requirements and benefits statements.’ And I totally agree. But I don’t see how tasks help this.
Squirrel: That doesn’t trigger a conversation either.
Jeffrey: Exactly. So I think part of what we’re saying I would rephrase this way. ‘User stories are good because you have a story about the conversation.’ And there’s a lot of reasons why stories are valuable. Stories in my mind–I’ve often told people that stories are the unit of idea transmission. This is how human psychology works. We understand why, we understand things in the context of stories. And so making a story of what you’re doing helps people have a shared understanding of what you’re doing and why you’re doing it. And we want to have that why conversation. And to me, I put that together with what you described, which is that there is some human. All work matters to some human. So in these cases, for these user stories without value to the user, what Darren’s calling technical tasks. What we’re saying is there are users it matters to. And we can have stories for those humans. Maybe we have to call them human stories sometimes instead of user stories.
Squirrel: We can have this debate about whether the compliance person who is in charge of the log-ins. Is that a user? I claim that person is, that person is an indirect user in the sense that that person can get the angry phone call from the person with a lemon meringue pie. If that’s what’s going to happen. So that person’s a user, at least indirectly, of the system, by having a result of the system matter to him or her. But you want somebody to whom you could be accountable. And I’m not claiming that in every case, you have to be accountable to that person, that you have to be checking every second, that you have to have the conversation every five minutes to verify every single requirement, every single thing that you’re going to be working on. But when I’m doing any kind of work and this includes by the way, things that some developers, I think they incorrectly use this word for it: refactoring. Refactoring really is something you do in about 60 seconds as part of your writing of code. It’s not a thing that takes two weeks to change the entire authentication module. But when people are doing that kind of work, their users, their interested humans, may be other developers. ‘Hey, I’m gonna make this code more maintainable so all of us stop wanting to poke our eyes out with a rusty fork every time we look at it.’ And then I can be accountable, and it could be I’m just accountable to myself that I look at and say, ‘yeah, this is better.’ Could be. And especially if I’m going to invest two weeks in it, I might want to show it to some other developers. And if they say it’s worse, then at least I found out before I released it. And I’m accountable in that way for what I’ve built. I have found a human who’s going to benefit from what I’m doing, and that human has verified it’s either worthwhile or not.
Jeffrey: To kind of sum up, maybe, at least my reaction, and I think you can tell me where yours is a bit different: I really enjoyed Darren’s article. I think he made some good points. But he also hit some things where I would part ways. I do like the idea of tasks. But for me, the tasks should be rooted within a story, and in a sense that there’s always a story for what we’re doing, and I find it is helpful to identify it. And I think having the story makes it more likely that we find alternatives. To use his example, we’re more likely to have a conversation, in my mind, that maybe traditional Web advertising is not a good way to do it for our business, if we have identified the person to whom we would be having the conversation with about putting in Google advertising. So I think that’s our summary for that. User stories are good. Conversations are good. If you find you’re writing awkward stories, it’s not a ‘follow the tool.’ Think about what you’re doing and figure out how can I write what I’m doing in terms of a conversation with some human. And I think that will help you set on the right path.
The Answer for Simon
Listen to this section at 13:14
Squirrel: Indeed. But we should come back to Simon’s original question, because he put something else in his e-mail, which I thought was interesting. And he said, ‘what I find that I can relate to in the article is sometimes the user story alone doesn’t convey enough of the how, especially when for reasons of cost or non-functional requirements you are swapping out some piece of the tech, but not dramatically changing the story. It’s not clear to me in these situations what would be the Agile practitioner’s artefact of choice?’ Well, I don’t know about all Agile practitioners, but I think we can apply what we just talked about and determine what our artefact is. I predict it’s gonna be a story and a conversation.
Jeffrey: Yeah. A human story. And remember, the story cards are a promise for a conversation, so we could write that story and then we can have a conversation about why we’re doing it and what benefits we get. And, you know, ‘how do we feel about this choice?’ And what we want to have is that conversation.
Squirrel: Mm hmm. I have a perfect examples of this kind of thing where I was doing due diligence recently for a company whose AWS bills were sky-high and they knew it. So they were clear about it as we were doing the checks and the audit and so on. And they said, ‘yep, we know this is too high and here’s our detailed plan for addressing it.’ Now, they didn’t put it in terms of user stories. I think they would have benefited from doing so. And those stories might read something like, as an investor, I want my money to be used effectively and not wasted on servers that we don’t need, so that we can invest it in expanding the business. And then you would want to go find the investor in this case, my client, the person for whom I was doing the due diligence and say, ‘yeah, how much do we have to reduce it by? And what are you going to spend the money on and what benefits does this have’ so that you know whether to cut by 10 percent or 30 percent or stop using AWS altogether.
Jeffrey: I do really like that article because it does identify some of the things that I’ve seen happen amongst development teams where they’re going to make a change that for them, it’s obvious why they should do it. And a good example as you said, we’re going to do something that we know is a good thing. We’re going to reduce our costs. And that has to be good.
Squirrel: But the problem is, it’s not always good. In this case, it is. So I have another client who spent many, many months trying to reduce their AWS bill, and it was already de minimus. It was already unimportant. There was a huge other benefit that they could have been spending time on, but they were spending huge amount of effort trying to, in part, to reduce their their hosting bill. Their hosting bill was tiny, didn’t matter.
Jeffrey: Right. I’ve also come across examples where there’s a business opportunity that dwarfs the costs that you’re trying to save. So you have this opportunity cost. And, yes, it’s, you know, all things being considered. You know, all else being equal, then lower costs might be better. But very often all the things are not equal. There’s other choices. There’s a trade off you’re making. And for me, these conversations are about identifying the trade-offs and saying, do we all value the trade offs the same way? And at least, can we get to to a clear understanding of what trade-offs we are making?
Squirrel: That sounds great. So our summary of our answer to Simon is, ‘yes, our artefact of choice is a user story in the format that we talked about, but maybe with a slightly different user or a different definition of user, namely an interested human.’
Jeffrey: All right. Thank you very much Simon for sending that in.
Squirrel: Absolutely. Yeah. And if other listeners would like to get their questions answered, you can do that in lots of different ways. For example, you can write to us. You can come to us on Twitter. You can go to ConversationalTransformation.com and you’ll find lots of different bits about us. I do office hours pretty regularly. Jeffrey has the London Organisational Meetup, so there’s lots of places to find us, and Conversationaltransformation.com is probably the best place to start in getting in touch with us. We sure like to hear from you. And of course, we always like it when people hit the subscribe button because that means we’ll be coming back for the next hundred and thirty episodes, whatever we’re up to these days. And we’ll be showing up in your inbox every Wednesday. So we’d like to continue doing that.
Squirrel: Okay. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.