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!
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.