User story writing techniques: avoiding the circular story by focussing on the benefit
Introduction
We’ve all seen them, and some of us are guilty of having written them. I’ve certainly seen enough evidence that the circular user story is a common mistake.
User stories are usually written in the format:
“As a (role) I want (something) so that (benefit).”
In a circular user story, the requirement being proposed (the ‘I want’) and the benefit being described (the ‘So that’) are pretty much the same. Here’s an example of a circular story:
As a customer
I want to change my password
So that I have a new password
Effectively, you might as well just omit the benefit:
As a customer
I want to change my password
In this post I’ll discuss why it’s important not to skip the effort of writing the benefit part of a user story or falling into the trap of simply repeating what’s already been stated in the ‘I want’ portion.
‘I want’ doesn’t tell the whole story
User stories are intended as an invitation to a conversation. This is because it means we can understand a user, their needs and their motivations before diving into creating software. The ‘I want’ part of a user story is as close as the story gets to describing a specific requirement but in itself it lacks an explanation of why there’s a need for it in the first place. And it’s this explanation that can contain the information we need to enter into meaningful discussions about how to go about implementing the story.
In defence of ‘So that’
In Mike Cohn’s post ‘Advantages of the “As a user, I want” user story template’ he suggests that the ‘So that’ part of a story is optional. Far be it from me to disagree from someone I’ve learnt so much from but I would advise proceeding with caution if you’re going to leave it out. I’m not saying there aren’t circumstances where it’s OK to leave out the benefit but the decision to do so should be based on merit and not taken as a short cut (which is my worry when I see examples of stories like this): the story could be misinterpreted because there’s potentially some vital information missing or there’s a risk of implementing a story with no perceivable value.
My general rule is that you shouldn’t implement a user story if you cannot define any real benefit for doing the story in the first place. And, when it comes to creating user experiences that not only fulfil a requirement but also tailor it to specific motivations, dare I say it, ‘delighting’ the user along the way, we need to understand the benefit because it provides us with the context when we’re discussing the story.
Describing the benefit provides context
Think about how different the conversation would be when discussing these two examples and think how the user experience could be tailored to help the user in each of the given contexts.
As a member of staff
I want to change my password
So that I can adhere to the company policy that requires me to update my password every 30 days
As a registered user
I want to change my password
So that I can log back into the system after I have forgotten my password
Just because it’s hard, don’t skip it
Writing the ‘So that’ part of a user story can be hard, indeed it’s often the hardest part of story writing because it may require you to scratch beneath the surface and question quite a lot — it takes effort because you have to unearth the value proposition of the story which often means reaching out beyond your usual cohorts. But that effort can save a lot of wasted development (which is expensive) and lead to better solutions. In the words of the gov.uk service manual:
“When writing a user story, make sure the story is well-formed. Don’t skip the part explaining why there’s a need for a service just because it can be difficult.”
Try flipping it on its head
As an exercise, it can be worth flipping user stories on their head and starting by describing the benefit, after all, the benefit is the value proposition of the story. It can also help you to think more creatively about the ‘I want’ rather than prescribing a solution first and shoehorning a benefit just to fill in the blanks as people can do when they suffer from feature infatuation.
To conclude
User stories are the lifeblood of an Agile project; they feed the production team with just enough information about a requirement without being too prescriptive about implementation. But it’s possible to get into bad and lazy habits resulting in writing stories which can be either circular, or completely omit the benefit. Falling into this trap can reduce your ability to provide context to the user experience and software you’re creating. In other words, a requirement may be implemented but it may fall well short on the ‘delight’ scale.
