I’ve written previously about user stories, and I have compared them to other requirements techniques. Since then I’ve used them and seen them used in many new ways, some successful and some less so. I also often see people asking how to best use them, create them, develop them, size them and so on. I decided to dedicate a short series of blog posts to user stories.
The first, this one, will discuss common misunderstandings. Please at least skim it before reading the rest! After this post, I will provide some guidance on how to get the most out of user stories. The last in the series will discuss a very common question – how big is a user story?
But first, lets get some very common misconceptions about user stories out of the way.
Myth: If you’re doing Agile/Scrum/Insert framework here, you must use user stories
This is 100% false. If you don’t believe me, take it from the experts.
The Scrum Guide, the definitive handbook on what Scrum is and isn’t, written and maintained by the founders of Scrum, Ken Schwaber and Jeff Sutherland, does not use the term user story once. Instead it refers to Product Backlog Items, which include “all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.” This absence is intentional. Ken and Jeff want you to choose what works best for you.
Mike Cohn, a prolific and well respected writer and consultant on Scrum, writes “product backlog items can be whatever the team desires.” He has also written about using Feature Driven Development within Scrum, where the backlog items are written using a format that doesn’t mention a user at all.
User stories have emerged as the most popular format for product backlog items for good reason – they’re easily maintained, require little up front investment, can be thrown away if they become irrelevant, can be improved incrementally and they can be written by anyone. However, they don’t work in all situations. I recommend trying them before trying something else, but we’re free to find whatever technique fits our team and product best.
Myth: User stories must be written like this __
There are at least two problems with this belief. First of all, there isn’t a single agreed upon structure for user stories. People have proposed and use a number of different user story templates or structures.
Mike Cohn recommends the following, which is based on what was used by Connextra and is the format most often referred to:
As a (User) I want (action) so that I can (value given).
There is a common variation on this template, where the “why” is placed at the start of the story. Some people find this helps with prioritization.
In order to (value) as a (role) I want to (action).
And then there is the 5W format, where you try to answer Who, When, Where, What and Why in the story
As (who, when, where) I want (what, why)
The second problem with this is the idea that it assumes that the written form of the user story is the important part. The structure of the user story is not really important because the written user story should not be used to specify the need; it should act as a placeholder. The details should come out in discussions, and if needed the details are recorded in other formats. I emphasize if needed here because those of us with a traditional development background have a knee-jerk response that everything must be written and diagrammed in detail. User stories and Agile challenge this instinct due to the waste it can create.
If you, your team or your organisation are new to user stories, I do recommend that you stick to one of these templates. It’s a good place to start, but remember that templates and structures are only guides. If it isn’t working, try something else!
Myth: Everything in your backlog must be written as a user story
Part of the benefit of user stories is that focusing on the user and the goal is a useful exercise in fleshing out and understanding the need. However, this exercise is useless overhead in some situations. Bugs, UI tweaks, updates to underlying technologies and so on often don’t benefit much from being written or communicated from the user’s perspective. Some examples:
- Patches, updates and configuration tasks
- “As a security conscious user I want the system to have the most up-to-date version of WordPress so that I can feel certain that my experience is secure.” While this may be true to some extent, are you going to write this every month when you update? Is that providing important context? It also confuses things a bit – should we be informing users somewhere of the WordPress version?
- Small UI changes:
- “As the branding department, I want the links on the page to be changed to #668B8B to match the new brand colours.” Again, is writing it like this providing more context than simply saying “Update link colours according to the attached branding spec?” I will admit to writing something like “As the Product Owner for the web I want the header colours to match the branding document so the brand director will stop nagging me,” but that was an attempt at humour.
- In most cases, (but not all) writing a bug as a user story ends up being some variation of “As a user I want this to work because it’s broken.” It’s far more valuable to write the conditions needed to reproduce the problem, the expected behaviour, and add a screenshot. It can be valuable to link to the original user story for the feature if you feel it provides context
In summary, while user stories are a great technique, keep the following things in mind:
- They’re not the only technique
- They don’t work for everything
- They should be treated as an exercise, not a specification. The conversations around the story are the valuable part, not the text on the card
- Feel free to experiment as you and your team become more comfortable with user stories and Scrum