Security-First Agile Scrum¶

A synthesis of Scrum theory, security engineering, and people-first culture for enterprise engineering teams. Applies a strict precedence hierarchy: Security First → People First → Agile/Scrum. Security is non-negotiable; Scrum is the framework that enables it; people are the ones who make it work.

Three Laws Precedence¶

Every process decision resolves conflicts in this order:

Security First — No sprint completes if security gates are open. No code ships with known Critical/High vulnerabilities. This is not a negotiation.
People First — Sustainable pace, psychological safety, and blameless culture are prerequisites for security. A burned-out or blame-averse team will hide vulnerabilities.
Agile/Scrum — The framework adapts to serve the first two laws, not the other way around. Scrum ceremonies are tools, not rituals.

Scrum Fundamentals¶

Scrum is a lightweight empirical process control framework built on three pillars: - Transparency — work and status visible to all - Inspection — artifacts and progress examined frequently - Adaptation — adjustments made when inspection reveals deviation

The Five Events¶

Event	Timebox	Purpose
Sprint	1–4 weeks (fixed)	Container for all other events
Sprint Planning	≤8 hrs (4-wk sprint)	Why/What/How — defines Sprint Goal
Daily Scrum	15 minutes	Developer sync toward Sprint Goal
Sprint Review	≤4 hrs	Inspect Increment, adapt backlog
Sprint Retrospective	≤3 hrs	Inspect team process, commit to improvements

Three Artifacts and Their Commitments¶

Artifact	Commitment
Product Backlog	Product Goal
Sprint Backlog	Sprint Goal
Increment	Definition of Done

Core Roles (Accountabilities)¶

Product Owner — single voice for value; orders the backlog; makes binding scope decisions
Scrum Master — serves team effectiveness; removes impediments; is NOT a project manager
Developers — self-managing; own the Sprint Backlog; decide who does what, when, and how

Velocity is a planning tool, never a performance target. Comparing velocity across teams is meaningless. Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.

Security as Definition of Done¶

The DoD applies universally to every Increment. Security gates are mandatory — an item that does not pass is returned to the backlog, not presented at Sprint Review.

## Security Definition of Done Checklist
- [ ] SAST scan (Semgrep + CodeQL) — 0 Critical/High findings
- [ ] SCA scan (Snyk/Dependabot) — 0 Critical CVEs in dependencies
- [ ] Secrets scan (Gitleaks) — 0 leaked secrets in commits or diffs
- [ ] IaC scan (Checkov) — 0 High misconfigs (when infra changed)
- [ ] All DB queries use parameterized patterns (no string concatenation)
- [ ] All API endpoints carry [Authorize] with appropriate policy
- [ ] CORS policy explicitly whitelists allowed origins only
- [ ] Content Security Policy headers configured (no unsafe-inline)
- [ ] Security logging verified (structured logs; no PII in logs)
- [ ] Threat model updated if new data flows or trust boundaries introduced
- [ ] AI-assisted code: PR labeled ai-assisted; reviewer confirms understanding (not just diff)

Pipeline enforcement: SAST and secrets scanning run as PR gates — the PR cannot merge on failure. SCA runs nightly and on PRs. IaC scanning triggers on infrastructure file changes only. Every gate should produce zero manual willpower.

Threat Modeling in Sprint Planning¶

Threat modeling belongs in backlog refinement, not as a waterfall gate. Apply a 5–10 minute STRIDE quick-scan per user story when a story introduces new data flows, external integrations, or trust boundary changes. Full models are reserved for epics.

STRIDE Quick-Scan (per user story, ≤10 min)¶

Category	Question	Common Finding
Spoofing	Can someone impersonate a user or service?	JWT validation missing on new endpoint
Tampering	Can request data be modified in transit or at rest?	Object IDs accepted from client without server-side validation
Repudiation	Can a user deny performing an action?	No audit trail for admin operations
Information Disclosure	Does this expose data to unauthorized parties?	API returns sensitive fields the client does not need
Denial of Service	Can this be abused to exhaust resources?	Unbounded query without pagination
Elevation of Privilege	Can a lower-privilege user gain higher access?	IDOR — user accesses another user's data by changing an ID parameter

When to Use Each Model¶

STRIDE — per user story during refinement (5–10 min)
PASTA (Process for Attack Simulation and Threat Analysis) — for epics quarterly; 7-stage full methodology
MITRE ATT&CK — for attack simulation and adversary-informed red teaming; map threats to specific techniques (T1190, T1078, T1552, T1059)

Misuse Stories¶

Write a misuse story alongside every security-sensitive user story. Format:

As a [attacker type], I want to [exploit behavior] by [attack vector], so that I can [attain goal]. Mitigations: [specific controls] [automated test that proves the mitigation]

