CampusEvolve Sprint Cadence: Partner Guide¶
This is a quick reference for the ChaosTheory team on how our sprint cadence works and where you plug in. We operate two-week sprints (10 business days). All times are shown in Eastern / Pacific.
Your Touch Points at a Glance¶
| When | What | Duration | Your role |
|---|---|---|---|
| Daily (except Wed) | Standup | 15 min | Required when working on sprint stories. Wednesday is async only (Slack). |
| Tue, Week 2 | Mid-Sprint Health Check | 30 min | Required when working on sprint stories. Extended standup: are we on track, anything at risk? |
| Thu, Week 2 | Backlog Grooming | 60 min | Required for shared stories. This is the first time you'll see upcoming technical stories and provide input. |
| Fri, Week 2 COB | Code Cutoff | All PRs must be submitted. No new code after this point. | |
| Monday | Sprint Close Day | All day | PR reviews, QA on staging, production deploy. No new code, reviews and verification only. |
| Tuesday 12:30 / 9:30 | Sprint Review | 30 min | Required. Demo your completed work to stakeholders. |
| Tuesday 2:00 / 11:00 | Sprint Planning | 60 min | Required. Final estimation, commit to sprint backlog. |
| Wednesday | No-Meeting Day | Sprint starts. Async standup only (Slack). No meetings, protected deep-work day. |
How Stories Get to You¶
We run a dual-track process. The CampusEvolve PM and designer run discovery (user research, problem framing, solution exploration) in parallel with delivery (your sprint work). Here's how that flows into your world:
-
Discovery happens on the CampusEvolve side. PM and design validate problems and explore solutions with stakeholders.
-
Arjun is the CampusEvolve tech lead for discovery. He participates in solution exploration and assesses technical feasibility. If a story needs ChaosTheory input during discovery, Arjun will bring you in, though we expect most stories will be fully shaped before grooming.
-
Your first formal look at upcoming stories is Thursday backlog grooming. The PM presents candidate stories for the next sprint. This is where you assess dev-readiness, ask clarifying questions, and provide rough t-shirt sizing (S/M/L/XL). If something isn't clear or isn't ready, flag it here.
-
Stories that aren't dev-ready on Thursday go back to the PM for refinement before Tuesday planning.
-
Final estimation and commitment happens at Tuesday sprint planning. Stories are estimated in story points (Fibonacci: 1, 2, 3, 5, 8, 13). The team commits to a sprint goal and sprint backlog. Story assignment (who works on what) happens here.
Sprint Shape: Day by Day¶
Week 1¶
| Day | What's happening |
|---|---|
| Wed | Sprint starts. No meetings. Async standup. Dig into your stories. |
| Thu | Standup 12:30 PM ET / 9:30 AM PT. First sync of the sprint. |
| Fri | Standup 12:30 PM ET / 9:30 AM PT. |
Week 2¶
| Day | What's happening |
|---|---|
| Mon | Standup 12:30 PM ET / 9:30 AM PT. |
| Tue | Standup + Mid-Sprint Health Check (30 min). Are we on track? Anything at risk? |
| Wed | No-meeting day. Async standup. |
| Thu | Backlog Grooming (60 min) + Standup. Review next sprint's candidate stories. |
| Fri | Standup. Code cutoff COB. All PRs submitted. |
Sprint Close + Ceremonies¶
| Day | Time | What |
|---|---|---|
| Mon | All day | Sprint close: PR reviews, staging QA, production deploy. No new code. |
| Tue | 12:30 PM ET / 9:30 AM PT | Sprint Review (30 min). Demo to stakeholders. |
| 2:00 PM ET / 11:00 AM PT | Sprint Planning (60 min). Estimate, commit, kick off next sprint. | |
| Wed | New sprint begins. Release goes out. Heads down. |
April 2026 Reference Calendar¶
Your touch points for the next two sprints at a glance. Grayed-out days have no required ChaosTheory involvement.
Deployment vs. Release¶
These are two different things in our process:
| Deployment | Release | |
|---|---|---|
| What | Code promoted to production | Stakeholders and users notified of new features |
| When | Gated: approved and triggered after QA on staging | Wednesday mid-morning, after sprint review |
| Who | Engineering (automated pipeline, manually gated) | PM + Engineering |
| Visibility | Internal, team monitors | External: stakeholders, users |
Deployments are automated but gated. The CI/CD pipeline handles the mechanics, but production deploys are approved and triggered deliberately, not on every merge. Brian has been managing this as release manager, and we appreciate ChaosTheory owning that process to date. Going forward, we want to coordinate deployment timing with the sprint cadence so that production deploys land before Monday's sprint close, giving us time for smoke testing and QA before Tuesday's sprint review.
The release happens after sprint review. The Tuesday sprint review is where stakeholders see completed work and provide feedback. The Wednesday release is the communication event: release notes, stakeholder emails, "here's what's new." Sprint review is the feedback gate before that communication goes out.
What about stakeholder-sensitive changes?¶
If code is already in production before Tuesday's review, what does stakeholder feedback actually gate? In practice:
- Most sprint work is incremental. Bug fixes, small improvements, routine features. These don't need stakeholder approval before they're live, and the deploy-before-review gap is a non-issue.
- High-visibility or stakeholder-sensitive features get flagged during grooming. If the PM identifies something that needs stakeholder sign-off before users see it, we plan for that during grooming using a feature flag, a staged rollout, or holding the deploy until after review. This is the exception, not the rule.
- Sprint review gates the release narrative. If a stakeholder says "that's not what we intended," we can pull the feature from release comms, revert, or flag for immediate follow-up before users are formally told about it.
The short version: deploy when ready, but plan ahead for anything where stakeholder feedback could change the outcome. That planning happens at grooming, not at deploy time.
How We Work Together¶
These are shared expectations across both teams:
- One Definition of Done. Code reviewed, tests passing, acceptance criteria verified on staging, deployed to production, smoke tested. A story that's code-complete but not deployed is not done.
- PR review turnaround within 24 hours. Peter reviews appapi PRs, Hedley reviews RAG PRs, Eric reviews frontend PRs. Brian works across all of them to shepherd PRs into production. Same expectation in reverse for reviews on shared codebases.
- Surface blockers early. If a story is at risk, raise it in standup or Slack, not on Monday.
- Respect the code cutoff. Friday COB means PRs submitted, not "almost done." If something won't make it, communicate by Thursday so we can adjust scope.
- Communication in Slack. Blockers and updates in the team channel, not in private DMs.
Where We Keep Things Separate (and Why)¶
We're two organizations working as one team. The touch points above are designed to enable deep collaboration while respecting that each team has its own working style and culture. A few things stay on the CampusEvolve side:
- Discovery. CampusEvolve PM, design, and Arjun run discovery and validate stories before they reach the team. This means engineers see stories when they're actionable, not when they're still being shaped. If a story needs ChaosTheory input earlier, Arjun will pull you in.
- Retrospectives. Each team benefits from having space to reflect on their own processes. Our retros are internal by default for the same reason yours would be. When there's something that spans both teams, we'll run a joint session.
- Internal tooling and team structure. We've outlined our processes and cadence to reflect how we'd like to work. The touch points above are where we converge, and outside of those, each team continues to operate according to its own practices.
If something feels like it needs more collaboration, raise it. We'd rather over-communicate than under-communicate.
Key Dates Reference¶
All ceremonies happen on a single Tuesday every two weeks. The full schedule:
| Time (ET) | Time (PT) | Event |
|---|---|---|
| 12:30 PM | 9:30 AM | Sprint Review (30 min), with stakeholders |
| 1:15 PM | 10:15 AM | Retrospective (30 min), internal only |
| 2:00 PM | 11:00 AM | Sprint Planning (60 min), all devs |
If you have questions about the process, reach out to Toby, Arjun, or Margaret.