Manu's Vault

Sprint Process Criteria

3 min readStatus:Seedling

Sprint Process Criteria

A diagnostic checklist for evaluating whether a team’s iteration process is working — independent of the specific methodology (Scrum, Kanban, or hybrid). Larson distills seven observable, measurable criteria from observing many engineering teams.

The Seven Criteria

  • Velocity is measured and stable: The team tracks throughput per sprint and the number is consistent enough to be predictable. Wild variability signals broken estimation or planning
  • Sprints finish what they start: Carryover work is a symptom of overcommitment or unclear scope
  • Bugs are addressed before new features: The team has a bug prioritisation policy and follows it. Accumulating bug debt compounds faster than technical debt
  • The team can articulate its priorities: Every engineer knows what the team is working on and why
  • Meetings have clear owners and outcomes: Sprint ceremonies produce defined outputs. Meetings without outcomes erode morale
  • Retrospectives drive visible improvement: Retros are held AND improvements are implemented. Retros without change are worse than no retros at all
  • Oncall load doesn’t overwhelm sprint capacity: Operational burden is tracked and factored into commitments

Diagnostic Application

Use the criteria as a traffic-light scorecard:

  • Score each criterion: green (working), yellow (degrading), red (broken)
  • Address the reddest criterion first — fixing multiple things simultaneously dilutes focus
  • Reassess after each sprint to track improvement trajectory

Connection to Team States

Different Four-States-of-a-Team correlate with different criteria failures:

  • Falling Behind: Criteria 1 and 2 fail first (velocity unstable, sprints don’t close)
  • Treading Water: Criteria 3, 6, and 7 fail (bugs accumulate, retros produce no change, oncall overwhelms)
  • Repaying Debt: Criteria 4 and 5 are hardest to restore (team alignment and meeting discipline)
  • Innovating: All seven criteria are green

Common Root Causes

  • Velocity instability → ticket sizing inconsistent or scope undefined at sprint start
  • Bugs not addressed → no explicit policy; see Work-the-Policy-Not-the-Exception
  • Retros without improvement → action owners not assigned, no follow-up mechanism
  • Oncall load ignored → operational work invisible in planning tools
  • These criteria complement DORA-Four-Metrics — DORA measures delivery throughput; these criteria diagnose why throughput is where it is

Sources

  • Larson, Will (2019). An Elegant Puzzle: Systems of Engineering Management. Stripe Press. ISBN: 978-1-7322651-8-9.

    • Chapter 7.1 (Appendix): Seven criteria for effective sprint processes

  • Schwaber, Ken and Jeff Sutherland (2020). The Scrum Guide: The Definitive Guide to Scrum — The Rules of the Game. Scrum.org.

  • Cohn, Mike (2005). Agile Estimating and Planning. Prentice Hall. ISBN: 978-0-13-147941-8.

    • Chapter 3: Velocity as a planning tool; research-backed treatment of velocity stability and sprint commitment

  • Forsgren, Nicole, Jez Humble, and Gene Kim (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. ISBN: 978-1-942788-33-1.

    • Four key metrics of software delivery performance; complementary measurement framework to Larson’s sprint criteria

  • Denning, Stephen (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM. ISBN: 978-0-8144-3870-8.

    • Chapter 2: Research on why retrospectives without implementation produce negative team outcomes

Note

This note was researched and drafted with AI. How these notes are written →

Graph View

Backlinks