30/60/90 Sprint Plan & Cadence Template

Welcome — What this template helps you do

This template helps teams convert a vague improvement goal into three focused 30‑day sprints that chain into a 90‑day learning cycle. Use it to assign ownership, define observable success, run experiments, track leading and lagging measures, keep a steady cadence of huddles and retros, and store evidence so results become reusable organizational knowledge.

How to use this template

Copy one template per 90‑day cycle. Treat it as a scaffold: tailor scope, cadence, and measures to your team capacity. Keep the records (artifacts, results, decisions) attached to the sprint so future teams can reuse what worked.

Core template fields (fill these for each 30‑day sprint)

• Sprint name & phase: (diagnose | experiment | adopt) — days 0–30, 31–60, 61–90.
• Sprint objective: one clear sentence describing the desired outcome.
• Success criteria (observable): specific, measurable acceptance criteria the team will use to decide if the sprint succeeded.
• Owner(s): primary owner and backup—responsible for progress and artifacts.
• Stakeholders: who must be informed, consulted, or makes decisions.
• Measures: leading indicators (predict change) and lagging indicators (result metrics). Include baseline and target values.
• Experiments backlog / interventions: prioritized list of experiments or changes to try with clear inputs, expected effect, and measurement plan.
• Weekly cadence: standup, KPI review, experiment checkpoints, and a short retro. Include owners and timeboxes.
• Escalation path: when and how to escalate blockers, risks, or resourcing requests.
• Artifacts & handoff checklist: evidence captured at sprint close (data, experiment results, SOP drafts, training materials, decisions, and next‑step recommendations).
• Repository location: where artifacts and the completed sprint record will be stored (link to shared drive, wiki, or THE collection).

Suggested timeboxes and meeting cadences

• Weekly standup: 15 minutes — quick progress, blockers, and plan for next 7 days.
• Weekly KPI review: 30 minutes — review leading & lagging measures; owner updates on experiments.
• Experiment checkpoint (ad hoc): 15–30 minutes — when an experiment completes or needs early pivoting.
• End‑of‑sprint retro and decision session: 60 minutes — review evidence, decide adopt/abandon, and plan handoff.
• Monthly stakeholder review: 30 minutes — share progress, approvals, and escalation items with stakeholders (useful at day 30, day 60, day 90).

Measures — examples & guidance

Choose one or two meaningful lagging measures and 2–3 leading indicators you can update weekly. Be explicit about measurement frequency and data source.

• Lagging measure example: Customer satisfaction score, defect rate, on‑time delivery %, mean time to resolve.
• Leading measure example: Number of tickets triaged within 1 hour, percent of work passing first QA check, experiments run per week.
• Baseline & target: record current value, realistic target for the sprint, and who owns the data feed.

Experiments backlog format (repeatable)

1. Experiment title
2. Hypothesis: If we [change], then [expected effect] measured by [metric].
3. Design: what will we do, sample sizes, duration.
4. Owner: who runs it.
5. Success criteria: how we will judge success or failure.
6. Data source & cadence: where to get results and when to review.

Escalation path

Define thresholds that trigger escalation (e.g., risk to target, resource constraint, cross‑team dependency). Then list contacts and response expectations.

• Level 1: Sprint owner → Team lead (within 24 hours)
• Level 2: Team lead → Department manager (72 hours)
• Level 3: Department manager → Sponsor/executive (as scheduled in stakeholder review)

Artifacts for handoff and organizational memory

At the end of each sprint capture and store the following:

• Data snapshot: before/after values for measures; raw data extracts.
• Experiment records: hypothesis, design, results, interpretation.
• Decisions log: what was decided, by whom, and why.
• New or updated SOPs, playbooks, checklists, or scripts.
• Training materials and rollout plan if adopted.
• Link to code, configuration, or deployment artifacts (if applicable).
• One‑page summary for stakeholders (problem, approach, result, next steps).

Common failure modes and how to avoid them

• Unclear ownership — make owners explicit and name backups.
• No measurable criteria — define observable success before starting.
• Skipping reflection — hold the retro and record decisions with evidence.
• Orphaned results — store artifacts in a shared repository and link to related Domain resources.
• Overly rigid checklists — prioritize learning; use the template as a scaffold, not a rulebook.

Tailoring guidance

Adjust sprint length, cadence, and scope for your context. For high‑risk experiments shorten cycles and increase cadence; for complex change allow more time to embed adoption. Always weigh team capacity and alignment with strategic priorities.

Sample filled example (concise)

End‑of‑sprint retro checklist

1. Attach data snapshots and experiment records to the sprint page.
2. Record the decision: adopt, adapt, or abandon each experiment with rationale.
3. Update SOPs and schedule training if adopting changes.
4. Identify follow‑on experiments or next cycle objectives.

Preserve what you learned

Store every completed sprint in your Organizational Intelligence collection with tags for problem area, team, metrics, and date. Link related toolkits, audits, and playbooks so future teams can find and reuse tested practices.

Quick checklist before you start

• Is the sprint objective clear and aligned to a larger priority?
• Is there a named owner and backup?
• Are measures defined, with a data owner and baseline?
• Is the scope reasonable for 30 days?
• Have you scheduled the cadence meetings and stakeholder reviews?

Use this template as a living scaffold: copy it, adapt it, and attach the completed sprint artifacts so your organization gets steadily smarter.