The First 48 Hours
Taking over mid-sprint is disorienting. The team has context you don't, and the sprint board reflects decisions you weren't part of.
Here's what I do:
Hour 1–4: Don't touch the sprint
Resist the urge to reorganise tickets or re-prioritise. First, understand what's actually happening:
- Read every open ticket and its comments
- Talk to each developer 1:1 (15 min each): "What are you working on? What's blocking you?"
- Read the last 3 sprint retrospectives
Hour 4–8: Build your KT checklist
Document what you now know and what you still need:
- Sprint goal — confirmed
- Architecture docs — located
- Deployment process — need walkthrough
- Client escalation path — who contacts the PM?
Day 2: One change, communicated clearly
Pick the single highest-leverage change you can make in 24 hours. Ship it. Tell the team what you changed and why. This builds trust faster than any kickoff meeting.
The Longer Game
Mid-sprint leads are measured on delivery, not transformation. Stabilise first, improve second. The goal of sprint N is to finish sprint N — not to redesign the architecture.
Save the systemic improvements for sprint N+1 when you have the full context and team trust.