Don't Write User Stories, Tell Stories

User stories are narrative stories describing the goals that users and customers have. They are a way for teams to describe what they want to build in agile software development. But in the teams I see using stories, they’ve become more of a commodity of Agile. Stories are objects that get written, passed around, estimated and developed.

The part that’s gone is what I believe to be the core of user stories, and what’s left is only a dead shell.

I think shifting the focus from writing stories to telling stories is a subtle change in perspective we can encourage that could lead to meaningful changes in team behaviours and outcomes.

What Goes Wrong With Writing User Stories

Collaboration Suffers

I was leading a workshop recently where participants imagined a new feature to add to their existing product. The discussions were active, with lots of participation from everyone involved. But things stalled once participants were asked to write down their new features in user stories.

Suddenly, the discussions ended, and the group stopped talking or even paying attention to each other. Instead, they all focused on the whiteboard, trying to create the “correct” user story.

I watched them struggle like this for a few minutes until I told them to ignore the whiteboard. I said to them, “Pretend that whiteboard isn’t there. Look at this person and tell him what you want to have happen.” Which instantly got them talking to one another and asking questions again.

Learning to do something new is always challenging, but what’s the point of teaching about user stories if we’re training them out of communicating and collaborating?

Stories Become a Commodity

Teams treat stories as something an individual writes that gets passed around to the team, approved, estimated, and then passed to others to develop and test.

When people treat stories like a commodity, like a physical object, people start coming up with weird rules about who’s supposed to write them, who’s allowed to approve them, how they should be estimated, and so on.

This commodity perspective rewards a volume. Writing more stories means more work, which means people are busy! If you tell people to write user stories, they’ll go off on their own and write stories for days.

In the worst case, collaboration is stripped from the process entirely, and the team’s behaviours become very transactional. In this way of working, when communication and collaboration are absent, teams don’t benefit from the group’s feedback, insights and knowledge.

People Fill In the Blanks

I’ve been told that having a user story template and a clear format makes learning how to use user stories easier. It makes sense that having a template reduces the cognitive load for people as they get started, but I don’t think that’s actually desirable.

Making it easier for people to write their story means the story will get written, regardless of whether the story’s any good. If the only goal is to fill out the three magic prompts of “As a… I want to… So that…” there’s less need to carefully think about the actual story they’re trying to tell.

Tell User Stories

My recent thinking on user stories is to focus on telling stories about what we want to build for our users rather than writing them as documents or tickets. When I teach this to people, I emphasize that I’m talking about real stories that have nothing to do with cards, Jira tickets or software.

If we think about user stories as stories we tell to one another, the guidance on creating better user stories becomes even more helpful because it starts guiding our behaviour rather than helping us create a particular artifact.

One example of this is to apply the INVEST principles to the way we tell user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These are criteria that help us create well-formed user stories. INVEST becomes more helpful if we forget about trying to write stories and instead focus on telling stories that meet these criteria.

• Independent: The stories you tell should be complete, whole stories.
• Negotiable: The stories you tell should focus on the user, not the systems.
• Valuable: The stories you tell should help the user in some way.
• Estimable: The stories you tell should be coherent and possible to estimate.
• Small: The stories you tell should be short or micro-stories.
• Testable: The stories you tell should lead to questions and discussion.

Tell Bigger Stories With User Story Maps

We can also apply the idea of telling stories to user story maps. Instead of using story maps to organize project requirements into tickets before they get entered into Jira, if we focus on telling stories, the purpose of user story maps becomes to help us tell bigger stories.

So the story map is primarily a tool for storytelling, not a warm-up for Jira.

When the teams I work with start projects, creating a user story map is sometimes treated as one of their first project milestones. Their story maps are treated like any other project deliverable or artifact.

When the goal is to “Finish the story map,” it’s easy for people to create a large inventory of dozens or hundreds of stories. Having a large, excess inventory of stories is waste in the lean sense and a sign of waterfall thinking.

A team focused on creating an inventory of stories will likely have one person build their story map in isolation from the rest of the team because collaboration is a slower process. It’s easier to increase utilization by having team members separately—another sign of waterfall thinking.

A team focused on telling stories should be building their user story map together, and their map should focus on users, what users are trying to accomplish, and how users will interact with systems to achieve those goals.

Delay Adding Details Until Later

Adding tickets to Jira is sometimes the first sign for managers that their teams are progressing on a project. But adding detailed stories to Jira too early in the development process has the effect of locking people into their first, worst ideas.

Instead, a better approach with more significant projects is to take advantage of the discovery phase and focus more on learning and shared understanding, not rush to start development. Before people begin touching code, encourage them to spend more time exploring together.

Modelling systems and user flows using techniques like the C4 Model, EventStorming, or Domain Storytelling can benefit teams by encouraging more collaborative discussions about software systems and use cases to create shared understanding. When it comes to the details of a story, Example Mapping is a collaborative way for teams to discuss rules and system behaviours.

But, just like the example of the workshop where trying to write a user story caused people to freeze and stop talking with one another, the most important thing when using these modelling techniques is collaborative learning, not “finishing” a model.

Conclusion

Instead of helping teams focus on users’ needs and encouraging more interaction between teams and customers, user stories can sometimes become a process and a source of waste in agile teams.

Although user stories are easy to count and measure, having teams write mountains of requirements in user stories and pass them between themselves has nothing to do with their goals of focusing on user needs and collaboration.

When the understanding in the team is high, when more people have the opportunity to ask questions and contribute their expertise, the work quality will improve.

Shifting the focus to telling stories instead of writing them is a simple step teams can take to improve their outcomes.