Definition of Ready (DoR)

Conformo GDPR Compliance Platform
Version: 2.0
Last Updated: 25 October 2025
Effective From: Sprint 2

Purpose

The Definition of Ready (DoR) ensures that user stories and tasks are sufficiently refined, understood, and prepared before being pulled into a sprint. This reduces ambiguity, minimises rework, and enables the team to deliver high-quality, compliant features efficiently.

Key Principle: The DoR is a living guideline that supports collaboration, not a bureaucratic gate. If a story is not ready, the team works together to make it ready rather than rejecting it outright.

When to Apply

The DoR must be satisfied for:

  • ✅ All user stories before Sprint Planning
  • ✅ Technical tasks and spikes before Sprint Planning
  • ✅ Bug fixes classified as P0 (Critical) or P1 (High)

Definition of Ready Checklist

A user story is considered Ready when ALL of the following criteria are met:

1. Story Structure

  • User Story Format: Written in the format: “As a [user type], I want [goal], so that [benefit]”
  • Title: Clear, concise title that includes story ID (e.g., [8pts] US-010: Italian Privacy Policy Templates)
  • Story Points: Estimated using team’s agreed scale (Fibonacci: 1, 2, 3, 5, 8, 13, 21)
    • ⚠️ Stories >13 points must be split or have detailed sub-task breakdown
  • Priority: Assigned MoSCoW priority (MUST, SHOULD, COULD, WON’T)

2. Acceptance Criteria Completeness 🆕

  • Clear & Testable: All acceptance criteria (AC) have clear pass/fail conditions
  • Test Scenarios Documented: At least one test scenario per acceptance criterion
  • Edge Cases Identified: Error states, validation failures, and boundary conditions specified
  • Accessibility Requirements: WCAG 2.1 Level AA standards specified where applicable
    • Keyboard navigation requirements
    • Screen reader compatibility
    • Colour contrast ratios (minimum 4.5:1 for normal text, 3:1 for large text)
  • Italian Compliance Requirements: GDPR and Garante guidelines identified where applicable
    • Data processing requirements (minimisation, purpose limitation)
    • User consent mechanisms (explicit, granular, withdrawable)
    • Audit logging requirements

3. Legal & Compliance Review Flag 🆕

Required for stories touching:

  • Personal data processing
  • Document generation (privacy policies, cookie policies, etc.)
  • Data subject rights (access, deletion, portability)
  • Cookie/consent management

  • Payment processing

  • GDPR Impact Assessed: Data processing activities identified and lawful basis documented
  • Italian Garante Requirements Checked: Specific Italian DPA guidelines reviewed
  • Data Retention/Deletion Rules Defined: Storage duration and deletion procedures specified
  • Legal Review Scheduled: If story involves legal text generation or high-risk processing, legal review booked

4. Italian Localisation Requirements 🆕

Required for all user-facing features:

  • Italian Translations Identified: All UI text, error messages, emails, and notifications flagged for translation
  • Legal Terminology Validated: Privacy/GDPR terms use correct Italian legal language
    • Example: “trattamento dei dati personali” (data processing), “interessato” (data subject)
  • Date/Number Formatting Specified: Italian locale formatting defined
    • Dates: DD/MM/YYYY
    • Numbers: 1.234,56 (comma decimal separator)
    • Currency: EUR (€) with Italian VAT handling
  • Content Review: If story generates legal documents, Italian content review scheduled

5. Test Data & Environment Readiness 🆕

  • Test Data Scenarios Documented: Realistic test data requirements specified
    • Example: For GDPR assessment, define test scenarios for micro/SME/large businesses
  • Test Environment Configured: Required environments (dev, staging) are available and configured
  • Third-Party Integrations Available: External services (SendGrid, Stripe, etc.) accessible in test environment
  • Test User Accounts Created: User roles (admin, user, guest) provisioned with appropriate permissions

6. Dependencies Mapped ✏️ Strengthened

  • Technical Dependencies Identified: Required APIs, database schemas, libraries, or services documented
  • Story Dependencies: Upstream stories that must be completed first are clearly identified
  • External Dependencies: Third-party integrations, legal reviews, or vendor dependencies noted
  • Blocker Risk Assessed: If dependencies have delivery risk, mitigation plan documented

7. Design & UX Requirements

  • UI/UX Specifications: Wireframes, mockups, or design specifications available (if applicable)
  • Component Library Alignment: Existing UI components identified or new components specified
  • Responsive Design: Mobile, tablet, and desktop breakpoints defined
  • Brand Guidelines: Conformo brand colours, typography, and logo usage specified

8. Performance Criteria 🆕

Required for data-intensive or high-traffic features:

  • Response Time Expectations: Maximum acceptable response times specified
    • Example: “API endpoints must respond within 500ms for 95th percentile”
  • Load Expectations: Concurrent user or transaction volumes defined
    • Example: “Cookie consent banner must handle 1,000 concurrent page loads”
  • Database Query Limits: Query optimisation requirements specified
    • Example: “Compliance dashboard queries must complete within 2 seconds”
  • Scalability Requirements: Growth expectations documented
    • Example: “System must support 10,000 registered users by MVP launch”

9. Security & Data Protection

  • Authentication/Authorisation: Required user roles and permissions defined
  • Data Classification: Sensitivity level of data (public, internal, confidential, restricted) specified
  • Encryption Requirements: Data at rest and in transit encryption specified
  • Input Validation: Validation rules for user inputs defined (prevent SQL injection, XSS, etc.)
  • Audit Logging: Events to be logged specified (who, what, when, where)

