For years, the ‘As a user, I want, so that’ format has been the bedrock of agile development. It was designed to anchor our work in user value. But lately, I’m seeing more and more teams question if it’s still serving us, or if we’re just going through the motions.
The core criticism is that this rigid format can inadvertently push us into a feature factory mindset. We spend more time perfecting the syntax than understanding the underlying problem. It can sometimes obscure the ‘why’ behind the work, reducing a complex user need into a single, sterile sentence that doesn’t inspire genuine collaboration or creative problem-solving.
This has led to the rise of alternatives like Job Stories (‘When , I want to , so I can ’), which focus on context and causality. Other teams are ditching formal structures altogether in favor of well-researched problem statements that give engineering and design counterparts the autonomy to find the best solution. The goal is the same: to shift the conversation from ‘what are we building?’ to ‘what outcome are we trying to create?’ This empowers the entire team to own the problem, not just the ticket.
How has your team evolved its approach to defining work? Are you still finding value in the classic user story format, or have you moved towards Job Stories, problem statements, or something else entirely?