Example — Broken Object-Level Authorization:

As a malicious authenticated user, I want to access other users' order data by manipulating the orderId parameter in GET /api/orders/{orderId}, so that I can steal PII and financial data. Mitigations: Controller verifies order.UserId == currentUser.Id. Integration test: authenticated User A requesting User B's order returns 403 Forbidden.

Security spikes handle unknowns: time-box 1–3 days. Deliverable is a recommendation and estimated stories, not production code.

Security Champions Model¶

One Security Champion per team (one per 10–20 developers). Select based on curiosity and peer influence — not seniority.

Champion Responsibilities¶

In refinement — flag stories with security implications; propose misuse stories; initiate STRIDE quick-scans
In code review — review security-tagged PRs; verify DoD security criteria
In Sprint Review — present security scan dashboard; trend open vulnerabilities vs. resolved
Ongoing — maintain team's security knowledge; escalate to central AppSec when needed

Security Guild¶

Champions from all teams form a Security Guild meeting bi-weekly: - Share findings across teams (vulnerability patterns, new attack techniques) - Maintain shared Semgrep rulesets, Gitleaks config, and scan baselines - Coordinate on cross-cutting security architecture decisions - Manage the Champions rotation schedule

Rotation Schedule¶

Rotate champions every 6–12 months. Overlap periods of 4 weeks for knowledge transfer. Track champion assignments on a dedicated Champions board in the project management tool. Never leave a team without a champion — overlap before rotating.

Champion Training Path¶

OWASP Top 10 (foundational)
Threat modeling facilitation (STRIDE workshop)
SAST tool operation and triage
Penetration testing basics and scope definition
Incident response and blameless postmortem facilitation

Security Sprint Cadence¶

Recurring Security Stories (add to backlog each sprint)¶

Dependency updates — triage Dependabot/Snyk alerts; fix Critical CVEs this sprint
SAST triage — review new CodeQL/Semgrep findings; close false positives; create stories for true positives
Security debt burndown — dedicate 10–20% of sprint capacity to security debt
Security metric review — update vulnerability age dashboard; MTTR trends

Security Backlog Grooming¶

Hold a dedicated Security Backlog Grooming session monthly (separate from standard refinement): - Review OWASP SAMM maturity scores against targets - Review all open vulnerabilities from the unified dashboard - Prioritize using CISA Known Exploited Vulnerabilities list first - Severity-based SLAs: Critical/CISA KEV → current sprint; CVSS ≥9.0 internet-facing → current sprint; CVSS 7.0–8.9 → within 2 sprints; lower → scheduled as capacity allows

Penetration Testing Cadence¶

Tier	Frequency	Scope
Automated DAST (OWASP ZAP baseline)	Every PR/build	Changed endpoints
Security Champion review	Each sprint	Security-critical features
Internal manual pentest	Quarterly	Full application scope
External firm engagement	Annually	Full scope including social engineering

With 2-week sprints, annual external testing leaves 25 of 26 releases untested. Layer all four tiers.

Psychological Safety (Project Aristotle)¶

Google's 2012 Project Aristotle studied 180+ teams and found psychological safety is the single strongest predictor of team effectiveness — stronger than individual talent, colocation, or seniority.

Five Dynamics of Effective Teams (in order of importance)¶

Psychological safety — safe to take interpersonal risks without embarrassment or punishment
Dependability — members complete quality work on time
Structure and clarity — clear roles, plans, and goals
Meaning — personal sense of purpose in the work
Impact — belief that work contributes to something larger

Teams with high psychological safety were rated effective 2× more often by executives and exceeded targets by 17% in sales. Low-safety teams fell short by 19%.

Timothy Clark's Four Stages (cumulative — each enables the next)¶

Inclusion Safety — you belong here
Learner Safety — safe to ask questions and make mistakes
Contributor Safety — safe to participate actively and voice ideas
Challenger Safety — safe to challenge the status quo without repercussion

Security-Safety Connection¶

Amy Edmondson's hospital research found stronger teams reported higher error rates — not because they made more mistakes, but because they felt safe reporting them. The same dynamic applies to security: teams without psychological safety hide vulnerabilities to avoid blame. Psychological safety is a security control.

Building Safety in Practice¶

Scrum Master models vulnerability: "I don't know — let's find out together"
React to mistakes with curiosity, not judgment: "What did we learn?"
Run safety check at retrospective start: "Rate 1–5 how safe you feel speaking openly"
Use anonymous input channels for sensitive feedback
Remove management observers from retrospectives

Blameless Postmortems¶

Adapted from Google SRE. A blameless postmortem assumes everyone involved had good intentions and made the best decision they could with the information they had at the time.

Postmortem Template¶

