Fiction can help us here, this time in its form, not its content. It can help us to clarify our own thoughts, help us test our ideas before we build them, and help our teams stay focused on the things that matter.

Resources

On a previous post titled Why We Write Stories I took a light-hearted approach to the value we get from writing stories, in this post I want to write about why we write stories, the components of a story, when we don’t write stories, and how we use stories in our Scrum implementation at Leapfrog.

Components of a Story

Why We Write Stories

Let’s start with “why” we write stories. Stories are a ‘simple’ format to articulate and communicate requests for work; they can also be a placeholder for people to have conversations about work. Stories also provide a common language for folks to align and have an agreed definition of done. They mitigate sticky situations of “that is not what I asked for” or “I forgot to add this to the request.”
Acting Agile does not mean evergreen or daily changing requirements, it means building and delivering software incrementally, reflecting, and learning.
Stories help the team gain a shared understanding of the work and reach a shared definition of “done.” Stories are foundational in estimating and when the team plans work.

Story Titles

The title should describe an activity. Let the story name be the starting point for determining what “done” looks like. Ideally, the story title should describe actual behavior by a person in the system.

Story

As a <person/role>, I want <goal>, so that <reason>. Stories provide us with the person or the role that is making a request, the feature or requirement the business wants, and the problem solved. Stories should encapsulate what the business wants and why it is of value.

Acceptance Criteria

A story is not “done” unless the Acceptance Criteria is met, or the team and Product Owner have agreed that the criteria have changed since the commitment to the story.

Acceptance Criteria Characteristics

  • Set of statements, each with a clear pass/fail result
  • There is no partial acceptance: either a criterion is met, or it is not
  • They must be actionable
  • Criteria should be independent of the implementation
  • Helps the team deliver
  • Helps the team build or implement QA tests
  • Helps the Product Owner perform User Acceptance Testing
  • They are not the technical details or steps for completing a story
  • They are not the equivalent of how the story will progress through User Acceptance Testing

Implementation Details

Some of our teams prefer implementation details for additional details or guidance on delivering the work, but these are always defined and written by the development team. Sometimes they are non-obvious system complications, a sequence of events needed to complete the story or comments from the discussion of the story that the development team needs for reference during development.

When We Do Not Write Stories

When the work is either too small or does not fit into the story format, in those cases, we write Chores/Tasks. “As a <>, I want <>, so that <>. We write chores/tasks because it is work that needs prioritization and visibility and to add to an iteration. It may be a stepping stone to get a story to “done,” or it could be a cleanup task that needs attention.

Chores/Tasks Characteristics

  • Chores/Tasks can include acceptance criteria for clarity
  • Receive zero story point value
  • Typically used for documentation or straight forward work

How We Use Stories in the Technology Team

We use stories to break down work into demonstrable pieces of work that we can then estimate and plan for our teams to deliver valuable software to the business.