Hi Luis,
Thank you for taking the time to read and comment. I think we’re pretty much on the same page in some respects. The reason I say that is you’ll note that both our process and content argues strongly that iterative research with clear objectives guides the creation of Job Stories. That is something we are fairly explicit about. We also believe that situational context drastically effects behaviour. This is another reason we favour the JTBD Framework as we believe it more succintly captures the moment in which people make the decision to hire or fire a product or service. But, there are other reasons too…
To dive deeper, have you read Alan Klement’s article we reference? If you haven’t, I’d say it’s well worth it. It will add a lot of value to the discussion we’re having.
To synthesise; User Stories DO rely on assumptions. That DOES NOT mean they are formed without any reliance on research.
Why do they rely on assumptions? Because they regularly reference implementation (i.e. a solution) in the “I want” category. This doesn’t mean they rely on assumptions about the problem that may or may not be worth solving, but does mean it’s effectively the voice of the customer stating the solution they want. It is not the role of the customer/user to define the solution. Giving us insights into their problems and jobs is enough. From there, our unique collective expertise, with a lot of experimentation, will hopefully result in a really effective solution to the problem.
This isn’t a hard set rule, as in, you could choose to leave the specific solution out of the “I want” category, but let’s go deeper.
Think of a typical team practicing a solid Scrum Methodology. The PO sets the vision, manages the budget and decides on priority. The team then commits to X number of PBIs within the allotment of fixed-time. Does the PO, based on a User Story, Job Story, or whatever the structure of the PBI, then say, “Guys, this is the exact solution?” No.
Scrum teams DO NOT get to choose which problems they solve for customers. That is the PO’s job. They DO however get to choose HOW they solve those problems. Therefore stating in a User Story a particular solution is limiting. Why? Because the team has hardly even had time to assess the various ways in which this could be solved.
This reliance on ‘implementation assumptions’ is where Alan argues there is an existing weakness, as well as an opportunity for improvement. In this we agree with Alan quite strongly.
Throughout this article, and others, we also state that we observe User Stories being used very poorly. This does not mean they are bad in all situations for every team. What this does mean is our experience has now led us to believe that the JTBD Framework (i.e. a systematic approach to understand the need you’re trying to fulfil, which could of course be something other than the JTBD Framework), backed up by Job Stories as the highest level synthesis of the research, encourages an environment where implentation detail isn't assumed too early, but where implementation detail is the process of discovery that occurs through constant iteration. This of course happens post initial research (i.e understand the human need you’re trying to fulfil with decent granularity). But what we’ve come to learn is that initial research and an understanding of the problem space, or the JTBD, doesn’t necesarily result in the right solution. The right solution is the result of constant experimentation. Experimentation requires flexibility and Job Stories provide us with both the situational content (i.e trigger to hire or fire) and flexibility we require to explore various solutions.
User Stories, in their common form with implementation detail assumed, don’t give us what we need.
Now, having said all of that, does that actually mean User Stories can’t be incredibly useful if they are structured effectively and don’t assume implementation detail? Of course not. Nowhere do we say they can’t be useful. We have a very clear preference for a number of reasons and what we’ve tried to do is articulate those reasons within the context of how we work.
What I hope I’ve done in this reponse is help you dive a little deepr into our psyche and empathise with why we choose to use the JTBD framework, supported by Job Stories :)
Happy to have a deeper discussion if you wish.
