User stories

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User story basics

User story communicates features for development team:

• Who will need the feature, eg., recruiter using LinkedIn, project stakeholder using InvisionApp or lost driver using Waze.
• What exactly user want to do, eg., search by address on the map, filter candidates for the position, make comments for the design iteration.
• Why the action is necessary, that the team can see a broader context, eg., so that driver can find a way home, recruiter can quickly see top 5 executes for the position or stakeholder can return the work back to designer for further adjustments.

The user story should be open enough, so it does not tell developers exactly how it should be done.

A good user story raises discussions and conversations, which later can be developed in more refined and granulated stories for the sprint planning.

A detailed product backlog item which is ready for the sprint

Elements of a well crafted user story / task / issue / ticket which is ready for development:

1. A good summary line which makes sense without opening the description.
2. A good description which is focused on WHAT and WHY should be done from the users point of view. (If the story requires more tasks, then developers can create them additionally as separate tickets).
3. Acceptance criteria — specific criteria to determine when the story is Done.
4. Optionally: How to test, testing scenarios.
5. Should include a reference to the “Definition of done”, which can be common for the whole component, sprint, project, team etc.
6. Should include the estimate — whether in time or story points (or both), based on the followed practice in the team. This is necessary for sprint planning and monitoring the progress throughout the sprint.
7. It should have a set priority.

“INVEST” criteria for backlog item

Here comes the all time classic which is still true for user stories:

• I — Independent: We want to be able to develop in any sequence.
• N — negotiable: Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
• V — valuable: Users or customers get some value from the story.
• E — estimable: The team must be able to use them for planning.
• S — small enough: Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
• T — testable: Document acceptance criteria, or the definition of done for the story, which lead to test cases.

Readiness for Sprint

• Stories must be small enough to easily be done in the Sprint.
• Preferably each story take 1–3 days to get “Done”
• Teams should take many Stories into each Sprint
• Each Story should be a part of delivered Increment of functionality for the Sprint

Story templates

Typical template used:

• As [user role], I can [do something] in order to [some benefit of purpose.
• [User role] can [do something] so that [some benefit or purpose]

The “can” work can be replaced by “must”, “should” or any other appropriate verb.

Remember, Scrum talks only about “product backlog items” (PBI’s).

User Stories (a practice) are just one way of writing PBIs. There are also other types of items can be placed in the Product Backlog, like, Jobs-To-Be-Done and others: https://medium.com/@zbigniewgecis/8-things-to-use-in-jobs-to-be-done-framework-for-product-development-4ae7c6f3c30b