We’ve all written thousands of them: “As a , I want , so that .” The user story was created with a noble goal: to keep the user’s perspective at the heart of our work. But let’s be honest, has it become a hollow ritual?
More and more, I see teams using the format as a rigid template, a checkbox to fill out before getting to the “real work” of writing code. This approach often obscures the actual problem we’re trying to solve, reducing a complex user need into a single, context-free sentence. It’s a fast track to becoming a feature factory, churning out a backlog of “wants” without a deep understanding of the “why.” This leads to solutions that are technically complete but fail to deliver real value.
The shift I’m seeing among high-performing teams is a move away from this rigid format towards more narrative, problem-oriented approaches like Job Stories (JTBD) or Problem Stories. Instead of focusing on the requested action, they focus on the underlying motivation and the context of the struggle. This aligns everyone—PMs, designers, and engineers—around solving a core problem, encouraging better questions and more innovative solutions.
How has your team adapted the user story format, or have you moved to a different framework altogether to better define the work to be done?