How should a Development Team deal with non-functional requirements?

Question

Options

• AEnsure every Increment meets them.
• BMake sure the release department understands these requirements, but it is not the Development
• CHandle them during the Integration Sprint preceding the Release Sprint.
• DAssign them to the lead developers on the team.

• A
  92% (55)
• B
  2% (1)
• C
  2% (1)
• D
  5% (3)

Explanation

Non-functional requirements (NFRs) - such as performance, security, scalability, and accessibility - are part of the Definition of Done and must be satisfied in every Increment, not deferred or delegated, which is why A is correct. Option B is wrong because the Development Team owns quality; offloading NFRs to a release department violates the self-organizing nature of Scrum teams. Option C is wrong because Scrum has no "Integration Sprint" or "Release Sprint" - deferring quality to a special sprint is a classic anti-pattern that leads to technical debt and last-minute failures. Option D is wrong because quality is a shared team responsibility; assigning NFRs only to lead developers creates bottlenecks and silos.

Memory tip: Think of NFRs as the "invisible walls" of your product - every single room (Increment) must have them built in from the start, not added at the end of construction.

No community discussion yet for this question.