Overview

Everything on the Kanban board starts in the backlog as a story.

A good Agile story typically describes who it is for, what they need, and why — with clear acceptance criteria. Exactly how we achieve that is for the team to interpret, and this area often accounts for a large share of our retrospective discussion. We iterate and adapt these principles as we learn.

Principles

Currently, our principles for writing and working with stories are:

  1. Every story should be deployable upon completion
  2. Acceptance criteria should be independent of other stories
  3. Development should tackle the story, not the big picture
  4. Focus on delivering a single benefit to the end user
  5. Stories should be small chunks of work solving a single problem
  6. Acceptance criteria should be written in the Gherkin language
  7. Develop the solution for the story as fast as possible: commit, review, refactor, repeat

Acceptance criteria (Gherkin)

Write criteria so they can be verified without depending on another story being done first. Prefer clear Given / When / Then scenarios that describe behaviour from the user’s point of view.

Related