Add one security question to each sprint retrospective, rotating through six: skipped checks, blocked reviews, scan results, near misses, the definition of done and ownership. One question keeps the retro focused and builds a habit, so security is discussed as routine quality work and not only after an incident.
What the Scrum Guide says retros are for
The Scrum Guide says the purpose of the sprint retrospective is to plan ways to increase quality and effectiveness. The team inspects how the sprint went with regard to individuals, interactions, processes, tools and its definition of done, and it identifies assumptions that led it astray. Security issues are quality issues, so they fit that scope with no special treatment.
The six rotating questions
| Sprint | Question | What it surfaces |
|---|---|---|
| 1 | Which security check did we skip or rush, and why? | A line in the definition of done that is wrong or unowned |
| 2 | Did any story wait on a security review, and for how long? | Queue time that caps delivery |
| 3 | What did the last scan results teach us? | Patterns in findings and noisy checks |
| 4 | What nearly went wrong? | Near misses that never became incidents |
| 5 | What would we change in the definition of done? | Concrete edits |
| 6 | Who did not know who to ask? | Gaps in ownership and contacts |
After six sprints, start again. Change the order if something is urgent.
How to run the segment
- Keep it to five minutes. One question, silent writing for two minutes, then discussion.
- Write answers on cards or a shared board. Quiet voices get heard.
- Group the answers. Look for the same issue named twice.
- Pick one change. Not five. One change the team will actually make.
- Give it an owner and a date. A change with no name is a wish.
- Check it next sprint. Start the next retro by asking if the change happened.
Turning answers into changes
Most answers lead to one of four edits:
- A new or sharper line in the definition of done.
- A new pipeline check, or a check removed because it is noise.
- A change to the refinement questions.
- A new contact or an agreed response time for security help.
NIST's Secure Software Development Framework asks teams to analyze root causes, look for patterns over time and review the SDLC to update it where appropriate. A regular retro question is a light way to do that every sprint, not only after incidents.
Keep it blameless
Ask "what made this easy to miss?" and not "who missed it?" People will not admit a skipped check if they expect to be blamed for it. A skipped check is usually a sign that the check is slow, unclear or unreasonable.
Common mistakes
- Always covering security last. It gets cut when time runs out. Put it in the middle on a rotating basis.
- Collecting actions and never closing them. Review the previous sprint's change first.
- Making it security staff's job. The team owns its process. Staff can attend when invited.
- Asking the same question every time. People start giving the same answer. Rotate.
Measure lightly
Count how many security-related retro actions were completed in the following sprint. A rising completion rate shows the habit is working. Do not count the number of issues raised, which rewards noise.
When an incident happens
An incident deserves its own review. The regular question set is for the quiet sprints, where small changes prevent the loud ones.
Safeguard offers compliance and evidence automation plus policy gates, which can feed the "scan results" and "skipped check" questions with real data. A free scan is available at gold.safeguard.sh/scan.
Quick check
How much retro time should security take?
About five minutes: one question, silent writing, brief discussion and one agreed change with an owner.
What if nobody has anything to say?
Try a different question, or bring a concrete data point such as the last scan result or a review that waited several days.
Sources
Last reviewed: 19 October 2026.
