Master the art of fail-proof user stories that keep the quality of work consistently high
The first rule for writing great user stories is to make sure it’s always in compliance with the INVEST criteria. You may or may not have heard of it but INVEST is an acronym that stands for the following:
Once the user story satisfies all of the above then it’s in alignment with the INVEST criteria.
The term ‘user story’ and ‘product backlog item’ are nowadays largely interchangeable. The reason the user story format is widely adopted, and considered a generally accepted practice. It is widely adopted because stories come natural for people; they are a written in a language that everyone understands. If you imagine the user as a character in a story you can write a simple sentence that goes like this:
As a [user type/persona], I want to [action] so that I can [value].
A completed example of this would be:
As a corporate partner, I want to receive updates on my referrals so that I can understand the value I’m bringing to our partnership.
Be sure to fill each of the gaps, and that the outcome has real intrinsic value that the story aims to deliver by its completion. If it helps, flip it around and start with the value:
So that I can [value] I want to [action] as a [user type/persona].
“It is important to note that the user story is a summary and reminder of a conversation that the team had, not a substitute for conversation and collaboration.”
Lastly, an ideal user story will typically include two things: ‘conditions of satisfaction’ and ‘acceptance criteria’. In agile working, acceptance criteria is very well known, but conditions of satisfaction are not.
Conditions of satisfaction are solution agnostic conditions by which the user value will be released. When you have a user story available, you can work out, regardless of the route, what are the success criteria, definitions, goals or quality metrics that you want to achieve? And then separate to that, you’ll have your acceptance criteria which are solution-specific.
For example, using the user story above, the conditions of satisfaction might be:
Acceptance criteria (using the simple “Can I …?” format) might be:
If the team determines in a product backlog refinement session that the product backlog item is too large, then they can split the user story, e.g. by referrals value.
I hope the video and tips above help you to create better user stories or product backlog items for your team. Once concrete stories are created using the suggestions above, the work can be better understood, managed, executed and tested to bring real value to the business.
If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!
Here’s the full transcript:
-Hi, Georg Fasching here, helping you unlock your team’s genius.
In this video I’m going to focus on writing user stories.
This is another episode in the Power of Three series where I’m spending just three minutes on sharing my top three tips and encouragements on a particular subject.
And with that, let us put three minutes on the clock, starting, now.
So the first thing is I need to caveat this one because there is a great deal to be saidabout writing good user stories, but I’m gonna share my top three things to get you off to a great start.
So, the first thing is you want to write user stories
that are in compliance with the INVEST criteria.
You may have come across this before.
In case you haven’t or in case you’d like a refresher, let me do that for you.
INVEST is an acronym. It stands for Independent.
User stories ought to be independent.
Negotiable, the way to achieve the value of the user story needs to be pliable.
Of course, there may be a simpler way to achieve the same value for the user.
Then it needs to be valuable.
The V stands for Valuable, of course.
You want to be able to release value to the user just by delivering this small piece of functionality.
E stands for Estimatable.
It needs to be concrete enough so the team can have a conversation, work out roughly where effort is going to be involved in realizing that value.
S stands for sized appropriately.
It should be small and it should be able to realize this is a short period of time.
If it currently takes you four or five days, aim for one day and then see whether you can push that down even further in your team.
And T, it needs to be testable.
So the user story needs to be written in a way where you can check it against the definition that is in the user’s story and written in there. All right?
So it needs to be in the INVEST criteria when you’re writing the user stories.
The next thing is that user story is not only a synonym for Product Backlog Item, but it is, of course, also a format.
As a type of user, I want to do a certain action in order to realize a specific value or satisfy a need of mine. “As a…, I want to…so that.”
Now, it’s very important that I don’t skip over the “so that.”
I’ve seen product backlogs where I just see the “As a…, I want to…”
It’s important to start with the end in mind, if you will.
If it helps you to remember writing about the purpose and the value you want to release, you can turn it on its head and say, “So that I can do this and that, I want to do this and that as a type of user.”
So, you can turn it on its head, in order to help you when you’re writing a user story.
Now, the third thing I wanted to get you started with is to include conditions of satisfaction and acceptance criteria.
Now, acceptance criteria is pretty well-known, conditions of satisfaction less so.
Conditions of satisfaction are solution agnostic, conditions by which the user value will be released.
So, when you have a user story available, you can work out, regardless of the type of solution that we end up choosing, what are the success criteria, the success definition, if you will, the success goals for the particular quality metrics that you want to achieve.
And then you have your acceptance criteria, and with that, unfortunately, our time is up.
As I said, there’s much to be said about writing good user stories, but these three things are the ones I wanted you to start off with.
So, thank you very much for your time.
And, if you have any thoughts or comments, please share them down below.
If you found this video useful as a starting point for
great user story writing, please like, share and subscribe.
And with that, I would like to thank you very much.
All the best for the practice with your team.
Until the next video, thank you again, and goodbye.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.