The below details the steps within our two week sprint timeline.
🏃♀️ Sprint Lifecycle: Two-Week Sprints + Deployment
This doc outlines how our team operates in two-week sprints, including when work gets planned, executed, and deployed.
📅 Sprint Schedule Overview
-
Sprint Length: 2 weeks (10 business days)
-
Sprint Cadence: Starts on Monday, ends on Friday (two weeks later)
-
Sprint Planning: Held on the Thursday before the sprint begins
-
Deployment Timing: The Thursday after the sprint ends
-
Goal: Deliver well-defined, tested, and stable work in a predictable rhythm
🔁 Sprint Lifecycle Breakdown
1. Backlog Refinement (Ongoing, Weekly)
Who: Product Manager, Developers
Purpose: Ensure upcoming work is well-defined and ready to be pulled into a sprint
Includes:
-
Ticket grooming and estimation
-
Prioritization for the next sprint
-
Breaking down large items into sprint-sized chunks
2. Sprint Planning (Thursday Before Sprint Start)
Who: Full Product + Development team
Purpose: Finalize scope and commitments for the next sprint
Includes:
-
Review of prioritized, groomed tickets
-
Agreement on what will be worked on
-
Clarify goals, blockers, and acceptance criteria
3. Sprint Execution (Sprint Days 1–10: Monday–Friday)
Who: Development, QA, Product
Purpose: Build and test sprint work
Includes:
-
Dev work begins on Sprint Day 1 (Monday)
-
QA begins testing as features become available
-
Daily standups
-
Work moves to “Ready to Deploy” once merged and verified in QA
4. Sprint End (Sprint Day 10 – Friday)
Purpose: Wrap up the sprint and evaluate outcomes
Includes:
-
Final testing and bug fixes
🚀 Deployment Process
5. Post-Sprint QA + Deployment Prep (Monday–Wednesday after sprint end)
Purpose: Final validation before production release
Includes:
-
Regression testing in QA
-
Address any last-minute send-back issues
-
Final approval from PM for release scope
6. Production Deployment (Thursday after sprint ends)
Purpose: Release completed sprint work to users
Includes:
-
Night time deployment to production
-
Post-deploy smoke test
-
Notify stakeholders (via changelog, email, etc.)
📥 Getting Work Into a Sprint
To be eligible for inclusion in a sprint, tickets must be:
-
Clearly defined with acceptance criteria
-
Estimated and groomed
-
Prioritized ahead of Thursday planning
- Critical bug fixes or hotfixes