BES Playbook

Back to Phase 2: Conceptual Design

3.4.2.2 Story Writing

Story writing is the process of breaking down a feature or group of features that are to be built into discrete, achieveable implementation tasks. In Agile terminology, a story may be also called a Product Backlog Item. The term “story” is frequently used, however, because of the important notion that these implementation tasks be oriented around the user and achieving value for the user. Thus, the task is very loosely written in the format of a “story” of which the target user is the main character. Use cases are ideal building blocks for stories. The user’s need becomes the focus of the story. The sequence of actions, and the system functionality necessary to support those actions, form the basis for the story’s acceptance criteria.

Product/output

A typical user story starts with a statement in the format of “As a [user type], I need [functionality] so that [goal/task to be accomplished].”

From there, additional description can be included, as well as any already defined requirements, conceptual designs for fulfilling the identified user need, and known technological leverage or constraint.

As the story matures as is prepped for execution, complete requirements, in the form of acceptance criteria, should be captured and included. These acceptance criteria should form the basis for later quality assurance, including acceptance testing.

Practical considerations

  • Stories are best written and reviewed by the entire team, across disciplines.
  • Stories can be split into experience-led and technology-led versions if implementation efficiencies will be gained by doing so.
  • Initially, the story should have little clarity around how the need it raises will be fulfilled. In other words, the story identifies the problem, but not its solution.

Resources