HKSM

A curated set of candidate non-functional requirements and constraints intended to be added to the Program Product Backlog and reflected in the Prioritized Product Backlog. These items describe measurable quality attributes such as performance, security, reliability, and compliance that influence ordering, acceptance criteria, and the Definition of Done across teams.

Key Points

• An input to creating and refining the Program Product Backlog and an output from stakeholder analysis, architecture reviews, and compliance discovery.
• Covers cross-cutting quality attributes: performance, security, reliability, usability, accessibility, maintainability, and regulatory compliance.
• Expressed as backlog items, global constraints, or quality criteria that apply across multiple epics and user stories.
• Prioritized by the Program Product Owner using business value, risk reduction, compliance urgency, and cost of delay.
• Shapes the Definition of Done, acceptance criteria, and non-functional test strategy for all participating Scrum Teams.
• Refined during Program-level backlog grooming and Release Planning; implemented through stories, enablers, spikes, and test cases.

Purpose

To ensure program-level quality expectations are explicit, measurable, and visible before and during prioritization. Making non-functional needs transparent early reduces rework, improves consistency across teams, and protects compliance and user experience goals.

These proposals guide ordering decisions and help embed quality attributes into epics and stories, influencing acceptance criteria, Definition of Done, and release gating across the program.

Key Terms & Clauses

• Non-functional requirement (NFR): A quality attribute or constraint describing how the system performs rather than what it does.
• Global acceptance criteria: Cross-cutting conditions that all related stories must satisfy (for example, 99.9% availability).
• Definition of Done (DoD): A shared checklist updated to include relevant non-functional checks and evidence.
• Constraint vs. story: Some NFRs are global constraints; others are implemented as specific backlog items or enablers.
• SLA/SLO: Service level agreement/objective that can serve as a measurable target for performance and reliability.
• Traceability: Links from program-level NFRs to epics, stories, test cases, and compliance evidence.

How to Develop/Evaluate

1. Gather inputs: business case, stakeholder interviews, regulatory standards, security policies, architecture guidelines, production telemetry, and incident trends.
2. Draft proposals: write concise, testable NFR statements with clear metrics (for example, response time, throughput, error rates, RTO/RPO).
3. Structure items: decide whether each proposal is a global constraint, a standalone backlog item, an enabler, or a spike for investigation.
4. Make it measurable: add objective acceptance criteria and target thresholds; avoid vague terms like fast or secure.
5. Size and analyze: use spikes and technical discovery to reduce uncertainty and estimate effort and risk across teams.
6. Review with stakeholders: align with Program Product Owner, Scrum Masters, architects, security, and compliance representatives.
7. Prioritize candidates: order by business value, regulatory urgency, risk reduction, and dependencies affecting epics and releases.
8. Record traceability: link proposals to impacted epics/stories and to planned non-functional tests and evidence artifacts.

How to Use

During Program Backlog creation and refinement, incorporate the proposed non-functional items, update ordering, and adjust the Definition of Done and global acceptance criteria. When planning releases, factor these items into capacity, dependencies, and risk mitigation.

At Sprint Planning, translate applicable NFRs into story-level acceptance criteria and tasks, and include non-functional tests in the sprint backlog. During Reviews and Retrospectives, verify measurable outcomes and update proposals based on feedback and production data.

Example Snippet

• ID: NFR-01, Title: Web response performance, Type: Non-functional. Metric: p95 response time ≤ 2.0 seconds for 1,000 concurrent users. Acceptance: Load test report shows p95 ≤ 2.0 seconds in staging; monitoring alerts configured.
• ID: NFR-02, Title: Data protection at rest, Type: Constraint. Metric: AES-256 encryption for all PII fields. Acceptance: Security scan reports zero unencrypted PII; policy exception list is empty.
• ID: NFR-03, Title: Availability target, Type: Global acceptance criteria. Metric: 99.9% monthly availability. Acceptance: SLO dashboard meets target; incident postmortems completed within 48 hours.

Risks & Tips

• Risk: Vague NFRs without metrics lead to disputes and rework. Tip: Use quantifiable targets and objective tests.
• Risk: Treating NFRs as afterthoughts causes late surprises. Tip: Integrate into prioritization, DoD, and planning from the start.
• Risk: Over-constraining the system inflates cost and time. Tip: Negotiate minimum viable quality thresholds aligned to value and risk.
• Risk: Fragmented ownership across teams. Tip: Assign a clear owner (Program Product Owner) and maintain cross-team alignment.
• Risk: Missing compliance evidence. Tip: Link backlog items to required artifacts, audits, and test reports.
• Risk: Unverified in production. Tip: Add monitoring, alerts, and SLO dashboards to validate NFRs post-release.

PMP/SCRUM Example Question

During program-level backlog refinement, several new security and performance proposals emerge. What should the Program Product Owner do next to handle these proposed non-functional items?

1. Add them as tasks in the current sprint without estimation to avoid delay.
2. Assign them exclusively to the architecture team and bypass backlog refinement.
3. Capture them in the Program Product Backlog with measurable criteria, then reprioritize and update the Definition of Done as needed.
4. Defer them until after functional epics are fully delivered to protect scope.

Correct Answer: C — Capture them in the Program Product Backlog with measurable criteria, then reprioritize and update the Definition of Done as needed.

Explanation: Proposed non-functional items become backlog entries with clear metrics and are prioritized at the program level, often influencing the DoD. They are not forced into the current sprint or deferred without review.