User Story

Why

A user story[1] describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?

Prepare for success

A user story is actionable when:

  • It’s in line with the product vision, and contributes to the goal of the project.
  • The team understands the intention
  • The acceptance criteria are clear. These are any functional and non-functional requirements that are specific for this story. More generic requirements are captured in the overall Definition of Done[2].
  • It follows the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable
  • The team estimated the story points

How

User Stories are written from the perspective of the end user of the product (as if the product can already be used like that). However, it is not about the writing, it is about talking about it (telling the story): stakeholders, Product Owner and the team. Backlog Refinement plays an important role in the use of user stories. This is where the stories come to life for the Development Team.

Typically a user story is written in the format: As a [type of user], I want [some goal] so that [some reason]

Within the user stories you can specify the intention by the following template:

Given I see the question “Wat wil je versturen?” in the chat Then I see the option “Pakket binnen Nederland (see image below)” When I select this option Then I see that I answered: “Pakket binnen Nederland, Max 20 kg en max 80 x 50 x 35 cm” in the Chat history as a message from me

Definition of Done

  • The goal of the story is achieved
  • Acceptance criteria are met
  • Automated tests have been added and/or adjusted
  • Code has been checked in and reviewed
  • Deployed on a test environment
  • Tested
  • CI is green
  • Product Owner[3] (and/or key stakeholder) tested & accepted
  • Ready for release This is a common Definition of Done (DoD). The PO & team are free to adjust it to accommodate their way of working.

Real Life Example

One of the user stories for the epic[4] “online address book” was described as: “In order to simplify address selection, as a user I want to see search results from the online address book”. During backlog refinement[5] the user story was discussed with the development team, and based on their questions and remarks, the following acceptance criteria were defined:

  • Search only at beginning of a field, as this is the similar behaviour as most other address book applications.
  • When found in first name or last name show only the name .
  • We do not mix online address book results and results from the phone’s address book.

Notes

  1. User Story - A user story describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?
  2. Definition of Done - A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.
  3. Product Owner - The Product Owner plays a crucial role in the development of a great software product. He or she is responsilble for maintaining the Product Backlog.
  4. Epic - An epic is a means to describe a larger user goal or business goal, that will be further developed in multiple user stories. Linking the user stories to the epic, gives insight in the context and progress of the epic. Epics are used to make a high level planning.
  5. Backlog Refinement - The goal of Backlog Refinement is to be prepared for the upcoming sprints.