Checklists
Definition of Ready
Criteria that must be met before work can begin
The Definition of Ready (DoR) defines criteria that user stories or work items must meet before they can be brought into a sprint. It ensures that work is well-defined, understood, and can be completed within the sprint.
Purpose of Definition of Ready
| Benefit | Description |
|---|---|
| Clarity | Team understands what they're building |
| Reduced Rework | Fewer mid-sprint scope changes |
| Better Estimates | Clear requirements enable accurate sizing |
| Efficiency | Less time blocked waiting for information |
| Quality | Requirements issues caught before coding |
User Story Definition of Ready
Requirements Complete
- User story follows format: "As a [user], I want [goal], so that [benefit]"
- Acceptance criteria are defined and testable
- Story is independent (minimal dependencies on other stories)
- Story is small enough to complete in one sprint
- Business value is clear and understood
Design Clarity
- Technical approach discussed and agreed
- UI/UX designs available (if applicable)
- API contracts defined (if applicable)
- Data model changes identified
- Integration points documented
Dependencies Resolved
- External dependencies identified and scheduled
- Blocked items have resolution path
- Third-party services or APIs available
- Test environment requirements met
- Access and permissions in place
Estimated
- Story points or time estimate assigned
- Estimate validated by implementing developers
- Risks identified and factored into estimate
INVEST Criteria
Stories should be evaluated against INVEST principles:
Acceptance Criteria Guidelines
Format Options
Given/When/Then (BDD Style)
Given I am a logged-in user
And I have items in my shopping cart
When I click the "Checkout" button
Then I should be redirected to the payment page
And my cart items should be displayedChecklist Style
- [ ] User can view cart summary before checkout
- [ ] System validates inventory availability
- [ ] User receives confirmation email after purchase
- [ ] Order appears in user's order historyQuality Criteria for Acceptance Criteria
| Quality | Description | Example |
|---|---|---|
| Specific | No ambiguous terms | "within 2 seconds" not "quickly" |
| Measurable | Can be objectively verified | "3 items per page" not "reasonable amount" |
| Testable | Can create test cases from it | Clear pass/fail criteria |
| Complete | Covers all scenarios | Happy path, errors, edge cases |
Backlog Refinement Checklist
Before sprint planning, verify during refinement:
┌─────────────────────────────────────────────────────────────────────────────┐
│ BACKLOG REFINEMENT CHECKLIST │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ STORY QUALITY │
│ □ Story describes a user need or business outcome │
│ □ "Why" is clear (business value articulated) │
│ □ Scope is well-defined (what's in/out) │
│ □ Assumptions documented │
│ │
│ ACCEPTANCE CRITERIA │
│ □ At least 3 acceptance criteria defined │
│ □ Criteria cover happy path │
│ □ Criteria cover error cases │
│ □ Criteria cover edge cases │
│ □ Non-functional requirements specified │
│ │
│ TECHNICAL READINESS │
│ □ Technical approach discussed with team │
│ □ Architecture questions answered │
│ □ Security implications considered │
│ □ Performance requirements defined │
│ │
│ DEPENDENCIES │
│ □ External dependencies listed │
│ □ Internal dependencies (other stories) noted │
│ □ Team members with required expertise available │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Story Ready Examples
Ready Story
## User Story: US-1234
**As a** registered customer
**I want to** reset my password via email
**So that** I can regain access to my account if I forget my password
### Acceptance Criteria
1. Given I am on the login page
When I click "Forgot Password"
Then I should see a form to enter my email
2. Given I enter a registered email address
When I submit the reset request
Then I should receive an email within 5 minutes
And the email should contain a reset link valid for 24 hours
3. Given I click the reset link
When I enter a new password meeting complexity requirements
Then my password should be updated
And I should be redirected to login
4. Given the reset link has expired
When I try to use it
Then I should see an error message
And be prompted to request a new link
### Technical Notes
- Use existing email service (SendGrid)
- Reset tokens stored in Redis with 24hr TTL
- Password requirements: 8+ chars, upper, lower, number
### Estimate: 5 pointsNOT Ready Story (Needs Refinement)
## User Story: US-5678
**As a** user
**I want to** manage my notifications
**So that** I get relevant updates
### Acceptance Criteria
- Users can change notification settings
### Notes
- TBD: What types of notifications?
- TBD: Email, push, in-app?
- TBD: What are the default settings?
- Design not available
### Estimate: ???Sprint Planning Gate
Stories must meet DoR before being accepted into sprint:
| Gate Check | Question | Must Have |
|---|---|---|
| Clarity | Does team understand what to build? | Yes |
| Testable | Can we write test cases? | Yes |
| Estimated | Do we have a confident estimate? | Yes |
| Sized | Can it be done in one sprint? | Yes |
| Dependencies | Are blockers resolved? | Yes |
When Stories Aren't Ready
Options
- Spike First: Create a time-boxed research task
- Split Story: Break into smaller, ready pieces
- Defer: Move to future sprint when ready
- Accept Risk: Pull in with documented gaps (avoid if possible)
Spike Template
## Spike: Research notification architecture
**Goal**: Determine technical approach for notification system
**Time-box**: 4 hours
**Questions to Answer**:
1. What notification channels do we need?
2. What's the best delivery mechanism for each?
3. How will we handle notification preferences?
4. What infrastructure is needed?
**Output**: Technical design document enabling US-5678 refinementRelated Resources
Compliance
This section fulfills ISO 13485 requirements for design inputs (7.3.3) and planning of product realization (7.1), and ISO 27001 requirements for application security requirements (A.8.26) and information security in project management (A.5.8).
How is this guide?
Last updated on