Once upon a time, during the development of the Extreme Programming methodology, a man called Alistair Cockburn coined the phrase, "A user story is a promise for a conversation."
Other proponents of the agile user story, such as Ron Jeffries and Mike Cohn, have continued to develop this idea until arriving at the user story, as we know it today:
As a <persona>
I want to <do a thing>
So that <benefit>
This new format for writing out requirements was a massive step forward for the industry, and soon, the agile user story became a staple within agile teams around the world. Instead of having pages and pages of stale requirements filling an enormous specification, we now have contextual snippets that give an actual problem to solve instead of having to work through someone else’s guess at a solution.
The formula presents the ‘persona’ as a type of real-life user of the software. The ‘do a thing’ is an action that real-life users would want to do, and the ‘benefit’ is the reason they want to do it. Creating a relatable scenario in this way provides everyone with the context they need to find the best solution.
Luckily everyone always writes user stories properly, and no-one ever misuses them to the point of them becoming devalued.
Just kidding; occasionally, we’ve ruined them.
Instead of following the proven and established format, so many teams and organizations use stories as a catch-all or a shortcut when they don’t know what else to do. Using them as a starting point, they veer wildly from the story format instead of putting the time in to get it right.
For example, who has seen a user story that looks like the below?
As a system
I process the information
So that the information is saved
The above might sound like an exaggeration, but it’s not. I’ve seen stories written like this across several companies, and it’s baffling. Below is another example that I’ve seen numerous times when the story is approached from a developer’s view:
As a developer
I want to see more bugs
So that I can diagnose issues
Why Does This Happen?
People write stories this way for a straightforward reason: because ‘user story’ has become a synonym for ‘piece of work,’ and so they think that’s what’s required. Want something in the sprint? Shoehorn it into a user story. That’s the approach a lot of teams take nowadays.
In a software development environment, it’s common to hear “create a story for it,” when anything from a new requirement to a small bug fix is mentioned.
It’s generally seen that the hierarchy for pieces of work is a user story at the top, with sub-tasks underneath, and people seem to default to this, even when it’s not appropriate. This is why we end up with things like “as a developer” or “as a system” in a user story where they don’t make sense.
Why is this a Problem?
On the surface, you’d be forgiven for thinking that it doesn’t matter if we employ the user story structure for things that aren’t user stories, but misusing a user story framework can have a much bigger effect than you might think.
The main benefit of user stories is the context they supply. When the focus is placed on solving the problem told in the story, you can come up with some genuinely brilliant solutions. But you can only do this if you’re focusing on the user story as it is written. The waters are muddied when you’re creating ‘user stories’ that aren’t user stories. If half of the time, the ‘story’ part of a ticket is pretty much nonsense, people stop paying attention to it.
How can we Solve the Problem?
The solution is pretty apparent, but oddly, people seem resistant to do it. All that needs to be done is have clear definitions for how you categorize your work and stick to them. If the task is to try solving a problem for a user, then it should be a user story. It’s likely to be a specialized task if it’s a technical piece of work that doesn’t directly relate to the user’s needs. Things like bugs and tech debt should also be categorized in their own right.
They should also have their format specific to the categorization. This can be helped by configuring your task management software (things like Jira and TFS) to have custom form fields, workflows, and icons. For example, if a field is relevant to one ticket type but not another, hide it for the latter.
You can also help this process of separation by asking the question, “are we using the right task type?”. Whether you ask yourself only or the whole team, frequently asking the question is all it takes to break bad habits and get some consistency.
It may not feel like it will make much difference, but it will trust me.
