We are generally massively in favour of the creation of user stories, where real needs of real users are captured in the format ‘As a…, In order to…, I want to…’ for each user type.
But we’ve found that clients will sometimes ask us to ‘turn requirements into user stories’ — something that doesn’t work well.
Because if what you actually want is a way to communicate a solution that has already been agreed, user stories probably aren’t the best way to do it — and here’s why.
What are user stories for?
The real value of user stories is that they convey something that is needed, who needs it, and why.
When we are coming up with solutions for a client, we need to gain as much understanding of their business and user needs as we can. We firmly believe that gathering user stories, ideally in person, is the best way to capture this knowledge and transfer it to the team who are going to be working on the project.
Generally, we find that requirements don’t convey this information very well because they just document a solution; instead of answering ‘who’, ‘what’ and ‘why’, they address only the ‘what’ and ‘how’.
As digital experts, we’re here to suggest the best solutions to meet client needs. And we find that transferring business knowledge to the wider project team via user stories (communicating the ‘who’, ‘what’ and ‘why’) — rather than just presenting them with the ‘what’ and ‘how’ brief — is the best way to arrive at the very best solution.
Another approach: describing solutions
If a solution has already been agreed then turning this back into user stories often feels uncomfortable, and for good reason — that’s not what they were designed for, and so there are better ways to achieve that objective.
At Code, we have found in these cases that it’s actually better to describe the solution through a mix of visual designs and acceptance criteria:
– A sketch, or design or html prototype describes what the solution should look like
– A set of scenarios with examples describes how the solution should behave.
Scenarios captures the acceptance criteria for the solution in the format ‘Given…, When…, Then…’. This should cover anything that you can’t tell from the visual design alone — interactions, back end functionality and edge cases. Some examples include: what is included in lists, how results are sorted, validation for forms, confirmation emails sent, etc.
And the moral is…
The best way to describe needs is with user stories.
The best way to describe solutions is with visual designs, scenarios and examples.
And if what you actually want is for the team to build a specific solution, then acceptance criteria will do a better job than user stories.