We’ve all been there, writing ticket after ticket in the classic “As a [user type], I want [an action], so that [a benefit]” format. The user story has been a cornerstone of agile development for years. But lately, I’m seeing a growing discussion questioning if this format is actually limiting our potential.
The core argument is that the user story format can inadvertently push us into a feature factory mindset. It frames the work around a pre-defined solution (the “I want” part) rather than the underlying user problem. This often leads to engineering teams becoming ticket-takers, disconnected from the ‘why’ and focused solely on shipping the requested feature.
Shifting the focus from solutions to problems—using formats like Job Stories or Problem Statements—can be transformative. It empowers the entire team to think critically and creatively about the best way to achieve a desired outcome. When your backlog is framed around problems, your cross-functional collaboration deepens, and roadmap discussions become more strategic. Ensuring everyone is aligned on the customer problem (something we use tools like https://leera.io to keep front-and-center) connects day-to-day work directly to real value.
This isn’t just about semantics; it’s about shifting from building a list of features to solving genuine customer needs.
Have you or your team experimented with moving away from traditional user stories? What have you learned?