Incident summary — one paragraph, factual
Impact assessment — affected users, revenue impact, duration
Timeline — chronological, using roles not names
Root causes and triggers — systemic factors, not individual failures
What went well — detection speed, response effectiveness, communication
What went wrong — gaps in monitoring, process failures, tooling gaps
Where luck intervened — reveals future risks that could materialize without the lucky condition
Action items — SMART, single owner, due date, linked to Sprint Backlog ticket
Lessons learned — generalizable insights for future incidents

Store postmortems in a searchable team wiki. Review action item status at the next Sprint Retrospective. Use past incidents for "Wheel of Misfortune" training with new team members. Focus on systems, not individuals — the goal is to prevent recurrence, not assign blame.

Retrospective Formats¶

The #1 reason retrospectives fail: action items never get completed. Every unresolved action item teaches the team that participation is pointless.

Rules for Effective Retrospectives¶

Limit to 1–3 action items per retrospective
Each action item must be SMART: Specific, Measurable, Achievable, Relevant, Time-bound
Assign a single owner (not "the team")
Action items become Sprint Backlog tickets — they are real work
First 5 minutes: review previous action items before generating new ones
Open with Norman Kerth's Retrospective Prime Directive: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time."

Format	Best Used When	Structure
Start/Stop/Continue	Default; fast	Three columns, sticky notes, dot vote
4Ls	Milestone retrospectives	Liked / Learned / Lacked / Longed For
Sailboat	Team struggling with alignment	Wind (helps) / Anchor (slows) / Rocks (risks) / Island (goal)
Mad/Sad/Glad	Burned-out or high-stress teams	Emotional temperature check
Lean Coffee	Mature teams wanting open agenda	Participant-proposed topics, dot-vote, timeboxed discussion
Starfish	Teams needing nuance	More Of / Less Of / Keep / Start / Stop

Signs of Dysfunctional Retrospectives¶

Only 2–3 people talk (lack of psychological safety)
Same issues raised every sprint (action items not tracked)
Retrospective is the first ceremony cut (team sees no value)
Blame language directed at individuals

Team Health Checks¶

Spotify Squad Health Check (Kniberg & Lindwall, 2014)¶

Rate eleven dimensions on green/yellow/red with trend arrows: Easy to Release, Suitable Process, Tech Quality, Value, Speed, Mission, Fun, Learning, Support, Pawns or Players, Teamwork.

Run quarterly as a workshop with simultaneous card reveals — the conversation is the value, not the score. Track trends across quarters; scan across teams to spot systemic patterns.

Bus Factor Mitigation¶

Bus factor = minimum team members whose sudden absence would stall the project. Research of 25 popular GitHub projects found 10 had a bus factor of 1.

Strategies: - Pair programming — NC State research: ~15% development-time cost; 86–94% test pass rate vs. 73–78% solo - Mob programming — whole team on one problem; best for complex architectural decisions - Code review limits — SmartBear/Cisco: optimal review size 200–400 lines; defect detection drops sharply above 400 LOC - Architecture Decision Records — capture reasoning, not just decisions

Architecture Decision Records (ADRs)¶

ADRs (Michael Nygard, 2011; Thoughtworks Radar "Adopt" 2018) capture the reasoning behind architectural decisions for future team members and for system evolution.

ADR Template¶

# ADR-NNN: [Short title]

**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-NNN

**Context:** [What is the situation forcing this decision? What constraints apply?]

**Decision:** [What was decided?]

**Consequences:** [What becomes easier or harder as a result?]

Store in docs/adr/ in the repository — co-located with code, version-controlled, always current. Create ADRs during spikes and refinement. Reference them in Sprint Planning when related work appears. Present significant decisions in Sprint Review.

Sprint Planning Checklist with Security Gates¶

Before Sprint Planning¶

[ ] Security backlog groomed; Critical/High vulnerabilities assigned severity SLA
[ ] Previous sprint security scan results reviewed; open findings triaged
[ ] OWASP SAMM targets for this quarter reviewed
[ ] Champion available for the sprint (not on PTO)

During Sprint Planning¶

[ ] Sprint Goal drafted before selecting backlog items
[ ] Capacity calculated realistically (subtract ceremony time, PTO, support rotation, interrupt buffer)
[ ] Each story with new data flows or integrations: STRIDE quick-scan assigned (5–10 min during planning or refinement)
[ ] Security stories included (dependency updates, SAST triage, debt reduction)
[ ] Misuse stories written for security-sensitive features
[ ] AI-assisted work tagged; augmented DoD requirements confirmed
[ ] Security DoD checklist reviewed with team

Security Work Allocation Target¶

50–60% feature development
10–20% infrastructure
10–20% data engineering / analytics
10–20% security hardening and debt reduction

AI Coding Governance in Agile¶