10. Documentation Requirements

  • Technical Documentation: API documentation, database schema changes, or architecture decisions documented
  • User Documentation: User-facing help text, tooltips, or guides specified (if needed)
  • Compliance Documentation: Updates to GDPR compliance documentation identified (if applicable)

11. Definition of Done Referenced

  • Team Reviewed DoD: Story creator has reviewed the Definition of Done and confirms story can meet all DoD criteria
  • Test Coverage Target: Minimum test coverage percentage specified (default: 70% for unit tests)

Story Sizing Guidelines

Story Points Complexity Duration Splitting Guidance
1-2 Trivial < 1 day No split needed
3-5 Simple 1-2 days No split needed
8 Moderate 2-3 days Consider splitting if >3 acceptance criteria
13 Complex 3-5 days Split if possible - high risk of scope creep
21+ Very Complex > 1 week MUST split - too large for single sprint

Sprint 2 Example:
US-010 (Italian Privacy Policy Templates) is 21 points. Recommended split:

  • US-010A: Privacy Policy Template Engine (13 points)
  • US-010B: Italian Content & Localisation (8 points)

Priority Definitions (MoSCoW)

  • MUST: Critical for MVP 1.0 launch. Part of the 191-point MVP 1.0 roadmap.
  • SHOULD: Important for MVP 1.1 competitiveness. Part of the 432-point MVP 1.1 roadmap.
  • COULD: Nice-to-have features. Delivered if capacity allows.
  • WON’T: Out of scope for current release. Parked for future consideration.

DoR Review Process

  1. Story Refinement Session: Product Owner + Tech Lead + Team review backlog weekly
  2. Sprint Planning: Scrum Master verifies DoR compliance before story commitment
  3. Continuous Improvement: DoR reviewed and updated quarterly based on retrospective feedback

DoR Violations & Exceptions

What happens if a story doesn’t meet DoR?

  • ❌ Do NOT: Reject the story or block the sprint
  • ✅ DO: Collaborate to make it ready
    • Product Owner clarifies acceptance criteria
    • Tech Lead identifies dependencies
    • Team estimates story points together

Exceptions:

  • Critical Production Bugs (P0): Can bypass DoR to enter sprint immediately
  • Emergency Compliance Issues: Can bypass DoR with Product Owner and Tech Lead approval
  • Spikes/Research Tasks: Reduced DoR (no acceptance criteria required)

DoR for Different Work Item Types

User Stories

✅ Full DoR checklist applies

Bug Fixes

  • P0/P1 Bugs: Require only: Description, Steps to Reproduce, Expected vs Actual, Acceptance Criteria
  • P2/P3 Bugs: Full DoR checklist applies

Technical Tasks

  • Require: Description, Acceptance Criteria, Technical Dependencies, Definition of Done

Spikes

  • Require: Research Question, Time-Box (max 1 day), Success Criteria (deliverable)

Quality Gates Summary

Gate Timing Owner Outcome
Definition of Ready Before Sprint Planning Product Owner + Team Story is ready to be committed
Definition of Done End of Development Developer + QA Story is ready for production
Sprint Acceptance End of Sprint Product Owner Sprint deliverables accepted

Compliance-Specific DoR Additions

For Conformo as a GDPR compliance platform, additional scrutiny is required for:

Document Generation Features (Theme 2)

  • Legal text reviewed by qualified legal professional
  • Italian legal terminology validated by native Italian speaker with legal background
  • Garante Privacy guidelines cross-referenced
  • Document versioning and audit trail specified

Data Subject Rights Features (Theme 3)

  • GDPR Articles 15-22 compliance verified
  • Garante-specific timelines documented (e.g., 30 days for DSAR response)
  • Identity verification mechanism specified
  • Audit trail for all data subject requests specified

Cookie/Consent Management (Theme 3)

  • Italian e-Privacy Directive implementation verified
  • Consent must be: freely given, specific, informed, unambiguous
  • Granular consent options specified (not bundled)
  • Consent withdrawal mechanism specified
  • Consent records retention specified (minimum: duration of processing + statute of limitations)

Supporting Documents

  • Test Strategy Document: Defines testing approach, coverage targets, and quality gates
  • GDPR Compliance Guide: Details GDPR and Italian Garante requirements
  • Code of Conduct for Management Software: Italian DPA guidelines for software developers (Nov 2024)
  • Security & Data Protection Policy: Technical controls and security measures

Version History

Version Date Changes Author
1.0 Sept 2025 Initial Definition of Ready Product Team
2.0 25 Oct 2025 Added: Acceptance Criteria Completeness, Legal & Compliance Review, Italian Localisation, Test Data & Environment Readiness, Performance Criteria. Strengthened: Story Sizing, Dependencies, DoR Violations process. Product Team

Questions or Feedback?

If you have questions about the DoR or suggestions for improvement:

  • Slack: #conformo-product channel
  • Weekly Refinement: Every Wednesday 10:00 CEST
  • Retrospective: End of each sprint

Remember: The DoR exists to help us deliver high-quality, compliant features efficiently. It’s a living guideline that evolves with our team’s needs. When in doubt, collaborate to make stories ready rather than blocking progress.