Each sprint is structured by several regular meetings, or “sprint rituals.” These meetings should serve the project team and help move work forward.

If you find that the project team is going through the motions of the rituals, it’s probably time to change something about the meetings.

Daily standup

This is a daily meeting, with the goal of creating visibility into the work and keeping everyone focused, un-stuck, and moving forward. Occasionally the team decides to use email or Slack to share standup-style updates when it’s not possible to meet in person.

Here’s what I do to run standup each day:

• Show up to meeting, remind other people to show up, and decide when you have quorum to start (if folks are unavailable, remind them to post their update elsewhere so the team can see it)
• Set format for standup; usually one of these two options:
  • Yesterday / Today / Blockers: each person says what they worked on yesterday, what they’re doing today, and if they have any blockers
  • Waffle check-in: PM goes through each issue in review, in progress, and in the backlog, asking the relevant person to speak to the next steps or blockers for moving that issue forward. (Sometimes just covering “in review” and “in progress” issues is plenty.) Can either go through issues in order, or by person.
• Announce format and facilitate.
  • Ask clarifying questions, add context, or emphasize priorities as everyone goes through their work.
  • If things come up that people are working on, but that aren’t reflected in the project board, work with people to get that work reflected (often this means finding the relevant issue, opening an issue, asking them to open an issue, or asking them to deprioritize that work in favor of in-sprint priorities).
  • At the end, close by emphasizing priorities or reiterating next steps.
• END THE MEETING once the agenda’s done (even if that’s early)

Sprint demo

The goal of demo is to share the progress we made in the last sprint with stakeholders, which helps to build visibility and trust in the process — and avoid surprises about what’s going to go live. Here’s what I generally do to run demo each sprint:

• Before demo:
  • Take a look at GitHub or Waffle to get a sense of what work might be ready to show
  • Reach out to team members and ask them to share specific features or explain progress
  • Post a brief agenda and ask whether you’re missing anything
• At demo:
  • Welcome any stakeholders and introduce the agenda/order
  • Hand off to each team member to share whatever feature they’re demonstrating
  • Ask questions to encourage each person to frame the work in terms of problems solved or user needs addressed
  • Add context or background as needed
  • Leave time for questions (some silence is okay!)
  • Keep timing on track, and sometimes decide to end the meeting early or skip something if things take much more or less time than expected

Demo is not a “progress update.” It’s meaningfully different from standup, in that it’s more outcome-oriented and shipping-focused. The tone is also different: instead of framing things as here’s how I spent my time, we frame things in terms of here’s the goal accomplished or here is how we solved X problem.

It can be tempting to skip demo if stakeholders don’t show up. Don’t do it; even if it’s just the core team, it’s incredibly valuable to take the time to treat each other as stakeholders and make space to celebrate and reflect on the accomplishments of the sprint. This also forces you to stay honest—if you find yourself saying we didn’t accomplish anything this sprint, that’s a good clue that scoping or prioritization needs to change in order to be more focused and make tangible progress each sprint.

Sprint retrospective

The goal of retro is to reflect as a team on how our last sprint went, and identify opportunities to help us work even more effectively together the following sprint and beyond. It’s how we ensure we’re continually improving and building momentum as a team.

It’s important that retro feels like a safe, blameless space—making sure only core team members participate in the meeting is an important part of this (no “onlookers” from outside the core team).

Before retro:

• Decide on what format you’ll use
• Prep the space where you’ll be holding retro (this can be a real space, or a shared document like we’ve been using)

During retro:

• If any new folks are joining the meeting, set the tone for what the meeting is about and that it’s a space to be honest. Some teams start by reiterating the “Prime Directive”:
  • "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
• Announce format and facilitate.
• Capture any next steps you hear articulated.

For happy-shruggie-tableflip retro format:

• 5 minutes for everyone to write things
• Once writing has calmed down, give folks 3 minutes to add +
• Discuss items with the most plusses, asking folks to elaborate

A couple other formats that can work well:

• “I like; I wish; What if” (use these 3 prompts in lieu of “happy-shruggie-tableflip”, but the facilitation is pretty much identical)
• “Keep doing; start doing; stop doing” (same as above)

Sprint planning

The goal of sprint planning is to help the team align on what chunk of work they’ll be tackling during the upcoming sprint, and making sure each issue for the sprint is clear and well-defined.

How we facilitate it currently:

• Kick off the meeting
• Review last sprint’s goals, and get a temperature check on how we did. This helps calibrate whether we’re setting goals that are too safe or too ambitious. (We should achieve some of them, but not all.)
• Take a look at our high-level roadmap, and check what’s on the horizon. Use this to help the team come up with 2-3 major sprint goals.
• Open a new milestone in GitHub, give the sprint a name (optional but fun), set an end date, and capture the sprint goals in the description. The sprint goals should reflect what the team is hoping to accomplish, but not be so wide-ranging that the team is likely to feel pulled in too many directions.
• Look at the previous sprint, close out any completed issues, and pull forward any issues that serve the new sprint goals. If an issue doesn’t serve the sprint goals, don’t pull it into the sprint (and drag it back to the product backlog or icebox, as appropriate).
• Look at any issues in the icebox/product backlog and identify whether they serve the sprint goals or are dependencies for any of the in-sprint issues. If so, pull ‘em in!
  • This is where it can be helpful to be keeping your backlog in good shape via regular backlog refinement sessions, so the team is more familiar with what’s actually in there and are prepared to make these calls more quickly during sprint planning.
• Before ending the session, make sure:
  • All the tasks needed to achieve our sprint goals are represented in the sprint backlog.
  • Each issue in the sprint backlog is assigned to the right person, and that person feels clear on what the definition of “done” is and feels capable of achieving it during the sprint (ideally, you’ll capture the definition of done in the issue description itself).
  • Each team member is capable of verbalizing their top individual goal for that sprint (sometimes it can be helpful to spend the last 5 minutes of the meeting actually doing this if the team felt unfocused during the last sprint, but it’s not always necessary).