This article talks about a different approach to capturing product requirements and describing the problems a team is trying to solve. It describes user story as too limiting, perhaps too granular. The story loses the meat of the problem being solved and the setting in which it is being solved. The author proposes a new story format called a job story. A job story intends to capture more context around the user, their needs, and how they’re interacting with the software.
Image source: Alan Klement
This kind of challenge to the user story format is not new – nobody enjoys writing user stories because they’re fairly artificial, often too obvious, and it can feel less than valuable. The solution certainly addresses aspects of the challenge, but I see the author’s suggestion as overly blunt. A key part of the agile manifesto for me, is as follows
Individuals and interactions over processes and tools
In this case I suspect that if a team were to choose to “adopt job stories rather than user stories” there would be churn and concern about change, its impact, roles involved, defining expectations – all that good stuff as people are asked to “manage change”. Another approach would be to loosen the constraints imposed by a strict user story format. Don’t make a new artifact out of this, just write the stories a little differently.
I also believe that the author’s situation that lead to this approach may be due to a lack of an empowered BA on their team. The BA, ideally, will capture all this information, including UX requirements (either through their own skills or through collaboration with UX team members), and present requirements that meet the teams’ needs as well as produce the right results.
The job story sounds like a bit of a process change that could better be accomplished with a refocusing of the team on how requirements are gathered, captured, and communicated. One could imagine the BA/UX people speaking with the team about a new story format they’re trying out and asking for feedback on. The development team might not even care about the change, though QA may be slightly more interested.
In the end I support the “Job Story” focus, as it better captures users needs and the real problems the team is trying to solve. I’m reluctant to create a whole new “thing” that a team has to adopt, leaning more towards allowing the team to find the right balance in their requirements that meets their needs. User Story structure should not trump a team’s desire to improve on how it captures and communicates product requirements.
Finally, I agree that personas are often not helpful when written because they include too much demographic information or back story. Don’t throw the baby out with the bath water though. Personas, when created well, actually can help convey user needs, context, assumptions, motivations, etc. This is more a quality concern than a need to question the concept entirely.