Three quick tips on writing the perfect agile user story | Unlock Your Team's Genius

Three quick tips on writing the perfect agile user story

By Georg Fasching | agile practice

Sep 13

Master the art of fail-proof user stories that keep the quality of work consistently high

Tip 1: Be INVESTed

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:

  • Independent: the story must be a deliverable entity on it’s own
  • Negotiable: the solution must be up for negotiation in case of e.g. an easier way to achieve the same value.
  • Valuable: it must bring clear value to the end user
  • Estimable: it has to be concrete enough for the team to assess the level of effort required
  • Small: it’s got to be sized appropriately so that it can be delivered in a fraction of a single sprint–the smaller the better
  • Testable: the product owner must be able to check it against the end result

Once the user story satisfies all of the above then it’s in alignment with the INVEST criteria.

Tip 2: Create a user scenario

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

Tip 3: Satisfaction and acceptance

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:

  • High value referrals completion results in instant notification
  • Medium value referrals completion results in daily notification
  • Low value referrals completion results in weekly digest notification

Acceptance criteria (using the simple “Can I …?” format) might be:

  • Can I choose SMS or push notification for high value referrals notification?
  • Can I choose time of day for medium value referrals notification?
  • Can I choose which day of the week for low value referrals notification?
  • Can I specify an email address for medium and low value referrals notification?
  • Can I receive each of the notifications?

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.

Follow

About the Author

A leadership team development specialist, International Coach Federation - Professional Certified Coach, with global product management experience since 2000, employing Agile & Lean since 2010, Georg Fasching helps digital creative agencies’ leadership teams delight their clients, fulfil their people, and improve their prosperity.

>