HKSM

Candidate non-functional requirements and constraints submitted for inclusion and ordering in the Product Backlog. Sourced from stakeholders, standards, and risk analysis, they are refined, made testable, and prioritized by the Product Owner with the Scrum Team. They guide quality criteria, design choices, and cross-cutting work across sprints.

Key Points

• Represents proposed quality attributes and constraints to be added and ordered in the Product Backlog.
• Includes performance, security, reliability, usability, scalability, compliance, and operational needs.
• Originates from stakeholders, regulators, architecture discussions, risk assessments, and operations.
• Prioritized by the Product Owner based on value, risk, compliance urgency, and technical dependency.
• Refined into testable, measurable acceptance criteria and sometimes dedicated non-functional stories or enablers.
• Influences Definition of Done, release planning, and system-wide design decisions.
• Acts as an input to Create Prioritized Product Backlog and is revisited during backlog refinement.

Purpose

The purpose is to ensure non-functional expectations are visible, measurable, and prioritized alongside functional work. This reduces late discovery of quality gaps, aligns architecture early, and helps the team plan capacity to meet service-level objectives.

By capturing these items explicitly, the Product Owner and team can balance feature delivery with essential quality characteristics and compliance obligations.

Key Terms & Clauses

• Non-functional item: A backlog entry that describes how the system should perform rather than what it does.
• Quality attribute: A measurable characteristic such as performance, security, reliability, or usability.
• Constraint: A rule or limit (e.g., regulatory, technology, compatibility) that the solution must respect.
• Acceptance criteria: Specific, testable conditions that confirm the non-functional item is met.
• Definition of Done: Team agreement that may embed recurring non-functional thresholds across stories.
• Service-level objective: A target threshold (e.g., response time, availability) the product should meet.

How to Develop/Evaluate

1. Gather sources: Elicit from stakeholders, compliance documents, support teams, and risk logs.
2. Express clearly: Phrase as backlog items or clauses with measurable thresholds and scope of impact.
3. Make testable: Add acceptance criteria with quantifiable targets and verification methods.
4. Assess impact: Identify affected epics/stories, dependencies, and architectural considerations.
5. Estimate collaboratively: Size effort with the Development Team; consider spikes to reduce uncertainty.
6. Prioritize: The Product Owner orders by value, risk, compliance deadlines, and sequencing needs.
7. Record links: Map each non-functional item to related stories, releases, and test suites.

How to Use

During Create Prioritized Product Backlog, add proposed non-functional items, ensure they are measurable, and order them with stakeholders. In Approve, Estimate, and Commit User Stories, embed relevant non-functional acceptance criteria into stories or plan separate non-functional stories.

In Sprint Planning, select relevant non-functional items or criteria, plan tasks and tests, and update the Definition of Done if a recurring threshold applies. In Release Planning and during reviews, verify non-functional outcomes with appropriate test evidence and monitoring data.

Example Snippet

• Security hardening baseline: All APIs require OAuth 2.0 with token expiry of 60 minutes; penetration test shows zero critical vulnerabilities.
• Performance threshold: 95 percent of catalog searches return within 300 ms under 1,000 concurrent users; monitored in staging and production-like tests.
• Availability objective: Service maintains 99.9 percent uptime monthly with automated failover validated in a controlled failover test.

Risks & Tips

• Risk: Vague statements like "fast" or "secure" cause rework. Tip: Use numeric thresholds and clear test methods.
• Risk: Treating non-functional needs as "later" leads to architectural debt. Tip: Prioritize early items that unlock or protect value.
• Risk: Scattered ownership dilutes accountability. Tip: Assign clear owners and link to Definition of Done where recurring.
• Risk: Overloading a sprint with invisible quality work. Tip: Make NFR work visible as backlog items with estimates and tests.
• Risk: Compliance surprises near release. Tip: Involve compliance and security stakeholders in backlog refinement.

PMP/SCRUM Example Question

While creating the Prioritized Product Backlog, the team receives new security and performance constraints from a regulator. What should the Product Owner do next?

1. Add them to the Sprint Backlog immediately without prioritization.
2. Treat them as impediments for the Scrum Master to resolve later.
3. Record them as proposed non-functional items, make them measurable, and prioritize them in the Product Backlog.
4. Defer them to release planning because they are not functional features.

Correct Answer: C — Record them as proposed non-functional items, make them measurable, and prioritize them in the Product Backlog.

Explanation: Non-functional needs are captured and ordered in the Product Backlog by the Product Owner, with clear acceptance criteria. They are not automatically in the Sprint Backlog, nor should they be deferred or treated as impediments.