Feature Readiness Assessment
Overview: Feature readiness assessment is a critical process in SAFe that ensures features are properly prepared before they move to implementation. This guide covers the assessment criteria, process, and tools for evaluating feature readiness.
What is Feature Readiness?
Feature readiness refers to the state where a feature has all necessary requirements, acceptance criteria, dependencies, and resources in place to begin development. A ready feature reduces uncertainty, minimizes rework, and increases the likelihood of successful delivery.
Key Benefits
- Reduced Development Risk: Clear requirements and acceptance criteria minimize misunderstandings
- Improved Estimation: Well-defined features enable more accurate sizing and planning
- Better Resource Allocation: Understanding dependencies helps optimize team assignments
- Quality Assurance: Clear acceptance criteria support better testing strategies
Feature Readiness Criteria
Definition of Ready (DoR) Checklist
- Business Value: Clear articulation of business value and success metrics
- Acceptance Criteria: Well-defined, testable acceptance criteria
- Dependencies: All dependencies identified and managed
- Size Estimation: Feature appropriately sized (not too large for a single PI)
- User Stories: Key user stories identified and prioritized
- Technical Feasibility: Technical approach validated
- Resource Availability: Required skills and resources available
- Compliance Requirements: Regulatory and compliance needs identified
Readiness Assessment Matrix
| Criteria | Ready | Needs Work | Not Ready |
|---|---|---|---|
| Business Value | Clear ROI, metrics defined | Value stated, metrics unclear | No clear business case |
| Acceptance Criteria | Specific, measurable, testable | Generally defined, needs details | Vague or missing |
| Dependencies | All identified and planned | Most identified, some unclear | Major dependencies unknown |
| Technical Design | Architecture reviewed, approach clear | High-level design, details needed | No technical analysis |
| Team Capacity | Team available, skills matched | Team identified, capacity questions | No team assignment |
Assessment Process
Pre-PI Planning Assessment
- Feature Review Session: Product Manager presents feature to stakeholders
- Technical Feasibility Review: System Architect evaluates technical approach
- Dependency Analysis: Identify and map all feature dependencies
- Resource Assessment: Verify team availability and skill alignment
- Risk Evaluation: Identify and assess potential risks
- Readiness Scoring: Apply scoring criteria to determine readiness level
Readiness Scoring System
Ready Score = (Business Value + Acceptance Criteria + Dependencies + Technical Design + Team Capacity) / 5
Scoring:
3 = Ready (Green)
2 = Needs Work (Yellow)
1 = Not Ready (Red)
Overall Readiness:
2.5-3.0 = Feature Ready for PI Planning
2.0-2.4 = Feature Needs Minor Adjustments
1.0-1.9 = Feature Not Ready, Requires Significant Work
Common Readiness Issues
Typical Problems and Solutions
| Issue | Impact | Solution |
|---|---|---|
| Vague Requirements | Scope creep, rework | Conduct user story mapping sessions |
| Missing Dependencies | Delays, integration issues | Comprehensive dependency mapping |
| Technical Unknowns | Implementation delays | Spike stories for investigation |
| Resource Conflicts | Capacity constraints | Early resource planning and allocation |
| Unclear Success Metrics | Difficult to validate completion | Define measurable acceptance criteria |
Tools and Templates
Feature Readiness Assessment Template
Feature Name: [Feature Title]
Epic: [Parent Epic]
PI Target: [Target Program Increment]
Assessment Date: [Date]
Assessor: [Product Manager/Owner]
Epic: [Parent Epic]
PI Target: [Target Program Increment]
Assessment Date: [Date]
Assessor: [Product Manager/Owner]
Assessment Categories
- Business Value (Score: ___/3)
- Business case clearly articulated
- Success metrics defined
- Stakeholder alignment confirmed
- Acceptance Criteria (Score: ___/3)
- Functional requirements specified
- Non-functional requirements identified
- Test scenarios outlined
- Dependencies (Score: ___/3)
- Internal dependencies mapped
- External dependencies identified
- Dependency timeline confirmed
Best Practices
For Product Managers
- Start feature refinement early, well before PI Planning
- Engage technical teams in feasibility discussions
- Maintain regular communication with dependency providers
- Document all assumptions and validate them
- Keep feature scope focused and achievable within a single PI
For System Architects
- Review features for technical feasibility early
- Identify potential technical risks and mitigation strategies
- Ensure architectural alignment across features
- Validate that proposed solutions align with technology roadmap
For Scrum Masters/RTEs
- Facilitate readiness assessment sessions
- Track and communicate readiness status
- Help teams identify and resolve readiness blockers
- Ensure assessment criteria are consistently applied
Integration with PI Planning
Pre-PI Planning: Only features that meet readiness criteria should be considered for the upcoming PI. This ensures teams can make realistic commitments during PI Planning.
Readiness Review Timeline
- 8-10 weeks before PI Planning: Initial feature assessment
- 6-8 weeks before PI Planning: Dependency resolution
- 4-6 weeks before PI Planning: Technical feasibility validation
- 2-4 weeks before PI Planning: Final readiness confirmation
- 1 week before PI Planning: Readiness communication to teams
Measuring Success
Key Metrics
- Feature Completion Rate: Percentage of features completed within the planned PI
- Scope Change Rate: Frequency of major scope changes during implementation
- Dependency Resolution Time: Average time to resolve feature dependencies
- Readiness Assessment Accuracy: Correlation between readiness scores and actual delivery
Continuous Improvement
Regular retrospectives on the readiness assessment process help teams improve their ability to evaluate and prepare features. Consider adjusting criteria based on lessons learned from previous PIs.