How you can help your Product Owner write better User Stories
Let's start with a story about John.
John uses your HR software and sends an email to your Product Owner about something that's been bugging him for a while.
Now it's time to make the HR system reflect these changes so employees get their new salary in time for Christmas.
Making the change one by one is going to take forever and there is a big chance that I will make an error which would cause employees to get the wrong salary.
Employees would then be really upset with me and my HR manager will have to work during the holidays to fix this in all the other systems.
That sounds awful!
Personally, I would love to help that guy!
But this is what lands in your backlog...
Now, we obviously can't work with that!
So you ask the product owner to write it as a user story instead.
That should fix it! Agile makes everything better!
And now this is what you get...
Is this better?
Did rewriting it as a user story fix it?
Of course not.
And it's actually worse!
Now it almost look like it makes sense.
Why do we end up with stories like this?
And how can we get better user stories from our product owner?
It's easy! Stop focusing on the user and focus on the story!
The problem with user stories is that they start by focusing on the user.
Not the situation they are in.
Enter... Job stories!
Remember the User Story pattern?
“As a [type of user], I want [some action], so that [outcome]”
Job stories follow a slightly different pattern
"When... I want to... So I can..."
You might notice that there is no made up [type of user] in the job stories pattern.
It's all situational.
With an expected outcome in the end!
This expected outcome becomes the acceptance criteria for your story.
Let's see how we can improve the user story by asking the right questions
Remember, this is what we started with..
Now for the questions.
Q: First of all, what job does the eligible user have?
PO: Well, John is an HR assistant at SemiCorp Inc.
Q: Why do they need to upload a document?
PO: Because they already have an Excel document that includes all the updated salaries and they don't want to have to update them one by one in our application.
Q: How many people are we talking about?
PO: Something close to 500 people, I guess.
Q: What time of day is the user doing this
PO: Not sure, didn't seem important
Q: How often do they do this?
PO: Not often. They said they do it right around Christmas time. So come to think of it, it is probably a bit stressful with all the other things they have going on.
Q: Where is the user when they need to do this?
PO: They are usually in their office because the excel document is on their hard drive
Q: What happens to the user if they don't do this properly?
PO: They mentioned something about having to manually redo the changes in the integrated systems. Oh yea, they also mentioned that people tend to get angry if they don't get the correct salary payout, which makes a ton of sense.
So a job story might look like this
... I want to be able update and verify them all in one go
... So people get their correct salary in time for the Christmas shopping and my manager doesn't need to work overtime during the holidays
Now that's a lot better, don't you agree! This is something we can work with.
How do you get there?
In your next refinement, try asking some of these questions to help your product owner write better user stories.
- What time of day it is?
(when I have my morning coffee; when I have an afternoon for myself) - What cadence is work done at?
(When doing the monthly invoicing, When doing my daily time sheets) - Where is the person?
(When I'm in my office; when I'm in my car) - What other things are they doing at the time?
(When I'm on the call with a customer; when I'm in a meeting; when I'm dropping my kids off from school)
Related articles