User needs or user stories?

User stories describe specific features a team must deliver to meet a user need.

User stories are generally written with additional information, such as acceptance criteria, complexity, and dependencies. You should always be able to map a user story back to user needs.

User needs and user stories often use the same format, which is not helpful for a new learner! However, it is possible to tell the difference due to the additional information and the focus.

User needs are high level, which means they are more general and should emerge naturally from the research data. User stories are low level, which means they are more specific and may sometimes refer to features or solutions, but only in certain instances.

For example, a user story could mention a solution when a service is nearing completion and it makes sense to refer to things that have already been built. User needs should never mention solutions. User stories should always have some connection to your research data, even if the connection becomes a little less obvious.

Individual but related stories can be organised together into ‘epics’. This allows big, complex bits of work to be split up into discrete chunks while ensuring individual stories/tasks are clearly defined and achievable and allowing different parts of the team to work on different stories.

User stories are mostly used to track work, so tend to be more granular and have acceptance criteria attached. This allows your team to take evidence-based but achievable actions based on the research findings.

Acceptance criteria

Acceptance criteria are statements used for evaluating when a piece of work can be considered complete.

Every product or service feature has a unique user story, so every feature has its own acceptance criteria. These always go together.

As statements of things that must be true before the piece of work can be considered complete, acceptance criteria must be written before work begins on the product in a way that will allow your team to test them. This is often as a list of statements that begin with the phrase ‘it’s done when.’

As the criteria are derived from the user story, this will let you see if you have met the user need or not.

Acceptance criteria are helpful because they provide clarity around when a piece of work will be considered done. This can decrease uncertainty and help control the scope of the work.

Let’s look at a simple example – setting the table for dinner. A user story for this example could be:

As a dinner host, I need to set the table, so that my guests are able to eat the dinner I have made for them

The acceptance criteria linked to this story could be:

It’s done when…

• there are plates on the table
• there is cutlery on the table
• there are glasses on the table

Task

Using the same tasks you used for your user needs statements in step 1.14, try to refine your user needs into some user stories with acceptance criteria.

Share your stories and discuss with other learners in the comments below.