You can fit threat modeling into sprint planning by choosing only the stories that change trust boundaries, spending about fifteen minutes on them as a group, and turning each concern into a ticket or an acceptance criterion before the meeting ends. Most stories need none of this. The skill is picking the few that do.
Pick the stories, not the sprint
Scan the sprint list for stories that touch any of these: a new way for a user or system to authenticate, a new data store, a new external call, a new file or message the system accepts from outside, or a change to who can see what. Everything else gets a pass. In a typical sprint this is one to three stories, not twenty.
If you cannot tell by looking, a one line question to the story owner works: "does this change who or what can reach our data?"
The fifteen minute routine
Put the selected stories on a screen and spend roughly five minutes each.
- Sketch. One person draws the flow on a whiteboard: who sends what to which component, and where data is stored.
- Ask what can go wrong. Use a prompt such as: what would a curious user try, what would a careless colleague break, and what would an attacker with one stolen credential reach?
- Pick the top concerns. Not all of them. Two or three that you would be uncomfortable explaining after an incident.
- Decide the response. Each concern becomes a change to the story, a new acceptance criterion, a follow-up ticket, or a recorded decision to accept it.
The facilitator rotates each sprint so the habit does not depend on one person.
What to write down
Keep notes short and near the work. Add them as a comment on the story itself, not in a separate document no one opens. A useful note has three lines: the concern, the decision, and the owner. When someone asks later why a field is validated twice, the answer is findable.
Keep it honest about time
If a story needs more than five minutes, it needs its own session. Say so, schedule it, and mark the story as blocked until it happens. Forcing a deep design question into a planning slot produces shallow answers and false confidence.
Common ways this goes wrong
- Running it on every story, so the team learns to stop paying attention.
- Letting the loudest person list concerns while others stay silent. Ask each person for one.
- Producing a long list with no owners. A concern without a ticket will not be fixed.
- Skipping the routine in busy sprints, which are exactly the ones that ship rushed changes.
See when to threat model a feature for a fuller list of triggers, and threat modeling in four questions for the question set behind this routine.
Quick check
Do we need a security expert in the room?
It helps, but it is not required for the routine. Engineers who know the feature often spot the weak points. Bring in a specialist for stories that touch authentication, payments or sensitive data.
What if the team finds a problem we cannot fix this sprint?
Record it as a ticket with an owner and a date to revisit, and decide whether the story can ship with a mitigation or must wait. Do not leave it only in meeting notes.
Last reviewed: 19 October 2026.
