Stop Fighting About Backlog Formats. Pick the One That Fits the Question.

Your team keeps arguing about how to write backlog items. One person wants job stories. Another swears by user stories. Someone read a blog post and now wants to burn personas to the ground. The fight feels important, but it wastes time and settles nothing. The problem is treating this like a contest with one winner. These formats answer different questions at different points in the work. A leader's job is to know which question is on the table and reach for the format that fits.

The debate has no winner because they solve different problems

User stories came from Agile software work. They describe a piece of functionality from the user's side: as a role, I can do a thing, so that I get a benefit. They are built to hand a developer something to build. Job stories came later, from a team that wanted to capture why someone acts, not just what they click.

As Avi Siegel puts it, the argument over which is better is misguided. They are different tools useful at different times. Job stories dig into the pain and the need. User stories describe the work to ship. Asking which one wins is like asking whether a hammer beats a tape measure.

Job stories keep you honest about the why

The reason job stories exist is simple. People are good at describing their problem and bad at describing the fix. When they hand you a feature request, they hand you a guess at a solution. Your job is to dig back to the motivation underneath.

The Intercom team invented job stories to do exactly that. Their format is three parts: when a situation happens, I want to do something, so I can reach an outcome. Notice there is no persona, no age, no job title. They found that people with very different attributes often share the same motivation. A parent posting a family photo and a teenager posting a party photo want the same thing. Design for the motivation and you serve both.

Personas are not dead, they just have a smaller job

Some people took job stories as a reason to throw out personas entirely. That goes too far. Personas still earn their keep when you need to show that different types of people do the same job in different ways.

The JTBD Toolkit walks through this with a clean example. If your job performers are conference attendees, in-person and remote attendees follow the same job steps but prioritize different outcomes. That difference warrants two personas. Same piece also clears up a common mistake: job stories are a summary of what you found after research, not a shortcut you scribble before you talk to anyone. Do the analysis first. The story is the output.

Match the format to where you are in the work

Think of your backlog work in two stages. First you figure out the problem. Then you build the fix. Job stories live at the seam between those two. They pin down the problem in a way anyone on the team can remember. User stories sit downstream, tied to the actual thing you ship.

When the standard format feels awkward, that is a signal, not a failure. Valerio Zanini points out that not every backlog item is a user story. Sometimes the work is a system behavior with no human doing anything, and forcing it into user-story shape just makes it confusing. Pick the framing that gives the team the most clarity for that specific item.

Feedback is raw material, not marching orders

Most of the argument about formats masks a deeper miss: teams collect feedback but cannot turn it into product changes. A pile of feature requests is not a plan. Each request is someone telling you what they want, dressed up as a solution.

Ward Andrews makes the case that feedback only works when you pair it with the job behind it. Use the milkshake logic: people were not buying a milkshake because they liked milkshakes, they were hiring it to make a boring morning commute better. When a request comes in, ask what job it points to. That question, from Alex Jupiter's take on Jobs To Be Done, turns a noisy inbox into a short list of real problems worth solving.

The deep cut

The format fight is a proxy for a bigger question: who owns figuring out the problem, and who owns building the fix? Tony Ulwick splits this into distinct roles. When the planning team fails to hand designers a clear problem, designers get dragged back into figuring out the problem themselves. That causes rework and slows everything down. That is what a messy backlog actually costs you. Job stories are how the problem-owners pass a clean, motivation-first definition to the people who build. Get the handoff right and the format debate mostly disappears, because everyone knows which stage they are in.

Three questions for your team

• For the request on top of our backlog right now, what job is the user actually hiring us for, and what would they stop using if we won?
• Look at our last ten backlog items. How many are user stories we forced onto work that was really a system behavior or an untested motivation?
• When feedback comes in, who on this team owns translating it into a job before it becomes a build task, and does that handoff actually happen?