The user story format is practically tattooed on the brain of every PM: “As a [user], I want to [action], so that I can [benefit].” It’s a foundational tool in agile development, but I’ve been thinking a lot lately about its limitations. Are our backlogs becoming a crutch that pulls us into a feature factory mindset?
When we focus too heavily on a pre-written story, we risk turning our engineering teams into ticket-takers. The conversation shifts from “what problem are we trying to solve?” to “is this story built to spec?” This is where the magic of true cross-functional collaboration can be lost. The ‘what’ gets defined before the ‘why’ is deeply understood and debated by the entire team.
Frameworks like Jobs-to-be-Done (JTBD) or Opportunity Solution Trees encourage us to stay in the problem space longer. They frame the work around user needs and desired outcomes, empowering engineering to be genuine partners in designing the solution. It’s a subtle shift in how we define work, but it can be the difference between simply shipping features and delivering real, game-changing value. We’re not just building the thing right; we’re ensuring we’re building the right thing.
What are your thoughts on the traditional user story? Are they still the best tool for the job, or have you found more effective ways to define work and collaborate with your engineering teams on outcomes?