How To Structure A User Story

As my last post was about how to write good User Stories, this post is about good structures for them. When developing products that require several team and stakeholders to collaborate, it is beneficial to have a common User Story structure so that everyone can focus on the product instead of struggling with information and requirements about it. With all the points below please remember that a User Story should be a place holder for conversations. So avoid adding all details and take away room for negotiation and conversation.

Goal – Story – Narrative

This is the most essential part as it actually is the User Story. The narrative contains that actual target user, the goal and the value it will to deliver, once it is implemented. The User Story is told in the following form:
As a <user>
I want <goal>
So that <value>

Acceptance Criteria

Besides the story itself (as described above) the second essential part of an User Story are the Acceptance Criteria. Acceptance Criteria in the end determine when we have successfully turned a User Story into a product increment. They serves as a shared understanding of when a User Story is done and should describe the desired features of the product. Properly defined Acceptance Criteria are basis for test scenarios, furthermore they could actually be written in scenario
form such as:
Given <initial situation>
When <event>
Then <outcome>

Working with scenarios in Acceptance Criteria requires some experience and discipline in order to avoid writing too many scenarios and potentially stating what’s clear to everyone. The number of Acceptance Criteria shouldn’t exceed five, otherwise this is a hint that the User Story could potentially be broken down further.

Background

Some background information is useful, though not mandatory when it comes to implementation to the user story. In order to involve people I recommend including some background information, such as:

• Why do we develop this story?
• What product/feature does it belong to?
• What is the current situation, that it is built upon?

–

Further points that could be mentioned in a User Story respecting that it remains a place holder for conversations are listed below. I personally wouldn’t recommend to add all of these details in each User Story rather than adding it when it is actually useful on a case by case basis.

• demarcation in scope/not in scope
• constraints (resource limitations, laws, etc.)
• non-functional requirements (performance targets, etc.)
• designs & concepts
• wireframes
• notes