Sprint Cadence¶
Two-week sprint cadence optimized for deep work, stakeholder transparency, and sustainable pace. Ceremony days are consolidated to minimize context switching, with no-meeting Wednesdays protected throughout.
This is the delivery track. It runs in parallel with the discovery track, where the PM and designer validate problems and solutions before they enter the sprint backlog. The two tracks converge at Thursday backlog grooming.
Sprint Calendar¶
Sprints are 10 business days. The next sprint starts Wednesday morning after ceremonies on Tuesday.
Week 1 — Sprint Start¶
| Day | Activity | Details |
|---|---|---|
| Wednesday | Sprint starts — heads down | No meetings. Async standup only (Slack). Dig into sprint backlog immediately. |
| Thursday | Standup (12:30 ET / 9:30 PT) | First synchronous standup of the sprint. |
| Friday | Standup |
Week 2 — Mid-Sprint¶
| Day | Activity | Details |
|---|---|---|
| Monday | Standup | |
| Tuesday | Standup + Mid-Sprint Health Check | Extend standup to 30 min. Focus: Are we on track? Any stories at risk? Scope adjustment needed? |
| Wednesday | No-meeting day | Async standup only. |
| Thursday | Backlog Grooming + Standup | PM walks team through candidate stories for the next sprint. Team assesses dev-readiness and does rough t-shirt sizing (S/M/L/XL). |
| Friday | Standup. Code cutoff: COB. | All PRs must be submitted by end of day. No new code after this point — Monday is for reviews, QA, and deployment only. |
Sprint Close + Ceremonies¶
| Day | Time (ET) | Activity | Details |
|---|---|---|---|
| Monday | All day | Sprint close day | PR reviews, QA verification on staging, production deployment, smoke testing. Sprint closes COB. No new code. |
| Tuesday | 12:30 PM ET / 9:30 AM PT | Sprint Review (30 min) | Demo completed work to stakeholders. Showcase what's about to be released. Collect feedback. |
| 1:00 PM ET / 10:00 AM PT | Break (15 min) | Stakeholders drop off. | |
| 1:15 PM ET / 10:15 AM PT | Retrospective (30 min) | What went well? What didn't? One action item with an owner. Internal team only. | |
| 1:45 PM ET / 10:45 AM PT | Break (15 min) | ||
| 2:00 PM ET / 11:00 AM PT | Sprint Planning (60 min) | Final point estimation on groomed stories. Commit to sprint goal and sprint backlog. | |
| ~3:00 PM ET / ~12:00 PM PT | Done | ||
| Wednesday | Mid-morning | Release | Stakeholder notifications, release notes, user-facing comms. New sprint begins — heads down. |
Key Concepts¶
Deployment vs. Release¶
| Deployment | Release | |
|---|---|---|
| What | Code shipped to production | Stakeholders and users notified of new features |
| When | Continuously throughout the sprint | Wednesday mid-morning after sprint close |
| Who | Engineering (automated CI/CD) | PM + Engineering |
| Visibility | Internal (team monitors) | External (stakeholders, users) |
Deployments happen whenever code is merged and passes CI/CD. Zero-downtime deployments are assumed. A release is a communication event — it bundles deployed features into a narrative for stakeholders.
Definition of Done¶
A story is done when all of the following are true:
- [ ] Code is peer-reviewed and merged to main
- [ ] All unit and integration tests pass in CI
- [ ] Acceptance criteria verified on staging
- [ ] Deployed to production and smoke tested
- [ ] No known regressions introduced
- [ ] Documentation updated (if applicable — API changes, config changes, user-facing behavior)
A story that is code-complete but not deployed is not done. A story that is deployed but hasn't passed acceptance criteria is not done.
Because we deploy continuously throughout the sprint, most stories should meet the DoD well before Monday. The Friday code cutoff exists so that Monday is reserved for final verification — not for writing new code. If Monday regularly feels hectic, stories are too large, acceptance criteria are unclear, or the CI/CD pipeline needs investment.
Tracking progress toward Done:
| Checkpoint | What it means | Typical timing |
|---|---|---|
| PR submitted | Code is ready for review | Throughout sprint, by Friday COB at latest |
| PR merged | Code reviewed, tests passing, in main | Throughout sprint, Monday at latest |
| Staging verified | QA/acceptance criteria confirmed | Throughout sprint, Monday midday at latest |
| Production deployed | Live, smoke tested, DoD met | Throughout sprint, Monday COB at latest |
| Released | Included in stakeholder comms | Wednesday mid-morning |
These are visibility checkpoints, not gates. The only question that matters is: does the story meet the Definition of Done by sprint close (Monday COB)?
Estimation: Two-Pass Approach¶
| Pass | When | Method | Purpose |
|---|---|---|---|
| Rough sizing | Thursday backlog grooming | T-shirt sizes (S/M/L/XL) | Assess dev-readiness, flag stories that need refinement, give PM a sense of capacity fit |
| Final estimation | Tuesday sprint planning | Story points (Fibonacci: 1, 2, 3, 5, 8, 13) | Commit to sprint backlog with calibrated effort |
Stories that can't be t-shirt sized on Thursday aren't dev-ready. They go back to the PM for refinement before Tuesday planning.
Code Cutoff¶
- Friday COB is the PR submission deadline for the current sprint
- Monday is reserved for PR reviews, QA, and production deployment
- No new feature code should be written on Monday
- Emergency bug fixes are the exception, not the rule
Standups¶
- Time: 12:30 PM ET / 9:30 AM PT (daily except Wednesday)
- Wednesday: Async only — post update in Slack (no meeting)
- Format: What I did, what I'm doing, any blockers
- Duration: 15 minutes (30 min on mid-sprint Tuesday health check)
Mid-Sprint Health Check (Tuesday, Week 2)¶
Extended standup or separate 30-min session. Focused questions:
- Are we on track for the sprint goal?
- Which stories are at risk of not completing?
- Do we need to pull anything out or adjust scope?
- Are there any unblocked items that need pairing or support?
Ceremony Reference¶
| Ceremony | Duration | When | Purpose |
|---|---|---|---|
| Backlog Grooming | 60 min | Thursday, Week 2 | Review candidate stories, assess dev-readiness, rough t-shirt sizing |
| Sprint Review | 30 min | Tuesday 12:30 PM ET / 9:30 AM PT | Demo completed work to stakeholders, collect feedback |
| Retrospective | 30 min | Tuesday 1:15 PM ET / 10:15 AM PT | Team reflection, process improvement, action items (internal team only) |
| Sprint Planning | 60 min | Tuesday 2:00 PM ET / 11:00 AM PT | Final estimation, sprint goal, sprint backlog commitment |
| Standup | 15 min | Daily (async Wed) | Sync, blockers, progress |
| Mid-Sprint Check | 30 min | Tuesday, Week 2 | Sprint health assessment, scope adjustment |
Total ceremony time per sprint: ~4-5 hours (across 10 working days). Ceremony Tuesday itself is ~2 hours.
Why These Durations¶
We're a small team — roughly 5 internal + 5 partner. Ceremony durations are sized to match:
- Sprint Review (30 min): With 5-6 devs, there are typically 2-4 stories to demo. At 5-7 minutes per demo plus questions, 30 minutes is sufficient. If there's nothing substantial to demo, end early — don't fill time.
- Retrospective (30 min): Three internal team members can surface and discuss issues in 30 minutes. Larger retro formats (75+ min) are designed for teams of 8+ where everyone needs airtime. A simple format works: one thing that went well, one thing to improve, one action item.
- Sprint Planning (60 min): This compresses the least — the team still needs to walk through groomed stories, estimate, and commit. But with a pre-groomed backlog from Thursday, 60 minutes is sufficient.
If the team grows or ceremonies consistently feel rushed, extend them. But start tight and expand only when there's evidence of need.
Ceremony Attendance¶
Not everyone needs to attend every ceremony. Ceremony time is expensive — protect it by only including the people who need to be there.
| Ceremony | Internal Team | Partner Engineers | Stakeholders | CPO |
|---|---|---|---|---|
| Sprint Review | All | Yes (demo their work) | Yes | Yes |
| Retrospective | All | By invitation | No | By invitation |
| Sprint Planning | All | Yes | No | Optional |
| Backlog Grooming | All | Yes (for shared stories) | No | No |
| Standup | All | Optional / async | No | No |
Why the retrospective is internal-only by default:
Retrospectives require psychological safety. Team members need to feel comfortable raising concerns about process, communication, and collaboration without filtering for an audience. When leadership or external partners are present, feedback tends to become safer and less actionable.
This is not about exclusion — it's about creating the conditions for honest reflection. When a cross-team process issue needs addressing, invite the relevant partner team members to that specific retro. Run a joint retro quarterly as a relationship-building exercise. But the default is internal.
Product direction input:
Strategic product input (priorities, roadmap, business context) is valuable — and it belongs in discovery, not at the planning table. The PM brings product direction into planning through the prioritized, groomed backlog. Planning is where the team estimates and commits to what they can deliver, not where priorities are debated. Priority debates that happen at planning are a sign that discovery isn't running far enough ahead.
Role Expectations¶
Product Manager¶
Owns: Product backlog, story quality, stakeholder communication, release comms
| When | Responsibility |
|---|---|
| Ongoing | Refine backlog stories — write clear acceptance criteria, attach designs/specs, answer dev questions async |
| Thursday (Week 2) | Lead backlog grooming. Present candidate stories for next sprint. Only bring stories that are dev-ready or nearly so. Be prepared to answer questions about intent, scope, and priority. |
| Friday-Monday | Refine any stories flagged as not-ready during Thursday grooming. Ensure they're dev-ready by Tuesday planning. |
| Monday (sprint close) | Verify acceptance criteria on staging for completed stories. Confirm stories meet DoD. |
| Tuesday AM | Lead sprint review. Walk stakeholders through completed work. Collect feedback and capture new backlog items. |
| Tuesday PM | Co-lead sprint planning with Scrum Master. Present prioritized backlog. Clarify scope and trade-offs. Propose sprint goal. |
| Wednesday | Own the release. Send release notes and stakeholder comms. Communicate what shipped and what's coming next. |
Key expectations:
- Stories brought to grooming should have clear acceptance criteria — "as a user, I can..." not "implement X"
- The PM is the single voice of priority. If devs are confused about what matters most, that's a PM problem.
- Don't bring more stories to grooming than can fit in a sprint. Over-grooming wastes everyone's time.
- Attend standups to stay current on progress and blockers — but don't run them.
Scrum Master¶
Owns: Process health, ceremony facilitation, impediment removal, team dynamics
| When | Responsibility |
|---|---|
| Ongoing | Remove blockers surfaced in standup. Shield the team from unplanned work and scope creep. Monitor sprint burndown. |
| Tuesday (Week 2) | Facilitate mid-sprint health check. Surface at-risk stories. Facilitate scope adjustment if needed. |
| Thursday (Week 2) | Facilitate backlog grooming. Keep the session to 60 min. Ensure devs have space to ask questions and flag concerns. |
| Friday | Enforce code cutoff. Flag any stories that won't have PRs submitted by COB. |
| Monday (sprint close) | Monitor sprint close. Ensure remaining PRs are reviewed and stories are verified. Update sprint board. |
| Tuesday AM | Facilitate sprint review. Keep it focused on demo, not status updates. Time-box to 60 min. |
| Tuesday late AM | Facilitate retrospective. Review action items from last retro first. Drive toward 2-3 concrete action items with owners and due dates. |
| Tuesday PM | Co-lead sprint planning. Facilitate estimation. Ensure the team doesn't overcommit. Confirm sprint goal. |
| Wednesday | Verify sprint board is clean — new sprint is set up, old sprint is closed, stories are properly categorized. |
Key expectations:
- The Scrum Master is not a project manager. They don't assign work or track tasks — they protect the process and the team.
- Facilitate, don't dictate. The team decides how much to commit to; the Scrum Master ensures the decision is informed.
- Own the retro action items. If last sprint's action items didn't happen, figure out why before adding new ones.
- Be the one who says "that's out of scope for this sprint" so devs don't have to.
- Protect no-meeting Wednesday. No exceptions, no "just a quick sync."
Developers¶
Own: Technical execution, code quality, estimation accuracy, peer review
| When | Responsibility |
|---|---|
| Wednesday (sprint start) | Pick up stories from the sprint backlog. Post async standup in Slack. Start work immediately. |
| Daily (except Wed) | Attend standup (12:30 ET / 9:30 PT). Surface blockers early — don't wait until mid-sprint health check. |
| Wednesday | Async standup only. Deep work day — protect it. |
| Throughout sprint | Write code, write tests, submit PRs, review teammates' PRs. Deploy to production as stories are completed — don't batch deploys to Monday. |
| Thursday (Week 2) | Participate in backlog grooming. Ask clarifying questions. Provide rough t-shirt sizing. Flag stories that aren't dev-ready. |
| Friday (Week 2) | Code cutoff. All PRs submitted by COB. If a story won't make it, communicate early — don't surprise the team Monday. |
| Monday (sprint close) | Review teammates' PRs. Verify stories on staging. Deploy remaining work to production. Smoke test. No new feature code. |
| Tuesday AM | Demo completed work in sprint review. Show the thing, don't describe the thing. |
| Tuesday late AM | Participate in retrospective. Be honest about what's working and what isn't. |
| Tuesday PM | Participate in sprint planning. Provide final story point estimates. Commit to what you believe the team can deliver — don't let yourself be pressured into overcommitting. |
Key expectations:
- Estimate honestly. It's better to undercommit and pull in extra stories than to overcommit and carry work over.
- Communicate early when something is at risk. "I don't think this will make the sprint" on Thursday is useful. On Monday it's too late.
- Review PRs within 24 hours. Don't be the bottleneck. A PR sitting in review is inventory, not progress.
- Own your deployments. If your code is merged and tests pass, deploy it. Don't wait for permission or Monday.
- Stories aren't done until they meet the DoD. "It works on my machine" or "the PR is merged" is not done.
Stakeholders¶
Own: Feedback, domain expertise, adoption
| When | Responsibility |
|---|---|
| Tuesday AM | Attend sprint review. See completed work. Provide feedback. Raise concerns before the release, not after. |
| Ongoing | Provide feedback and requirements to the PM. Don't go directly to devs with requests — it bypasses prioritization. |
| Wednesday | Review release notes. Test new features if applicable. Report issues through the PM. |
Key expectations:
- Sprint review is your opportunity to influence what ships. If you skip it, you lose that input.
- New requests go through the PM and into the backlog. Urgent issues can be escalated, but "urgent" should be rare.
- Trust the sprint commitment. Once planning is done, the team has committed to a scope. Adding work mid-sprint undermines the process.
Scrum Guide Divergences¶
This process intentionally diverges from the Scrum Guide (2020) in several places. Each divergence is a deliberate choice.
1. Sprint starts Wednesday, not Monday¶
Scrum Guide: No specific day prescribed, but implies ceremonies happen at sprint boundaries with work starting immediately after.
We do: Ceremonies on Tuesday, sprint starts Wednesday.
Why: Stacking all ceremonies on Tuesday means Wednesday is a clean start with no meeting overhead. The team gets immediate deep-work time at the beginning of the sprint instead of losing Day 1 to planning. Combined with no-meeting Wednesday, this gives maximum momentum.
2. Backlog refinement before sprint close, not during the sprint¶
Scrum Guide: Refinement is an ongoing activity during the sprint, consuming no more than 10% of the team's capacity.
We do: Structured grooming session on Thursday of Week 2, with a second pass during Tuesday planning.
Why: Doing grooming close to (but before) planning means stories are fresh in mind. The two-pass estimation approach (t-shirt Thursday, points Tuesday) gives devs thinking time without requiring multiple grooming sessions. Stories that aren't dev-ready on Thursday have Friday and Monday to be refined by the PM.
3. Sprint Review before release¶
Scrum Guide: Sprint Review inspects the outcome of the Sprint. It's the second to last event of the Sprint.
We do: Sprint Review is Tuesday morning, release is Wednesday mid-morning — review happens before the release goes out to users.
Why: This gives stakeholders a chance to see the work and provide feedback that could gate the release. If something significant surfaces in the review, we can hold a feature from the release without delaying the sprint close.
4. Retrospective before planning (same day)¶
Scrum Guide: The Retrospective is the final event of the Sprint. Sprint Planning initiates the next Sprint.
We do: Both happen on Tuesday — retro late morning, planning afternoon.
Why: Retro insights are fresh for planning. If the retro surfaces a process issue (e.g., "we took on too much last sprint"), the team can immediately apply that learning when committing to the next sprint's backlog.
5. No-meeting Wednesdays¶
Scrum Guide: Daily Scrum is every day of the sprint, no exceptions.
We do: Async standup on Wednesdays via Slack. No synchronous meetings.
Why: Protecting one day per week for uninterrupted deep work significantly improves developer productivity and morale. The async update still provides visibility. With a distributed team across ET and PT, Wednesday async also respects the 3-hour timezone gap.
6. Fixed ceremony day¶
Scrum Guide: Events should be held at consistent times.
We do: All major ceremonies (Review, Retro, Planning) happen on a single Tuesday every two weeks.
Why: Most teams spread ceremonies across multiple days. Consolidating to one day is more aggressive but means the other 9 days have minimal meeting overhead.
Working with External Partners¶
We work with external development partners (e.g., ChaosTheory) who have their own internal processes. We don't require partners to adopt our full scrum process — we define clear integration points so both teams can work effectively.
Partner Integration Points¶
| Touchpoint | Partner Attendance | Purpose |
|---|---|---|
| Sprint Review (Tuesday) | Required | See completed work, demo their contributions, receive feedback |
| Backlog Grooming (Thursday) | Required for shared stories | Estimate and assess dev-readiness on stories they'll own or co-own |
| Sprint Planning (Tuesday) | Required | Commit to stories, understand sprint goal |
| Standup | Optional / async | Post async updates in Slack. Attend synchronously only when actively working on sprint stories. |
| Retrospective | By invitation | Include when process issues span teams. Default to internal-only to maintain psychological safety. |
Shared Working Agreement¶
These apply to all contributors — internal and partner:
- Same Definition of Done. Partner-delivered stories meet the same DoD as internal stories. No exceptions.
- PR review within 24 hours. PRs from partner devs are reviewed by the designated internal owner (Peter for appapi, Hedley for RAG). Partner devs review internal PRs on shared codebases.
- Communication via Slack. Blockers are surfaced in the team channel, not in private DMs or side conversations.
- Story assignment at planning. The PM assigns stories to partner or internal devs during sprint planning. No mid-sprint reassignment without the Scrum Master's involvement.
- Escalation path. If a partner-owned story is at risk, the partner surfaces it in standup or Slack — not on Monday.
What Partners Don't Need¶
- Access to retrospective notes (unless invited to the retro)
- Adoption of our internal discovery process
- Changes to their internal team structure or tooling
- Attendance at mid-sprint health checks (internal checkpoint)
Transitioning from the Current Process¶
We're shifting from a Friday-close sprint with a combined board-walkthrough meeting to the process described in this document. This section captures the key changes and guidance for the first few sprints.
What's Changing¶
| Before | After |
|---|---|
| Sprints end Friday | Sprints end Monday COB |
| Combined board walkthrough (Fri 5:00 PM ET) | Separate Review, Retro, and Planning (Tuesday 12:00-4:15 PM ET) |
| Walk Jira board column by column | Demo working software to stakeholders, then plan separately |
| No formal sprint goal | Sprint goal set at planning — one sentence describing what we're trying to achieve |
| No estimation | Two-pass: t-shirt sizing Thursday, story points Tuesday |
| No code cutoff | Friday COB code cutoff — Monday is reviews and deployment only |
| No dedicated grooming session | Thursday grooming — stories assessed for dev-readiness before planning |
Why the Board Walkthrough Isn't a Sprint Review¶
The current meeting has the right people in the room — including stakeholders. But walking Jira columns and discussing ticket statuses is a triage activity, not a review. Stakeholders don't need to know whether a ticket moved from "In Progress" to "In Review." They need to see what it does.
The board walkthrough still has value — it lives in two places in the new process:
- Thursday backlog grooming — "Is this story dev-ready? Should it stay in the backlog?"
- Monday sprint close — Quick board cleanup to ensure stories reflect reality before ceremonies.
Guidance for the First 2-3 Sprints¶
Start small and build the muscle
- Sprint review can be short at first. Even 2-3 live demos is better than zero. The goal is to shift from "status update" to "show and tell." Over time, devs will get comfortable demoing and the format will feel natural.
- Don't over-plan. The first sprint planning under the new process doesn't need to be perfect. Point the top 5-6 stories, set a rough sprint goal, and iterate.
- Retros will feel unfamiliar. If the team hasn't done structured retros, start with a simple format: one sticky per person for "went well," "didn't go well," and "try next sprint." Keep it safe.
- The Friday code cutoff will feel early. That's the point. If it creates pressure, stories are too large or PRs aren't being submitted incrementally.
- Stakeholders may resist the new format. They're used to the board walk. Tell them: "We're going to show you what we built instead of reading you ticket statuses. Same time investment, more useful."
Anti-Patterns to Watch¶
If you see these patterns, something needs attention.
- Monday scramble: Stories aren't being completed by Friday. Enforce the code cutoff.
- Thursday grooming goes long: Stories aren't being refined by the PM before the session. PM should pre-filter and only bring dev-ready candidates.
- Retrospective action items die: Assign owners and due dates. Review previous retro actions at the start of each retro.
- Sprint goal is a list, not a goal: The sprint goal should be a single sentence describing what we're trying to achieve, not a list of tickets.
- Deployment anxiety on Monday: The CI/CD pipeline needs investment. Deployments should be boring.
- Ceremony creep: Ceremonies should stay tight. If review regularly exceeds 30 min, demos aren't focused. If retro exceeds 30 min, the format needs simplifying. If planning exceeds 60 min, stories weren't groomed well enough on Thursday.