The evidence (2024–2026) is sobering. The METR RCT (July 2025, 246 tasks) found AI tools made developers 19% slower despite developers believing they were 20% faster. Apiiro found AI-assisted commits merged 4× faster while introducing 322% more privilege escalation paths. Veracode found 45% of AI-generated code samples fail security tests. Google DORA 2025 found a 9% increase in bug rates correlated with 90% increase in AI adoption.

Decision Framework: When to Use AI¶

Use AI First	Use Human First	Human Only
Boilerplate/scaffolding (CRUD, DTOs)	Complex business logic	Authentication flows
Unit test generation	Domain-specific reasoning	Cryptography
Documentation	Familiar codebases	PII handling
Migration generation	Security-adjacent features	IaC for sensitive infra

Augmented DoD for AI-Assisted Code¶

[ ] PR labeled ai-assisted
[ ] At least one human reviewer confirms they understand the code (not just reviewed the diff)
[ ] SAST and secrets scanning passed
[ ] Parameterized queries verified (AI frequently generates string concatenation)
[ ] License compliance checked (AI hallucinates package names — verify all AI-introduced dependencies exist)
[ ] Test coverage maintained at parity with human-written code

Team Norms¶

Approved tools — enterprise-tier tools with audit logging only (no consumer AI tools with production code)
Prohibited — pasting production secrets or PII into AI prompts; using AI output without human review
Track metrics — AI-assisted vs. human-only defect rates per sprint; if security debt exceeds budget, reduce AI-assisted work next sprint

Timeboxing AI Agent Sessions¶

Time-box AI agent coding sessions to avoid runaway scope
Review AI-generated changes as a complete unit before merging (not incrementally)
Set a maximum PR size for AI-assisted work (e.g., 400 lines per review session)

DORA Metrics (2024 Benchmarks)¶

The four key DevOps metrics from the DORA research program (Accelerate, Forsgren, Humble, Kim, 2018):

Metric	Elite	High	Medium	Low
Deployment Frequency	Multiple per day	Daily to weekly	Weekly to monthly	Monthly to 6 months
Lead Time for Changes	< 1 day	1 day – 1 week	1 week – 1 month	1–6 months
Change Failure Rate	0–5%	~10%	~15%	16–30%+
Failed Deployment Recovery Time	< 1 hour	< 1 day	< 1 day	1 week – 1 month

Important nuances: - Performance tiers are derived via cluster analysis from annual survey data — they shift year to year, not fixed benchmarks - DORA renamed MTTR to "Failed Deployment Recovery Time" (FDRT) in recent releases - The 2024 report found AI tools boost individual productivity but correlate with worsened software delivery performance at the team level — second consecutive year of this finding - 19% of respondents reached Elite, 22% High in 2024

Instrument in CI/CD: Deployment Frequency via pipeline run data; Lead Time via commit-to-production timestamps; Change Failure Rate by tagging failed deployments; FDRT by measuring incident creation to resolution.

OWASP SAMM Integration¶

OWASP Software Assurance Maturity Model v2 provides a structured path for security program maturity.

Assessment Cadence¶

Baseline — run SAMM assessment using the online questionnaire
Target setting — set target maturity per practice area based on organizational risk profile
Backlog mapping — convert SAMM improvement activities to Product Backlog items
Quarterly reassessment — track maturity improvement over time

SAMM Business Functions and Practice Areas¶

Governance: Strategy & Metrics, Policy & Compliance, Education & Guidance
Design: Threat Assessment, Security Requirements, Security Architecture
Implementation: Secure Build, Secure Deployment, Defect Management
Verification: Architecture Assessment, Requirements-Driven Testing, Security Testing
Operations: Incident Management, Environment Management, Operational Management

Security Backlog Grooming sessions should review SAMM scores and connect improvement work to quarterly Sprint Goals.

Security Debt Management¶

60% of organizations carry critical security debt (Veracode 2026 State of Software Security). Security debt is technical debt with higher blast radius.

Visibility Mechanisms¶

Unified dashboard: open vulnerabilities by age, security debt trend per sprint, MTTR by severity
CISA Known Exploited Vulnerabilities list checked weekly
Vulnerability age tracked as a sprint metric (average days open by severity tier)

Prioritization SLAs¶

Severity	SLA
CISA KEV or CVSS ≥9.0 (internet-facing)	Current sprint
CVSS 7.0–8.9	Within 2 sprints
CVSS 4.0–6.9	Within current quarter
CVSS <4.0	Scheduled as capacity allows

Dedicate 10–20% of sprint capacity to security debt. Make this a standing capacity allocation visible in Sprint Planning — not something negotiated away under feature pressure.

Plugin: agile-delivery · View SKILL.md on GitHub