There are a handful of sprint ceremonies that we go through and I thought it would be useful to document what the expected inputs and outputs of each should be, so that folks are ready for the meeting and know what they’re hoping to get out of it.
Backlog Refinement/Grooming
This is where we have conversations about requirements. You’d expect to hear stuff like “Yeah.. but what does that mean?” or “What’s the user going to see when this happens?”
Show up with:
- A list of unrefined tickets from your backlog with the “stuff we think we want to work on soon” near the top (not actually prioritized, but closeish)
- A list of benchmarked stories for your effort/complexity/doubt estimation
Leave with:
- Stories that have:
- clear, testable acceptance criteria
- high-fidelity estimates (e.g. story points)
- broken down into useful units of work
- identified any forseen technical dependencies
Planning
This is where we come up with what we’re going to spend our time on in the next two weeks.
Show up with:
- A prioritized and refined product backlog
- Team velocity from recent sprints
- A goal for the sprint that’s more tangible than “do the work”
- The Definition of Done
- Who’s going to be out (vacation, needs to do the all-day security training, etc)
Leave with:
- A sprint goal a user could get excited about
- A sprint backlog w/ tasks that are broken down into ~1 day of work each
- Task assignments / ownership mapping
Standups
These 15-minute check-ins keep everyone aligned on daily progress and surface blockers before they derail your sprint. Think of it as your team’s daily coordination mechanism, not a status report for management.
Show up with:
- A list of things that are actively blocking your work (not just general frustrations; save those for the retro)
- A list of things that you actually completed yesterday (completed; not worked on)
- Your plan for the day that’s more specific than “continue working”
Leave with:
- An understanding of how the team is tracking towards the sprint completion
- Coordination for any pair programming needs
- Confidence that we’re all working on the same goal
Demo / Review
This is an externally facing thing where your team can show stakeholders the working software you built and get their feedback. It’s where you find out if what you built actually solves the problem you thought it would solve.
Show up with:
- Working software (half-finished stuff doesn’t count)
- Stakeholders who represent our customer
- A list of what was/wasn’t completed from the sprint backlog
- A pair of fresh eyes who can wear the hat of the “user” (someone who hasn’t been in the daily weeds of building this feature)
Leave with:
- Product backlog updates based on what you learned
- Acceptance or rejection decisions on delivered features
- Input for next sprint’s priorities
- Validated (with those fresh eyes) that the story actually does hit the problem the user has
Retro
This is an internally facing meeting. The team looks back at how the sprint went and identifies specific improvements to try next time. It’s the difference between repeating the same mistakes every sprint and actually getting better at working together.
Show up with:
- Sprint metrics (velocity, burndown, defect counts - the real numbers)
- Specific examples of what went well and what didn’t
- Previous retrospective action items and their status
- Safe space where people can actually speak up
Leave with:
- 1-3 concrete action items (not a laundry list of good intentions)
- Process changes you’ll actually implement next sprint with clear owners
- Team agreements or working norms