How to write a User Story

Eine Zusammenfassung die ich in einem meiner Projekte benutzt habe um Product Owner zu coachen. Natürlich geht sie auf die dortigen Besonderheiten ein, weshalb manche Aspekte besonders betont werden. Bemerkenswert ist aber nicht nur was darin steht, sondern auch was nicht - beispielsweise wird kaum darauf eingegangen wie Stories geschnitten werden. Auch das sagt etwas über dieses Projekt aus.

What is a story about?

• A Story is a requirement for a small feature that can be implemented within one two-week-sprint.
• A Story describes a complete, working, testable feature (no separation in frontend/backend).
• A Story does not describe the current state of the application in detail.
• A Story does not describe what is planned for future sprints.
• A Story tells the development team what to implement, not how.

The Structure:

• A Card of roughly Din A 6-size is what classic User Stories are written on (meanwhile digital tools like Redmine or Jira are common as well).
• A Title is written on the front side (or in the top field of the digital form).
• Acceptance Criteria were originally written on the back of the card (in this project we add them in a mandatory field in our digital tool).
• Additional Information can be written in the description field of the digital tool – the shorter and catchier the better. 
• And keep in mind – the description is a supplement to the Acceptance Criteria, not the other way round.

The Title:

• The classic Title format is: As <Role> I want to <Perform Action> so that <I can have a Business Value>. For example: As a User of my company’s intranet I want to upload a profile picture so that the offshore colleagues can see my face.
• All three parts are important: The Role tells the developers which permissions are required, the Action is the new feature, the Business Value justifies cost and effort of the story. 
• Of course you can choose another format (for example the FDD-Syntax: <action> the <result>  to <object>. Example: Trigger a signal to confirm readiness) but in that case you should name the role and the business value in the description. 

The Acceptance Criteria:

• The Criteria define which actions must be executable before the story is considered done. 
• The Criteria must be testable: not "Performance must be better", but "Pages must load in less than three seconds". 
• It is recommended to put them in If-Then-form if possible: If I upload my profile picture and save it, then users who are logged in can see it on my profile page. 
• It is best practice to create them together with someone from the QA, because they can give you input about the testability.

The Additional Information:

• As said above: the shorter and catchier the better. And the description is a supplement to the Acceptance Criteria, not the other way round. 
• Valuable Information could be: 
• Preconditions (which Story must be finished before we can start this one?) 
• Dependencies (which features/teams might be affected when we work on this component?) 
• Constraints (the new page must be designed according to the company’s CI) 
• Important: Please name Preconditions, Dependencies or Constraints as such. Otherwise the developers might think they are requirements and try to implement them. 

Feasibility and Size of a story:

• Only the development team can say if a story is feasible and estimate it’s size. Thinking about feasibility and size without developers included is nothing more than a waste of time, money and brains. 
• There is a meeting for that, it’s the Backlog Grooming. 
• Stories are estimated in complexity, not in days/hours.

And one last thing: the earlier and the more people are involved in the creation of a story, the better the result.