User stories are a great way to manage requirements, they are small, light, to the point and make the benefit of any requirement explicit.
However, just like traditional requirements, there is a skill required to ‘get them right’.
Below is a quick hash up of some user story mistakes.
The Acceptance Criteria
The acceptance criteria is a key aspect of any user story. They provide a reassurance that whatever gets delivered is what was originally intended.
Some of the more common mistakes are:
- Acceptance criteria that doesn’t actually prove that the ‘want’ has been delivered.
- Too complex
Each should answer “yes or no”, not “yes and no”). - Too low level (remember this is the ‘what’, not the ‘how’).
Think about the output, as opposed to how the tester will get to that output. - Too much detail
e.g. better to say “does the page allow the user to enter their address details as per the address capture business rules”.
than to have a separate rule for “can the user enter their town”/”can the user enter their postcode”/etc
The User
It’s all to common to see the user of a user story being labelled as “user”. This is way too generic, and points to the writer lacking an understanding of who will actually gain benefit from the story. If we can’t identify who the user is, are we even sure the change will benefit anyone?
Sometimes the change may benefit a group of users, instead of writing the same story for each of them, it may be beneficial to understand the role each type of user is playing when they get the benefit. If this role ends up being the same, say that. Use the role in the user story (but highlight separately who may be performing this role). If the users are not playing the same role, then double check that they are actually getting the same benefit. You might find that in fact a single change helps different users in different ways, and in this scenario it’s probably best to highlight this into different user stories.
Another common mistake is having the product owner as a user, but the benefit being given from the perspective of another user. The user having the ‘want’ should always be the user getting benefit from that ‘want’.
It’s also quite common to see the user being a developer, for example a change being required that doesn’t seem to deliver user benefit, but may be required to reduce technical debt, etc. I’d argue that this type of change shouldn’t be represented as a user story (is this really the what? Or is it the how?). If we really think about why the technical change is required, there may actually be end user benefit, for example it may result in a certain aspect of the system running faster, or allowing more concurrent actions etc.
The Want
The goal of a story is to define the ‘want’. It’s a single, small feature that a specific user wants in order to give them some type of benefit. Some of the pitfalls are:
- Too ambiguous.
If the want is ambiguous, then what gets delivered turns into a lottery. The business user expects one thing, the developer delivers something else, while the tester tests for something entirely different. - Too complex.
The want should be a single piece of functionality. Using words like ‘and’ adds unneeded complexity to a user story that make meeting that story more difficult.
There is little reason why you shouldn’t split a complex story into multiple smaller stories. - Too technical.
A common issue for all type of requirement. Requirements are the ‘what’, not the ‘how’.
The user story defines what the software should do, how the software actually does that is the domain of the designer/developer. The business or end user has little interest in the latter.
User stories (like much in the BA world) are not black and white, there are always exceptions to the rule, the key is making sure they stay exceptions, and not end up being the de-facto.