Why did you come looking for this information today?
Your search probably came from a place of frustration with JIRA tickets: how long they take to write; or that when they get to the development team you have to re-write them all over again; or simply how “no one reads them anyway!”.
Regardless of the reason, let’s go through a bit of a review around User Stories and JTBD stories, provide some advice on how to use and improve them. Then we can compare them and give some advice on which (if any) is the best to use in your situation.
What are user stories
A user story represents a piece of work that, once released, adds value to the user, as they use your product or service.
This piece of work, or story, should be split in a way that can be delivered independently and without a special sequence. The decision on how to write the user story should be defined and agreed with the team who will be designing, developing and delivering the story.
A story, will include other items, such as an introduction, some acceptance criteria, or even, scope. It all depends on the practices adopted by your team, or organization.
User story template
The user story template will look something like this:
The idea of having a template is so that you can easily and quickly share information about the main purpose of that piece of work. However, in environments where you have a standard ticket that everyone copies from (and you have 13 other tickets to write in a day) it is very tempting to write something like this:
“As a user, I would like to be able to click the button, so that I can see my balance”
Now, we’ve all done this, but this isn’t ideal, is it?
Writing a bucket load of stories that look like this won’t add much value to yourself, or the people who will work on the story (no, putting it on a table doesn’t make it any better).
Why?
The information in this user story will quickly become redundant and repetitive (especially if you’re using something like Behavior-Driven Development - BDD, for example).
It doesn’t give context on why it is important and how it’s going to add value to the user; - what is marketing or sales teams meant to do with this information, for example?
It isn’t clear if this story is able to add value if released independently, nor if it has other dependencies.
How to improve a user story
If you’re going through the effort of writing a user story, here are some suggestions on how your user story could be improved:
“As a "user"
Replace “user” with the persona this story is about; or add some context about the person this story is for: “person who is responsible for x”; “person who cares about y”.
I would like to be "able to click the button"
I don’t know that many people who go around saying “ I would like to click this button, please”. This is your opportunity to illustrate the person’s end goal, which in this case could be “seeing my balance”.
So that I can "open the payment page" ”
Why does it matter for your user? What is it that you will be enabling? In this case, why does the person want to see their balance? For example, “So that I can make sure I’m able to afford to spend money”.
Once you lay down information like this, it might actually spark some surprising conversations.
In this case, the user need is “to be able to see if I have enough money”. Maybe you are a conversation away of finding out that there is a better way to achieve this, or you can go deeper and really understand why this person is worried about not having enough money; who knows?
Well, you should… This is where the next method comes in: JTBD stories.
What are Jobs To Be Done (JTBD)
If you’re not familiar with the background of Jobs To Be Done: what it is and how to put it into practice; you can have a look at the previous article on it for some background.
In short, JTBD focuses on the user, what they are trying to achieve, and the value it will bring to them once they’ve achieved it. It is solution agnostic, as this method defends that our needs and ambitions have always been the same, it’s the context that is ever-evolving.
The lack of a clear solution can be mind boggling for a lot of people, so JTBD can be easily discarded. At the same time, it allows for exploration and that’s how competitive advantage can be created.
Jobs to be done story template
JTBD stories are one of the many outputs the jobs to be done framework, so bear in mind that when you write a JTBD story, your statement should have been validated.
Seeing this in practice with our previous example, it would look something like this:
“When it’s close to payday and I’m out of the house while I’m looking for something to eat for lunch, I want to see how much money I have left in my current account, so I can decide where I can go without breaking the bank”.
How to write a good JTBD story
1. Give as much color and detail when framing the situation - this can be crucial when framing the solution piece.
For example, we can see this person is on the go, so our solution is mobile and might have to cater for poor internet connection, while being fast to load (no one likes standing in the middle of the street looking at their phones waiting for something to load).
On the other hand, you can see how this would look very differently if our person was an elder who were checking their balance to see how much money they could lend to their children.
2. Frame the “needs” part as a measurable outcome, so you can test if your solutions helped this person in achieving their needs (or not).
For example, this person might be oblivious to the fact that they will have a direct debit coming up, which will affect their balance, so by simply showing them their current balance we might be providing an incorrect reading of reality - considering they don’t want to “break the bank”.
3. Speak with the people you are creating the products for - this exercise becomes a lot easier and more useful when you have already spoken with actual people, so don’t skip that part, otherwise you are likely to be creating “fantasy stories”.
Jobs do be done hypothesis
While the JTBD story might be useful when having discussions with the team about a potential solution, if you’re already in a “go” mindset and the team is really solution focused, you can also explore the JTBD hypothesis template.
User stories give us the false sense of security that we always have the solution to the problem; the job is done when you release the story. With JTBD hat on, we know the solution can be anything, so there is an opportunity to explore and validate that solution.
WORD OF CAUTION: this template implies that you have already validated who the type of customer is, their problem, and the job to be done.
This hypothesis template might look like a good starting point for you and your team, but you might have false positives (or negatives) in your testing results if you don’t actually do some level of validation.
Jobs to be done vs User stories
We promised a comparison table, so here is a high-level summary of how User Stories and JTBD Stories differ from each other:
User stories vs Jobs to be done comparison table
Which one is best?
The idea of this article is to give you a good overview of both methods.
Find out which template works best for you and your team, but also which might result in a better system for the organization.
Don’t forget to consider which will support a better solution to the customer as well; - at the end of the day what really matters, right?
What to consider when thinking about a template, or framework?
There isn’t much to gain in starting “framework wars” of any kind; however here are some things you will need to consider for both:
1. Templates can be helpful, if/when everyone in that current team has contributed to the template and everyone understands why each section is there.
This is a good topic to discuss in retros, or when new team members join in.
2. When you find yourself in “copy-paste” mode, you might want to chat with the team about where your efforts are best placed. You might want to focus your thinking, or discussions around:
Have you been focusing on user outcomes and the value each piece of work is bringing?
Are you aligned on the definitions you are using (task vs story, for example)?
Who should be involved at what stage, or are the right people responsible for the right piece of work present?
3. No template is going to fix the fact that sometimes everyone is just too busy to discuss the next piece of work. If this is the case, it is likely that you will end up with more documentation than what is needed, with items that will never be released, and with poor quality products.
You can discuss this situation with your manager and clearly state: what is the problem, and what impact it will cause. Try working together on how to mitigate some of the things that are causing this to happen.
4. Remember that nothing’s “alive” until it is in the hands of the user.
What you expect the user will say, or think, it isn’t what they are going to say or think. Make sure that you (or someone in your team) is chatting with them and taking their feedback on board.
In conclusion
It is important to know and learn about the different frameworks we have available as product people, so they can support our job. Our job shouldn’t be made more difficult because of the frameworks we adopted.
We can use and adapt the best framework for the job and avoid getting lost in semantics which will create divides. Feel free to mix it all up, if that’s what makes sense to you and your team (and you are doing a good job with stakeholder alignment and shipping great stuff).
The role of any product person is to find the best way the organization can serve their customers, in a sustainable manner. This is a big enough job, so focus on that and the activities that will support your quest.
Inês Liberato
Read also
Experience the new way of doing product management
