What are two effective ways for a Scrum Team to ensure security concerns are satisfied? (choose the best two answers)

Question

Options

• AAdd security concerns to the Definition of Done.
• BDelegate the work to the security department.
• CHave the Scrum Team create Product Backlog items for each concern.
• DAdd a Sprint to specifically resolve all security concerns.
• EPostpone the work until a specialist can perform a security audit and create a list of security-

Explanation

The best two answers are A and C.

Adding security concerns to the Definition of Done (A) ensures that no Increment is considered complete unless it meets security standards - making security a built-in quality gate applied consistently every Sprint, not an afterthought. Creating Product Backlog items for each concern (C) makes security work transparent, estimable, and prioritizable by the Product Owner, integrating it into the normal Scrum workflow rather than treating it as invisible or external.

B is wrong because delegating to a separate security department creates external dependencies and contradicts Scrum's principle of cross-functional, self-managing teams. D is wrong because a dedicated "security Sprint" is an anti-pattern - it implies security is a one-time fix rather than a continuous concern, and Scrum Sprints should deliver potentially shippable increments, not just cleanup. E is wrong because postponing security work until an audit violates the Scrum value of continuous inspection and adaptation; deferring security creates technical debt and risk.

Memory tip: Think "bake it in, don't bolt it on" - security belongs in the DoD (every Sprint) and the Backlog (visible and prioritized), never delegated, deferred, or dumped into a single Sprint.

No community discussion yet for this question.