Effective Scrum ceremonies — Part 3

Photo by Daria Nepriakhina 🇺🇦 on Unsplash

So far, we’ve covered the wins and drawbacks of communication methods such as writing documents and meetings. Next, we spoke about the heart of async, written words! We dove into using the golden circle to help us stick with recording communications to facilitate discussion and gain goodies such as inclusivity, thoughtfulness and flexibility.

Ceremonies

If you’re following Scrum, you’ll have a series of ceremonies that repeat on a weekly, or bi-weekly basis. An example of ceremonies for a 2-week sprint in a medium size team:

• Standups (15 min) * 10
• Sprint planning (3 hr) * 1
• Sprint Review (2 hr) * 1
• Sprint Retrospective (1.5 hr) * 1

After deducting time for lunches, this amounts to nearly 1.5 days every two weeks for each member of your team. Rounding up, that’s 15% of 2 weeks on recurring meetings, it’s pretty typical for these to run over too. We can agree this is a significant amount of time, it’s therefore worth exploring how we could improve on them from an efficiency standpoint.

Standup Meetings

One of the most adopted techniques in Extreme Programming, standup meetings generally include:

1. What we did yesterday
2. What we’re doing today
3. Blockers (if any)

With distributed people and teams, the standup can and does suffer. It’s quite easy for a standup to run over when everyone is sat down, become an environment to fixate on nuance issues, derailing its purpose. With this, engagement can be impacted, we get into, we have the meeting, because we have the meeting as its original value and purpose erodes.

Focusing on the numbered list above, here’s some methods of improvement:

• ✅ Write updates — Using tooling effectively, points 1 & 2 can be answered by the board. If they can’t, it’s either a tooling problem or a human one. Team members should update via writing comments on stories and moving tickets into lanes / statuses. What happens when someone is out of the office? Unable to make the standup? Relying on sync communication creates frustration and slows us down.
• ✅ Flag stories — If you have a blocker, you’re likely already tackling and trying to resolve, not waiting until the next standup! Flag the ticket if blocked, write a comment explaining why, default to action, waiting to do this sync slows everything down.

Actioning the above points, it can become apparent the daily standup isn’t required. However, the key benefit of these meetings is the connection opportunity they provide. If your team still want them, remove the status update. Discuss the next actions, sprint goals, health check, high risk branches or changes.

There’s also a benefit of psychological safety via actioning the above, as the ticket communicates the progress of the story, avoiding lots of questions from multiple people.

Sprint Retrospective

The agile process is all about enabling continuous improvement. There’s no better way than having a retrospective! It’s a way to surface issues, celebrate success and enable actions to be taken away for future improvements. However, ran poorly, they can do more harm than good.

1. 😕 If they consistently don’t yield meaningful output, people lose faith in the ceremony
2. 🔄 We all have a recency bias, recording events that recently happened, leaving more historic issues to happen again
3. ⏱️ Running out of time, due to poor grouping, lack of voting, or absence of a theme

All these issues can be mostly solved by… you guessed it, async means. Here’s how we’ll make our retros more effective, efficient, and purposeful.

✅ Capture inputs — Enable and encourage the habit of everyone writing topics for the next retro throughout the sprint, these could be in a Google Form, doc, or even in their favourite note taking app. These can be sent to the facilitator of the retro if anonymity is not a concern.

✅ Group inputs — The host, ahead of time, groups related topics. If this was a Miro board then sticky notes in clusters achieves this. This helps with point 2.

✅ Voting — This enables focus and prioritises the topics people feel strongly about. This helps with point 3. As this is usually a quick process, it can be done before or during the meeting.

Sprint Planning

It’s a heavyweight ceremony and, unlike others, it involves many different subprocesses. Discussing these would require an article of its own. So, lets discuss this purely from an async, efficiency perspective. Here’s how we can streamline our planning sessions.

1. Have some form of async backlog refining where time is set aside to enhance stories via metrics or more detail, ready for the sprint.
2. Tightly prioritise the backlog for the function of increasing focus around outcomes.
3. Define the sprint goals before the meeting, the Product Owner / Engineering Manager can draft this, it will give natural shape to the start of the meeting. Make this known before the meeting to all.
4. Encourage team members to look through the draft of stories to bring into the sprint async, here there’s the opportunity to write comments in the stories for clarification.
5. Have the meeting.

Doing the above, will yield the following:

• ✅ Allows the team to think deeply about stories, thus create better outcomes such as horizontally slicing into smaller stories or highlighting potential issues.
• ✅ We’ll have a list of questions already available to discuss during the meeting, this is huge.
• ✅ Reduce risk that you’re pursuing the wrong thing.
• ✅ We’ll already have thought about the sprint goal and seen the approximate stories, which will give a better confidence indicator on if the goal is achievable, or requires reduction.

Conclusion

We’ve discussed simplifying each ceremony with straightforward, asynchronous actions. As a result, we’re creating a better fuel to accelerate meeting outcomes, ensuring we get the best out of each sync interaction. Furthermore, it enables contributions when it suits the individual and unlock thoughtfulness which can create better, faster delivery and greater working software.