What are two good ways for the Development Team to make non-functional requirements visible? (Choose two.)

Question

Options

• APut them on a separate list on the Scrum board, available for all to see.
• BAdd them to the Product Backlog and keep the Product Owner posted on the expected effort.
• CRun the integration and regression tests before the end of the Sprint, and capture the open work
• DAdd them to the definition of "Done" so the work is taken care of every Sprint.

• A
  6% (2)
• B
  74% (25)
• C
  21% (7)

Explanation

B and D are correct because they integrate non-functional requirements (NFRs) into Scrum's core artifacts, ensuring they are visible, tracked, and acted upon. Adding NFRs to the Product Backlog (B) makes them explicit, estimable items that the Product Owner can prioritize alongside functional work. Adding them to the Definition of Done (D) ensures every increment is checked against these requirements each Sprint - they become a non-negotiable quality gate rather than an afterthought.

A is wrong because a separate list creates a silo outside the normal Scrum workflow - it's easily overlooked and not officially part of the framework. C is wrong because running tests near the end of the Sprint is a reactive discovery mechanism, not a visibility strategy; it captures open work but doesn't make NFRs a planned, trackable concern.

Memory tip: Think of two levels - Backlog (B) for planning visibility and Done (D) for enforcement visibility. NFRs need to be seen before the Sprint starts (backlog) and verified before it ends (definition of done).

No community discussion yet for this question.