Apples, Oranges and User Stories
Imagine you’d never seen an orange or an apple before. Then, imagine you read an article by a vitamin consultant who shows you an image of a shiny, red fruit, saying – “This is an orange, it will help you with your vitamin C deficiency”. It’s a similar shape to the foods you’ve eaten for other vitamin deficiencies so still fits your model. You proceed to eat lots of this red, shiny, crunchy, refreshing fruit and you teach your colleagues the same. Now they’re eating “oranges”…
“You keep using that word, I do not think it means what you think it means.”
After some time, your vitamin C deficiency still hasn’t improved. So everyone says “down with oranges, they don’t work” – including the consultant who wrote the article. The problem was that you were eating apples, not oranges. But it’s too late, you, your colleagues, the consultant – all have a disdain for anything labelled ‘oranges’.
This sounds ridiculous, but only because you know the difference between oranges and apples. Yet, it reflects the same kind of misconception that has fueled the growing disdain among some peers for the Connextra Template – As a…I want to…So that…
- Some believe User Stories are analogous to product features & that they should state business benefit – this is a fundamental misunderstanding;
- User Stories are about what the user will be able to do/achieve (not actions or features they’ll do it with);
- The Connextra template (As a / I want to / So that) helps us start valuable conversations about: who the user is, what they want to do and why;
- Some tried to ‘improve’ the Connextra template to capture features and business benefit (software requirements). These ‘improvements’ spread far and wide, propagating the ‘feature’ misconception of user stories;
- It’s not too late to make the paradigm shift away from writing ‘software requirements’ to truly understand user stories as ‘the story the user wants to be able to tell’;
- Truly understand the User Story paradigm and you realise that the Connextra template is as useful as ever.
The root of the misconceptions
Think of a User Story as a short-story that a user will be able to tell about what they want to do and why they want to do it. It’s not the feature the product will have or the actions they’ll perform, it’s what the user will be able to do – as in achieve. One story may actually mean subtle or significant changes to multiple features, involving several actions.
“Stories aren’t a different way to write requirements, they’re a different way to work” -Jeff Patton
User stories are a paradigm shift, a different way of working. Jeff Patton explains this superbly in slides 1-50 of his User Story Mapping slides (I highly recommend you flip through them). Jeff highlights that “Stories aren’t a different way to write requirements, they’re a different way to work”.
The misunderstanding that User Stories are just a different way to write old-style software requirements has contributed to continuous deterioration in how the Connextra template is communicated across the industry – changing User Stories into features (or related user action).
Unfortunately, the problem wasn’t with the Connextra template, it was with a misinterpretation of it. This misinterpretation propagated so far and wide, that many teams now experience the problems caused by slicing work into features (problems that User Stories are designed to solve). And now people are saying – “User Stories are broken!”. Clearly, comparing apples and oranges, much like in the opening story.
How did this happen?
The Connextra template highlights the who, the what and the why from the user’s perspective:
As a <someone>
I want to <do something>
So that <some result or benefit>
This helps us start the right conversation; exploring the short story a user could tell about something they’ll be able to do – hence the term ‘User Story’. The “As a…” helps us start empathising with the user. The “I want to…” gets us thinking about what they want to do (not how). The “So that…” get us closer to their motivation – why they’d want to do this.
Unfortunately, many people mistook User Stories to be just a different way to write requirements – which they’d always expressed as features & functionality. In their efforts to help colleagues and peers understand user stories in the same way, several people changed the template:
As a [role]
I want [feature]
So that [benefit]
Many teams found that whole features were too big to implement in a short enough window, so we also saw a variation on this where the interactions within the feature were described:
As a [role]
I want to [action]
So that [outcome]
Others sticking with the larger feature model, asked about ‘benefit’ part – what’s that for? Is it the benefit to the user? If it’s about the user, then where do we ‘document’ the business benefit? The question of ‘value’ and ‘business benefit’ was seen to be missing so we started to see further perversions of the template:
As a [role]
I want [feature]
So that [business benefit]
People didn’t always know what the specific business benefit of a feature was so they started writing “As a… I want ” and left the “So that…” part out. So, a different format was put forward to encourage thinking about the business benefit and we ended up with a catch-all for feature or action – “functionality” – plus the business benefit as the opener (which became a confusion between what the business wanted and what the user wanted):
In order to <achieve some value>
as a <type of user>
I want <some functionality>
And what we end up with is something that is not sliced as a user story at all. Instead, it’s just features & business benefits – old-style software “requirements” dressed in a User Story like template.
User stories are about the user – hence the name. It’s a way of working, not a way of writing requirements. This is an area we all need to get better at explaining.
What we write on the User Story card (or electronic equivalent) using the original Connextra template helps us start the right conversation about users’ needs, slicing by value to the user. Starting the right conversation to slice by business value is a different problem.
The original Connextra template works just fine for User Stories that tell a story about the user. The template wasn’t trying to fix the mindset of slicing-by-feature. Books like User Stories Applied were there for that. The misconceptions began when people assimilated User Stories through their feature-biased filters and tried to ‘fix’ it – rather than question their own understanding.
This left many teams with “features dressed as stories” caused by a fundamental, yet common, misunderstanding. I may have once shared in that misunderstanding myself. Now, we have an opportunity to change this by learning more truths about User Stories so that we can all benefit from the increased agility they enable.
Have you been working with features dressed as stories? If so, and you want that to change, here’s a place to start.