Last updated on January 7, 2020
User needs and user stories refer to different things in Agile development. Because they are written in the same format [As a (type of user), I want (some goal), so that (reason/outcome)], it is not surprising they can confuse many. Furthermore, in design, user stories are referred to a detailed fictional description of how the user is currently carrying out the activity, and therefore used in a similar way that personas are used to represent the user research findings. Hence, I’m sharing below my understanding of the differences between user stories and user needs in Agile development. I’d love to hear what you think, especially if you disagree.
- User needs are high level needs, broad in scope and timeless
- User needs are the primary outcome of discovery (in-depth) user research
- User needs do not suggest a specific solution
- User needs are normally written by the user researcher in the team
Example of user need: As a user researcher, I want to help my team learn about users so we can make a better service.
- A user need (which is not solution-specific) can be broken down into a list of user stories, which is solution specific.
- User stories describe functionality, product increment(s) or the feature desired from the point of view of the user, and these will be valuable to the user. They replace traditional ‘requirements’ in waterfall projects.
- User stories are written by the design/dev. team led by the product owner, and not normally by the user researcher as user researchers’ job is not to specify solutions, rather present user needs and insights.
- User stories can be created from analytics, user feedback and hypothesis, not just from user research, and then validated with subsequent user research.
- User stories gain detail over time and are split into epics (see below) if they are too big
- The purpose of user stories is for the team to write stories together to build a shared understanding of what needs to be built. They are therefore called stories for the way they should be used, and not for the way they should be written.
- The goal of the user story is the most important part to ensure we are solving the right problem, and we know when the user story has fulfilled its goal.
- User stories also specify the “acceptance tests” (i.e. outcomes) used to check/test whether the product increment(s) or new feature has met the goal we set out to fulfil. They can be written as a list that starts with “it’s done when…” or in other formats such as:
- With scenarios, e.g. Given [context], When [event], Then [outcome] (more here)
- We believe that <this capability>, Will result in <this outcome>, We will know we have succeeded when <we see a measurable signal> (more here)
- Out of all people who <action> (population), How many <action> (numerator), Per <observation> (denominator) (more here)
- The user story or its related description should have sufficient information to make test development possible.
Example of user story: As a user researcher, I want to display the user research insights on Trello so the team always has access to user research findings to make improvements. Acceptance test: It’s done when all the team can access and see all the user research insights on Trello
Epics are large user stories that would normally take more than a few weeks to develop and test. Epics should be split into smaller user stories.
Any thoughts/feedback? Please share below or on Twitter (@DrSalmaPatel)