What Are User Stories and How Not to Write Them

Not that long ago, I was conducting an Agile Bootcamp and one of the attendees piped up when she saw that user stories were on the agenda.   

“Finally,” she said. “That’s why I’m here.”  

I’m sure my initial answer didn’t provide her much comfort. What I said was, “If you think that there’s one way to write a user story, you’re missing the whole point.”  

Of course, by the end of that particular course, this woman (and all the people who went through it with her) understood exactly what I meant. That doesn’t mean that what I presented was the be-all-and-end-all about “how” to write a user story.   

User stories shouldn’t become an exercise in documentation. They are a process that brings about productive and healthy discussions.   

This isn’t the first time that I’ve written about what it is that people do and don’t understand about user stories. It’s often easier to frame the conversation about user stories by first discussing what they’re not. (That may not be the last time that I take some liberties with grammar just to get my point across.) 

User Stories ≠ Software System Requirements 

When I talk about user stories, I discuss format last because the minute the discussion starts there, we’re already way off track. Instead, the best place to start the discussion about user stories is ultimately how they should be used, and not how they’re written.  

In truth, there’s no one way of doing it. I’ve walked into plenty of rooms where the white board is exploding with Post-it Notes, and each Post-it has a relationship to a requirement, and the entire board is somehow tied to a bulky and demanding deliverable schedule.   

No.   

You’re not trying to map a use case to a user story. User stories are not an extension of a requirements doc, but they are a gentler, and kinder, way to build features. (Yes, there’s a difference.)  

User stories should be lightweight, and they inevitably seem to become heavyweights attached to long-term planning…which defies the purpose of them entirely. They are less functional and more inspirational (I’ll get to that in a second). I understand that the haziness around user stories typically comes from the idea of solutions and permanence.   

The very idea of deliverables is rooted in expectations and deadlines. It makes sense that everything, then, gets tied to the ultimate goal, when what user stories are meant to do is start (or form the basis of) a conversation.  

Another way to say it: User stories aren’t the map, but they’re more like the rest stops. No one makes a long trip in a single drive. Even if you had a magical fuel tank that never needed refilling, you make stops. Most of us actually prefer to break up long trips into shorter jaunts because it’s just easier to manage, right? Here’s where that inspiration comes in.   

You’re using user stories as the opportunities to discuss where you should be going rather than another component of what can easily become a ruthless and stuck process. Forget the outcome for a minute. And start reimagining the journey. 

User Stories = Conversation Starters 

User stories work only when they create discussions for both clients and the very people who are working with them. You’re building software and products feature by feature, remember? User stories are one way of breaking down those smaller features into even smaller and smaller discussions.   

If I had to nail down this whole process with one word, it’s facilitation.   

So, what should user stories facilitate?   

• Small, manageable increments 
• Flexibility and malleability, providing more opportunities for the client to change their mind (requirements put the burden on the customer to be right from Day 1) 
• Clearer separations of how to leverage the feedback from the customer and the skills of the technical team  
• More opportunities for the customer to change their mind  
• Discussion amongst the development team as they complete work  
• Focus on the client and not a longer and longer to-do list 
• Celebrating small wins: Using our rest stop analogy, how critical is it to stop and take in the view? 
• Improved collaboration 

Where Do the Pitfalls Happen? 

They start at the beginning with the actual existence of the requirements document itself. If that’s the starting point, then you’re not only missing the point of a user story, you’re missing the point of agile.   

The whole idea of managing complexity is to take away the elements that are the most hindering and frustrating. This is always going to be a dynamic and unfixed process because solutions aren’t—and shouldn’t be—fixed.   

Tasks, though, tend to feel fixed…and that’s precisely why a user story isn’t a task.  

The goal of a user story is to contextualize and visualize functionality from the perspective of the person that’s going to be using it, instead of assigning a piece of work to a member of the team.   

If you write your user stories on the back of matchbooks or napkins, that’s a better alternative than writing tasks on a white board. Remember what you’re doing: You’re centering users in the conversation. User stories aren’t so much a “what.” They’re in the truest sense a “why.” 

Formatting Your User Stories: Start with the Why and the What 

We’re keeping it simple, so without getting too attached to how they “should” look, here’s a general idea.  

• Who is this for?  
• What are they trying to do? 
• Why are they doing it? 

I can’t reiterate this enough, that user stories are not user requirements. If you use them as a spec for an interface or a specific part of the software, then you’re still circling around what they are and how they work. And what they should do is create a structural landmark for a stop-and-chat about the real-world implications for users and products.  

User Stories = A Discussion Framework 

The user has an immediate desire to do something to derive an immediate benefit. Discuss. It really is that simple—but keeping it simple seems to be the biggest challenge for many of the teams we work with when we first meet them.  

The best way to know if you’re implementing user stories in a holistic and productive way (instead of just a 3-D to-do list) is by the results that you see. So, are you getting a better handle on:  

• What is the next and most urgent or pressing project? 
• Who needs it, how do you define the need, and how will they use it? 
• How can those be broken down into smaller steps? 
• How to better define the process of what your team does when and how your team can get to work

The more readily those issues are being addressed, the more you know that the process, however it is that you’ve implemented it, is working.   

Getting there does take work, time, energy, and confidence. That’s what we’re here to provide. Contact us today to discuss how we can make you and your team more productive and harmonious and serve your clients better.