The Definition of Ready (DoR) describes the minimum set of criteria that must be fulfilled before a story is declared "good enough" / ready to be included and worked upon in an upcoming sprint.
- The backlog item has a concise title, phrased using active verbs, avoiding technical terms
- A User Story
- is written in its typical narrative-like form
As [kind of user] I want [some feature] so that [some benefit] - has Acceptance Criteria (AC) that are testable and fully understood by the team; they
- may cover related functional requirements or cross-cutting concerns
(e.g. edge cases, error handling, empty states, loading states) - may include technical decisions
(e.g. architecture, use of libraries, major implementation details) - may define non-functional requirements
(e.g. security, performance, accessibility, configuration, observability)
- may cover related functional requirements or cross-cutting concerns
- is written in its typical narrative-like form
- A Bug
- details expected state vs. actual state
- offers a step-by-step guide on how to reproduce the issue
- includes environment details
(e.g. physical device, operating system, browser) - may have additional assets attached
(e.g. screenshots, videos)
- A Task ... should not exist
- The team has a good idea about how to present the backlog item deliverables, to the extend possible
(e.g. Sprint Review, presentation to non-technical people such as management) - The backlog item has been discussed and estimated by the team, and the estimation is not in the double-digits (8 points or lower)
(an estimation is a combination of effort and complexity, plus risks) - The backlog item is not blocked by another backlog item or external dependency, or the blocker is assumed to be resolved within the same Sprint
- If applicable, the backlog item has relevant or necessary files attached to it
(e.g. screenshots, design mockups / wireframes, documents) - If applicable, the backlog item contains information regarding external dependencies
(e.g. links, attached files, other stories) - If applicable, the backlog item contains information about external people taking part in that backlog item
(e.g. name, role and contact information for each person)
Tip: Print this and take it with you as an actual checklist into refinements :)
The Definition of Done (DoD) describes the conditions that must be satisfied before the teams deliverables (e.g. next iteration of the product) can be considered fit for release / "done".
- All Acceptance Criteria (AC) are met
(e.g. functional test is performed, no known defects exist, no regressions are introduced) - The code is checked into Git, and is part of the primary development branch
(e.g. relevant feature / bugfix branches are merged via PRs, stale branches are deleted) - The code is tested, and tests are successfully executed as part of a CI/CD pipeline
(e.g. unit tests, integration tests, end-to-end tests, security tests) - The code follows agreed upon best practices and conventions, and linters are successfully executed as part of a CI/CD pipeline
(e.g. linting rules, code formatting, PR reviews) - The code has been reviewed by at least one team member other than its creator (four-eyes principle)
(e.g. PR reviews, presentation to co-workers, pair / mob programing) - If applicable, documentation exists and is up-to-date
(e.g. in-code / generated documentation, README file, Swagger documentation, Postman collection, Confluence page) - If applicable, deliverables are deployed to a test environment
- If applicable, follow-up backlog items are created
(e.g. next iteration, performance enhancements, visual improcements, refactoring needs / technical debt)
Tip: Verify a backlog item has reached DoD levels before passing it on to testers and POs :)
As a user
I want to have some feature
so that I have some benefit.
Acceptance Criteria
- Criteria 1
- Criteria 2
- Criteria 3
Notes
- Details 1
- Details 2
Expected
When I ...
Actual
When I ...
Steps to reproduce
- Step 1
- Step 2
- Step 3
Environment
- OS:
- Browser:
Notes
- Details 1
- Details 2