While I love the ‘jobs to be done’ angle (There’s a good podcast on it here - http://www.thisisproductmanagement.com/episodes/jobs-to-be-done ), I’m not sure I have bought into this idea. I’d be Interested to hear your ideas on this.
I taught an entire company how to do job stories because they had only one persona. Some of the UX and designers fought me on it, to which I said "I’ll happily use user stories when you come up with multiple personas.
Job stories are amazing to me, because they give much better context for the beginning state of a requirement and the situation in which it’s needed. Developers and testers commented it was easier to write ACs for as well as tell the story of the requirement to others.
So…big fan here.
Let me know if you want to chat about it more, would love to give you more of the story of how I introduced it.
What I find particularly interesting here, from a historical angle, is that the author is equating the “user story” concept with a particular template. The “job story” is then presented as a different template. But as I remember things, the “as a … I want … so that” template was really just one person’s suggestion for a handy way to structure user stories, introduced several years after the user story concept was already baked into XP (it doesn’t appear at all on the C2 Wiki’s UserStory page, for example). That template has always felt awkward to me, not least because once the template becomes a habit it’s easy to lose sight of the reasoning behind the template. I’ll try to keep this alternative “job story” template in mind to see if it helps get people unstuck, but I’m also wary about replacing one habit with another.
The important thing is to focus on the problem for as long as possible before talking about solutions.
I have had many experiences where talking about solutions has kept us discussing and misunderstanding what we want, while talking about the problem to be solved / job to be done is so much cleare to everybody.
And at the same time it transports information and context about the users to all that participate in the creative work, too.
So true. Using the template for the sake of using the template is often awkward and leads to misunderstandings. Sometimes you can hear Scrum Masters or Product Owners say “But you use User Stories in Scrum, it’s the way it has to be done!”. It’s very unfortunate that this format is so stuck in many people’s heads.
The Job Story is a good alternative, IMHO. But sometimes not using a template at all is very productive, too.
Somehow I keep hearing about Jobs To Be Done. This very Agile Uprising thread was the first time I heard of it (guess I’ve been out of touch for a while). By an independent path I just ended up at this presentation, which made it a lot clearer for me:
The key insight (for me) explaining JTBD was in slides 6 & 7. But then he also gives a contrasting interpretation of User Story vs. Job Story in slides 15 & 16: They’re not alternatives, they’re complementary. We can start with a backlog of Job Stories representing problems to be solved and then brainstorm User Stories representing potential solutions for the next selected Job Story. Very interesting perspective.
That’s a really interesting perspective and one that I hadn’t considered before. As I was reading through the slides, my gut reaction was to disagree because I have a different experience gathering feedback and data from users as well as using Job Stories.
But there are some really cool possibilities when considering the Jobs are the epics and the User Story cards are the refined backlog to be used for development. I’m going to have to consider this more and try it out. Maybe from a SAFe release train perspective (if you’re into that sort of thing), the jobs could be the features part of a release train.
The aspect of those slides I probably disagree with most is customers knowing or not knowing what they want. Granted when he gives the presentation he may not say it this way, but it’s not a binary decision point. Users can know what they want and not know how to do it, or vice versa. And I’ve never worked with a customer who only measured users that buy. More often than not, retailers or service providers talk to people that DIDN’T buy more than the ones that did. That’s where value-stream mapping comes in.
That said, it doesn’t invalidate the concept.
I’ve used User Stories if there are multiple personas and Job Stories if there’s only a single one. So if I start with one, I usually stick with it. But this helpful info challenges me. Thanks for sharing Justin!
I ran across Jeff Patton and learned of his Story Mapping concepts. They were the closest thing I have seen to what we preached and practiced at TogetherSoft under the banner of Feature-driven Development.
It’s hard to put into words the nature of how I drive development by a domain model and features… as they are deeply intertwined. The major key is to develop client-valued features
I wrote a bit about it here: User Stories and FDD
But I have a great internal wiki that I wrote on writing features… issues… stories. I should turn it into a blog… But I will paste it here to start.
Proper decomposition of a feature set is the first step to breaking it down into manageable, visible bits of success.
The only real value that we can deliver is a fully functioning feature (and arguably, one that is sufficiently documented).
We do not want to break down issues in terms of technical layers (UI, Logic, Database). Customers can’t typically use a partially-implemented feature. Developers can add technical sub-tasks as needed (these need not be verified).
We do want to break features down into “vertical” slices as much as possible, so that we can deliver a fully-usable, valuable feature.
Split Stories into Small Chunks
Features (stories, use cases, requirements) are simply small blocks of client-valued functionality (they might appear on a marketing brochure or a users manual, and they are things the customer is willing to pay for (smile), and things that can have bugs against them (sad)). Ideally, you decompose – or break down – larger stories into smaller chunks of functionality (makes it easier to show progress and get feedback more quickly).
Features can be written in a couple of different ways, two of my favorites:
<Role> <Action> <Context> (thanks to Joshua Kerievsky) Salesman creates quote for a simple request Salesman creates quote for a complex, large RFQ <Action> the <result> <by | for | of | to> a(n) <object> (thanks to Peter Coad) Change the default price for current item Calculate the total of a quote’s items
We can group related features into a Feature Set. Here again, we can use a tip to help in naming the feature set:
<Action><-ing> a(n) <object> Creating a Quote Configuring a Quote Item
To group related Feature Sets, we can create an even higher organizing theme: Major Feature Sets. And once again, a common naming convention applies:
<Object> management Quote Management Order Management Product Item Management
None of these conventions are strict, but they do help to steer the names in a consistent manner. And we all know consistency is a quality unto itself, right?
Some articles for you:
That’s a great piece of content @Jon I’ve been combing through it this morning. Would love to hear some of your experiences in teaching this material. Guess it depends on the crowd right?
I like the role, action, and context bit…but for most of the work I’ve done in my career there haven’t been more than one role. So that part seems extra if there’s no variance. Just like if the context were the same it might be difficult to keep putting it in there (for example).
Which is why I usually teach context, action, result. That’s the job story for the most part. Make sense?
@PaulValitutto this is the first article I read on them and just kinda started trying them. Let me know if you have questions or want to chat about them.
@PaulValitutto sorry I should paste the damn link lol https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27
I enjoyed reading “Competing Against Luck: The Story of Innovation and Customer Choice”, which, when I got that correctly, is written by the “inventor” of the JTBD framework.
From the article linked by @chrismurman, which was one of my first contacts with JTBD, too, I first got the impression it would indeed be a simple replacement for user stories - which in and of itself is useful, imho. (repetetive stories starting with “As a user” or abominations like “As a user I want that the dev team refactors the core code”, anyone?).
When reading the book I realized that it originated in a much bigger scale - maybe one Job To Be Done per company even! IMHO it is a good mix to see the JTBD principles applied to both scales to see the value and change your inner way of thinking about “requirements”.
I wouldn’t consider it dead but at the same time, i’ve found that you have to be practical in how it’s used.
At the end of the day, it comes down to balancing the request against the delivery in a way that aligns with your customer, product, and team values. For some teams, you can accomplish that with User Stories without any AC, for others, a more strict template for format may be necessary.