Definition of Ready (for development)
Small, independent stories
Encourage small stories and avoid dependencies. Define behavior of Feature Switches. If not possible. List all dependencies explicitly (use Clubhouse linking feature)
Valid: always
Summary defined as user story
The summary should be defined from the point of view of the user of the feature (customer, developer using an API, etc.). E.g.:
As a user I'd like to be able to book a workout 3 weeks in advance so that I can plan my month better
Valid: always
Acceptance criteria
Checklist describing the expectations for considering the task completed, always listed as Tasks on Clubhouse. These could be for example:
Expected behaviors of a feature ("The endpoint should return 404 if an offer is missing")
A request to write and provide specific documentation ("The endpoint should be described in Swagger")
Any dependency/action needed to deploy the feature / unblock another action (e.g. “Feature switch for chat should be turned on on production”, “The changes in ticket 1234 have been deploy to staging”, "Mono-to-user coaches migration has been ran and validated“ etc.)
Valid: always
Steps to reproduce/expected/actual
Clear steps to reproduce a bug, that anyone in the team can easily follow to properly understand the behavior of the problem. E.g.:
Steps to reproduce
1. Go to Homepage
2. Click login
Expected behavior
Page opens
Actual behavior
Browser crashes
Valid: always for bug tickets
Designs & Prototypes
In UI-related tickets, designs should be available as links or as screenshots directly in the ticket. Affected designs should be clearly identifiable in the ticket. ( favor individual screens and highlights of affected parts, avoid sharing all available screens for a feature)
Valid:
when new designs need to be implemented
when existing designs need to be fixed (bug tickets)
Security and permissions
Any specific action that needs to be remarked to ensure that all data and privileges involved in a task are handled correctly.
Examples:
which data is sensitive and what risks should be taken into account (e.g.: GDPR concerns)
which roles should be able to do what (e.g.: admin-only actions, user-restricted features)
any edge cases
Valid: when applicable, especially when feature or bug is applicable to a specific type of user
Link to Epic
If a task is part of a bigger feature, an epic should exist with a description of the broader business case:
What step of the user journey are we affecting
What is the reasoning behind the tickets enclosed
What problem we’re trying to solve
Valid: when more than two related stories exist
User Journey
Add a link to a user journey description (e.g. a Confluence article and/or flow chart) highlighting all technical challenges and solutions
Valid: always
Last updated