Write User Stories

(Activity) for Tier: Release

View Training

PURPOSE

The purpose of writing user stories is to shift the focus from writing about requirements to talking about them. It fosters a series of conversations that lead to a shared understanding.

A good user story is succinct and adheres to the INVEST criteria. Independent, not overlapping in concept and can be developed in any order. Negotiable, the details can be worked out during development. Valuable to the user or customer and vertically sliced across architectural layers. Estimable, within a reasonable aproxiapproximation to assist with ranking. Small, less than a few person-weeks. Testable, understood enough to verify.

WHEN

Continuously

PARTICIPATING ROLES

• ACCOUNTABLE

  • Product Owner

• RESPONSIBLE

  • Business Analyst
  • User Experience Architect
  • User Education Specialist
  • Solution Architect
  • Developer
  • Tester

INPUTS

• Feature

ENTRY CRITERIA

• A Stakeholder’s need has been identified

SUB-ACTIVITIES

1. Draft the User Stories

   • Analyze a Feature to decompose it into draft user stories. Each story should start with a title and minimum acceptance criteria, so that the scope of the story is clear.

   • Ensure the user stories are linked to the Feature.

   • Write the story statement in the Description field to include:

     • The role/actor who wants the functionality.
     • The functionality the system needs to provide, preferably from the user’s perspective.
     • The perceived value of the new functionality.

2. Elaborate the Acceptance Criteria

   • Elaborate on the acceptance criteria to include anything the customer or team considers a “Condition of Satisfaction” for the story. Consider:

     • Expected functionality
     • Design elements conceived during user experience design
     • Architectural constraints

3. Breakdown User Stories into smaller slices

   • Continuously break down the stories into the smallest vertical slices that still deliver value and can be developed independently of other user stories.
   • Isolate stories that require specific design or technical attention. This helps prevent technical debt resulting from design gaps emerging during the sprint.
   • Analyze each acceptance criteria statement to determine if it can be it’s own user story.

   Note

   Smaller stories are easier to estimate with less variance and result in smaller cycle times.

4. Evaluate User Stories

   • Meet with smaller groups of stakeholders to evaluate the story for refinement readiness in order to optimize the team’s time.

OUTPUTS

• User Stories

Exit Criteria

• User Stories ready for backlog refinement by the team

Next Activity

• Refine Product Backlog

See Also

Process Guidance Version: 10.4