This is a transcript of episode 143 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Squirrel is gobsmacked by user stories that appear to be about aliens, who want “intuitive interfaces” and “modern technology”, where customers from Earth want “fun with my kids” or “relief from boredom”. Jeffrey reminds us that such stories can lead to conversations that tease out the emotions and the human stories behind the words. Both agree that once we revise our stories to create empathy, we also allow the team to discover amazing new ways to solve problems.
Show links:
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 I’ve discovered customers from Pluto, and I’m really upset about them.
Jeffrey: Really? That sounds anti-Plutonian. What do you have against customers from Pluto?
Squirrel: Well, none of the people that my customers and my clients serve are on Pluto. So I think they should go to consultants on Pluto, and we should make sure we don’t write user stories that are designed for customers from Pluto.
Jeffrey: So Pluto is outside of the target market you’re working with?
Squirrel: Unfortunately, shipping costs are too high.
Jeffrey: What do you mean by customers from Pluto? Who are these people and how did you come across them?
Squirrel: Well, let me give you a user story I encountered this week: ‘as a user, when accessing my service, I want to be shown an intuitive environment that clearly houses all the information I need.’ I have never met a customer who talks that way, and it doesn’t capture how people feel and what they actually want from their service. It’s getting dangerously close to ‘as a database I want to constrain and normalise my data.’
Jeffrey: We did talk about that problem with user stories back in July. The same way people might have technical tasks they want to do, and they make it OK to do them with ‘technical user stories,’ here it sounds like they have solution in mind and they’ve invented these customers from Pluto who want that thing. Is that what’s happening?
Squirrel: It’s hard to tell in this case. Alistair Cockburn said ‘a user story… is an invitation to a conversation.’ It’s a promise to have a conversation. This one certainly invites a conversation, but the problem is that I can’t tell where to start that conversation because I don’t know what problem this is solving. In this case, the author of the story is in a feature factory environment where there’s a list of things that someone hands to this product manager. And the product manager goes and writes a story for each item in the list. So there is retrofitting. But when I had a conversation with this person, I found out she really had somebody in mind when she wrote this story: herself. Once we managed to talk about who she was–a busy mother–and what problems she had, that was really helpful. Busy mothers are from Earth, I understand them. This week I got her to talk about the emotions that went into this. And she said, ‘well, I’m frazzled, I’m nervous that maybe what I want to do won’t work. I’m going to be really happy and I’m going to have a sense of ease if I can go in and update what I need to.’ And I could immediately empathise, I knew what she was talking about. I have had experiences where I was frazzled and upset and embarrassed that something hadn’t worked. And I’ve had experiences where something was easy and simple. And I had joy in the experience of updating something because it was so simple. So that was really helpful to get to that and have the conversation.
Jeffrey: It can be dangerously easy for people to skip the conversation. They take the cards and put them in user story but don’t use them as user stories: they don’t try to develop empathy. Someone reads the card and says ‘I see you want all the information together in an intuitive user interface. I’ll just go do that. We don’t need to have the conversation.’
Emotive User Stories
Listen to this section at 06:32
Squirrel: In fact, somebody outside this person’s team had gone through their backlog and said, ‘I don’t understand why we’re wasting our money on any of this stuff.’ If this person had read ‘a busy, frazzled mother wants to update her car registration,’ they would have said said, ‘hallelujah, why haven’t we built that already? Why haven’t we made that simple and easy for that person to update their car reg?’
Jeffrey: Getting that story is going to generate different reactions in different teams. Maybe you have a team where where people say, ‘look, I don’t know, let’s have a conversation.’ And they have that conversation and go, ‘OK, I get it now.’ When the team is functioning well, this kind of shorthand in the user stories might be benign. The problem is you may not have those dynamics and the story format is supposed to help encourage those conversations. We could have given a little bit more depth to that user. When we were first hearing about this, I thought, ‘this is why we use personas.’ You could say, ‘here we have Nick, our harried, frazzled, nervous user. When Nick goes to use the site, he’s nervous about what’s going to happen. Therefore, we need a calming, reassuring interface for him.’ One of the reasons for personas is to carry some of that emotional context so that you can identify that story with some human needs. You could have simply said ‘as a nervous user.’ The key element here is the emotional context.
Squirrel: With this group of product managers they could identify actual people. They don’t have personas, because they’re in the lucky circumstance where they’re selling to people who are like themselves. So this particular person could say, ‘I’m a busy mother and I would really like to update my car registration.’ Some of us work in situations where our customers are very distant from us, maybe not Pluto, but they are people who it’s harder for us to identify with. Personas are useful in both cases because there’s always some differences and it’s useful to have common language. But for these people I could say, ‘all right, so instead of saying as a user, it has to be a real person.’ I have to be able to go and find them and say, ‘hey, you do you want to display an intuitive environment that houses information or do you want to update your car registration?’ And that helps to create empathy.
Jeffrey: Ensuring there is at least one human that wants that is an excellent start. There is a danger to using people in the office as users: part of what happened in creating that story was the person who wrote it almost certainly felt it was completely clear and completely intuitive. But, that’s because they weren’t reading the text on the card. When people are speaking, they don’t actually hear the words they say, they are instead focused on their own intent. The words are a partial expression of that. This is one of the challenges in writing any sort of document: we are reading our own words with the context in our head. We read our intent along with the words on the page, and that can lead to problems where a team is designing for real people, but not the people who they’re hoping to sell to.
Squirrel: That’s exactly how this person was thinking. She said, ‘it’s obvious, I know all kinds of people like this.’ I said, ‘can you name one?’ She said, ‘well, me’. She clearly was thinking, ‘I have this problem. Everybody must know about this problem. These words must encode that problem.’ That didn’t quite work. But not only does a good user story conversation unlock understanding for the developer, others within the team, and those outside to all agree ‘yes, I understand why you’re building that.’ But also, it opens you up to new and different solutions. As we talked about this problem, once we understood it was about updating car registration and understanding the emotions of nervousness or relief, we thought of different solutions: there could be some kind of feed that could tell you that people have bought a new car, or what if she got a text message that said, ‘we noticed you bought a new car! Click here to update. Have you kept your old car? You want to have two?’ If she got that, then she could do that without even logging on to the application, without doing anything.
Jeffrey: That’s fantastic because it does show the point of the user stories is to have the conversation. You run into problems when you assume that you already know the answer when you’re just using them as stand-ins for tasks. ‘I’m going to write this user story not as a placeholder for a conversation, but really just to say to do that thing that we were told to do.’ You’re not really engaging the brain and being creative. When we say, ‘we don’t customers from Pluto,’ we don’t want to be limited to the voices around the table. We need customers that are a middle distance away–they’re outside of the building, but they’re still on the planet. When you start talking about not the feature you’re going to implement, but what that person needed, then you became creative. That’s a much more creative, interesting space than a task list checklist.
Testing Your User Stories
Listen to this section at 15:01
Squirrel: There are a couple of tests that you can apply to your user stories. First of all, are there any humans who think this way? You could read it to some random humans who aren’t in the building and see if any of them recognise the language and empathise with the problem. Then you can check to see if it leads to some creative thoughts? Is there only one solution that could possibly fit for your user story, or are there many?
Jeffrey: A crucial piece of that first test is more specifically ‘would anyone talk this way?’ If it sounds like normal human language, that’s a really good first step towards building empathy. This also goes back to the idea of the feature factory problem: the developer’s alienation from their work, they don’t feel connected to what people are doing. ‘Are we having exciting conversations about humans, what they need and what they want?’ If not, then you’re probably falling a bit short.
Squirrel: There we go. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.