Stop Writing User Stories. Start Writing Issues

The modern product team has outgrown the traditional agile ways of working. A common way to break down a project has been to create user stories.

I experience that user stories have turned into an anti-pattern in software development. They used to serve a purpose back when users had to communicate their needs into product requirements that a tech team could build and deliver. An information-gathering process covered multiple points of handover.

I used to write long user stories back in the day, around ten years ago. Trying to translate a customer request into a well-written and technically understandable context so our developers and designers could quickly implement it. I was new to product development, and it sounded and felt like a great idea to try to understand the user. But what was usually missing (besides the direct customer dialogue) was a well-written issue that explained what to do. We often found ourselves reading a business rep's notes from a customer dialogue they had. Then we wrote them down in a predefined format (word doc), which was later handed over to a developer as a requirement. A three-step information shipping activity ended up in a user story in Jira and some tasks that the developer herself could have easily written down.

User stories are obsolete.

You don't have to write user stories to keep your focus on the user.

A few of the benefits that traditional agile project management teams use as a reason to keep creating user stories in an organized hierarchical structure are:

1. "Stories keep the focus on the user." Imagining that a collection of user stories is the only way to capture real users' problems is a fantasy. If you have your users or representatives for your users in the team, you can just talk with them. Discuss what the problems are and prioritize which problem to solve first. There will always be new problems, and believing you can capture all of them in a nicely organized overview is a fantasy.

2. "Stories enable collaboration." Well, yes, but collaboration happens in a team with extreme ownership. If you have a clear goal for your next cycle or iteration, your team will find ways to solve them by taking ownership and prioritizing the next best step. Discussing broader product-level requirements together as a collaborative exercise and then creating own issues as team members to narrow down the focus for each stage will enhance collaboration and focus.

3. "Creative problem solving" This is a critical collaborative exercise that doesn't happen in silos. We believe creative problem-solving depends on a written user story, in a predefined format, in a project management software tool with thousands of features. In that case, there is a risk we trigger the wrong focus.

4. "Creating momentum." As a team, you create momentum through a sense of completion. You solve a problem, you celebrate, and you move on. Traditionally user stories have captured information about how much work is required, the complexity, and what problem you solve. But instead of fixating on moving a card from one column to another, true momentum is given when working software is shipped to production. A working solution you can show your users. Even from a minor text change to a more significant feature launch, what drives momentum is that your team members feel they have accomplished and solved a real-world problem.

All four benefits can be achieved without a well-structured product requirement hierarchy. I advocate for apparent issues linked to your project's goal.

We can learn how to prioritize the right things using a simple combination of human interaction, technical proficiency, and business knowledge.

If we have a new feature request or a new cycle to plan for, there are three high-level activities we preferably go through as a team.

1. We discuss,
2. we write, and the last thing we do is;
3. we code.

Then we iterate, reflect, and move on. Over-simplified description of the process, I know. We have lots of design sketches produced, meetings arranged, demos performed, and so on. But these are the high-level activities that most engineers go through together as a team.

The integrated product team

Today, we build products and software together as an integrated product team. Users and developers are more tightly involved than before, and the implementers in the tech team have a better feeling and understanding of what a customer and user need. The user is not a mystical superhuman that we need to translate or tap into a different mindset to understand what they want. Customers and users have problems that can be solved by talking to them directly.

Having a part of the team managing that direct dialogue with the customers and end-users is vital to keeping the conversation alive. And constantly keeping the story alive with the rest of the team keeps everyone focused on the product or project.

Since today's users are more tech-savvy, there is no reason to take words from the user's mouth by formulating a standardized description like: "As a user, I want to be able to add an item into my shopping cart." Every user and even their mother is used to modern technology, and they know pretty well what they need or what they lack—no need to "translate them" into some socially scientific explanation.

This leads to the question: Why are we still writing user stories? What's the point of them?

Without going too far down this rabbit hole, let us switch the perspective since I am worried that we try to fix something based on an anti-pattern instead of returning to the root. More precisely, how do we work effectively as a modern, nimble product team to solve the right problems for our users?

One part of it is to write clear issues based on extreme ownership.

Discuss, then write it down.

Whenever a new request or idea pops up that is relevant to the project or product you are building. Discuss it together on a product level, on a higher abstraction level enabling all team members to think creatively and question the status quo without being too affected by current tasks.

Whenever you have an agreement or negotiated solution, you write it down.

By writing issues, you enforce clear thinking and reason through the steps necessary to reach the goal for your project. Your discussion with your team ensured you were on the right path, so be bold in your issue descriptions.

Take ownership of your issues

Writing is thinking, and if we let one person, let us call him "The Ticket Master," write all the tasks and issues for the team, we take away the thinking from the practitioner who will implement the solution.

Instead of relying on one team member to write issues, every implementer with a clear responsibility should write their own issue—keeping the solution closest to where the knowledge is.

Minimize confusion by writing well

With short and simple titles, you can directly communicate what the task is about. It should be easy to skim through the titles of your issues and get a clear picture of what they are about.

Refrain from overengineering the issues by writing long descriptions. You shouldn't have to write a description if the title is clear. Let's keep it optional. A description of your issue can consist of links to deeper discussions, technical details on how to get up and running with a more technically advanced task, etc. If you realize you must write long descriptions, that may be a sign to get back to the discussion with your team.

Bugs and issues will appear, and new feature requests will come. Instead of trying to translate them, copy-paste a customer's feedback or problem into the issue directly. There is always a risk of removing a customer's authenticity when we try to re-write them.