Lately, I've seen some Scrum Teams using or being advised to hold a Mid Sprint Check-in. Sometimes it goes by other names such as a Mid Sprint Demo or Mid Sprint Review. What's wrong with these extra meetings? Plenty.
Maybe it seems like a great idea on the surface, or perhaps you heard that other Scrum Teams are doing it and want to suggest it to your team. I've heard Agile coaches recommend it more than once. There's even a Polly "Mid-Sprint Check-in" app that can be used in Slack to poll your team on their confidence to "hit their deliverables". One person told me they use the Mid Sprint Check-in because "Things usually don't go as planned during the Sprint, and we often end up with too many unfinished stories by the end of the Sprint. So we need this checkpoint to get the team focused and discuss issues before the Sprint Review".
These meetings are not necessary and are most likely:
- a sign that someone doesn't trust your Scrum team;
- masking impediments and covering up problems;
- a misunderstanding of the principles of Scrum resulting in your Scrum Team being less effective;
- wasting your Scrum Team's time with yet another meeting.
In the article, I will discuss why some folks think they need these meetings and why they make Scrum much less effective and give people the illusion of control and predictability. Proceed with caution!
There's even a Polly "Mid-Sprint Check-in" app that can be used in Slack to poll your team on their confidence to "hit their deliverables".
Scrum Is Simple - Use It As Is
Let's step back for a moment and refresh ourselves on the basics of Scrum. The Scrum Guide only prescribes five events. The Sprint is the container event that holds four other events: Sprint Planning, the Daily Scrum, Sprint Review, and Sprint Retrospective. Some teams might hold ongoing Product Backlog refinement sessions as needed, yet a formal meeting is not prescribed. Scrum doesn't prescribe a Mid Sprint Checkin or Mid-Sprint Demo. Scrum events are supposed to minimize the need for other meetings.
You might argue that the Scrum Guide is intentionally incomplete and that these other meetings, such as the Mid Sprint Check-in, are complimentary practices. There is nothing wrong with complimentary practices such as limiting WIP, story mapping, Test Driven development, pair programming, and more. But many other practices are generally harmful.
Scrum events are supposed to minimize the need for other meetings.
The Mid Sprint Check-in Anti-Pattern
When I hear someone mention that a Scrum team needs or is holding a Mid Sprint Check-in every Sprint, I get curious and ask what problem it is intended to solve. I've heard answers such as:
- During the halfway point of a Sprint, it's a good time for the team to understand if everything is going to be finished by the end of the Sprint so that the Developers can meet their commitments.
- We can use this as an opportunity to sync up to find out if anyone needs help finishing their tasks this Sprint.
- It will help us uncover any roadblocks to getting our work finished.
This is a good sign that some Scrum myths and misunderstandings must be addressed by the Scrum Master. Some believe that the Developers commit to completing the entire Sprint Backlog. Developers do not commit to completing everything in the Sprint Backlog - they commit to meeting the Sprint Goal. The Sprint Goal guides decision-making and allows some flexibility throughout the Sprint. If the scope needs clarification or adjusting, the Sprint Goal provides guidance and flexibility. As soon as the Developers discover the Sprint Goal is in jeopardy, they should talk to the Product Owner immediately.
And yet another misunderstanding that I see often is that the Daily Scrum is used as a status meeting. The Daily Scrum is not a status meeting - it is a planning meeting for the Developers to inspect their progress towards the Sprint Goal and adapt their plan for the next 24 hours (i.e., adapt the Sprint Backlog). There should never be a need to check on commitments mid-Sprint if the Daily Scrum is used properly. Never.
Another myth I see is people subscribing to the idea that the Daily Scrum is a sync meeting. Developers should be syncing up with one another all day long. Roadblocks should be raised immediately. If an impediment arises, the Scrum Master should jump in to assist.
Here's by far the worst answer I ever heard for a Mid Sprint Check-in:
Our manager (or replace manager with Scrum Master, Agile coach, or Product Owner) wants it!
I have a problem with this. Where's the trust in our Scrum Team? Where's the spirit of self-management? Is there no respect for the Scrum Team as capable people able to self-manage and meet when needed? Do the Developers need to be micromanaged, or can they hold each other accountable as professionals?
There is no need to schedule a formal meeting in the middle of the Sprint to handle these situations - we have the Daily Scrum and constant collaboration instead. In a world of complexity, changes happen frequently and almost every day. Checking in with the team mid-Sprint only gives someone the illusion of predictability and of being in control.
The Mid Sprint Demo or Review Anti-Pattern
Some Scrum Teams are using a Mid-Sprint Demo or Review. This meeting is different than the Check-in. This meeting is typically put in place because the Scrum Team either needs feedback from the Product Owner or a stakeholder. Or it is put in place to solve another problem: the Sprint Review isn't effective or being used as intended.
Often I see this meeting put in place because the absentee Product Owner, a Product Owner who spends too little time with the Scrum Team or is unavailable most of the day. One of the biggest complaints I hear from Scrum Teams is that their Product Owner is rarely available, so they schedule a demo with the Product Owner to get feedback. Scrum Teams need fast feedback and shouldn't have to wait until mid-Sprint. The lack of availability of the Product Owner is the impediment that the Scrum Master needs to help resolve. Don't mask this impediment with another meeting.
Often I see this meeting put in place because the absentee Product Owner, a Product Owner who spends too little time with the Scrum Team
If the problem is that the Scrum Team needs some ad-hoc feedback on a completed Product Backlog item from a stakeholder, anyone on the Scrum Team, including Developers, should be able to talk to the stakeholder. There is no need to schedule yet another formal meeting. Go off and gather that ad-hoc feedback as soon as possible.
We have a formal Scrum event for getting feedback called the Sprint Review. Scrum events are in place to minimize other meetings. If stakeholders met to give feedback at a Mid-Sprint Demo, would they want to attend the Sprint Review since they've already collaborated? Moreso, things change rapidly in the world of complexity - don't set false expectations from the time the Mid-Sprint Demo takes place to the end of a Sprint. Anything can happen during the rest of the Sprint, impacting results. The Sprint Review is a better place to inspect the Increment with everyone. Don't get me wrong, an ad-hoc conversation with a stakeholder can be valuable now and then. Yet wouldn't it be better to ensure all stakeholders are available at the Sprint Review so that a more divergent set of opinions and feedback is given? Might transparency be lost in this Mid-Sprint Demo if everyone wasn't there to inspect the product increment together and to share and hear everyone's feedback?
There's also the myth that the Sprint Review is a "demo". And worse, others have misunderstood that the Sprint Review is for the Product Owner to approve work done in the Sprint. If your Scrum Team is treating the Sprint Review as simply a "demo" for your Product Owner and don't have stakeholders in attendance at the end of the Sprint, or if you use it for Product Owner approval, you're missing the point of the Sprint Review. It is way more than a "demo". The Sprint Review is a collaborative working session between the Scrum Team and their stakeholders. Everyone inspects progress towards the Product Goal and the latest product Increment and provides feedback (the good, the bad, the ugly). They discuss what to do next and adapt the Product Backlog. They discuss marketplace changes, forecasts, and the remaining budget.
The Antidote
So what's the solution?
- Drop these other meetings, and get back to the basics of Scrum by using the four container events more effectively. A Scrum Master is a servant-leader who upholds Scrum by using the teaching stance to help everyone to understand the purpose of the Scrum events and to find better facilitation techniques to make Sprints more effective. Here is a refresher on how to facilitate the Scrum events.
- A Scrum Master can observe throughout the Sprint and use the Sprint Retrospective to make any challenges transparent, and then work with the Scrum Team to improve the events or collaboration between the Developers and Product Owner.
- Many Scrum Team treat the Sprint Goal as if it is optional. It is not - it is a commitment. Ensure your Scrum Team is crafting a Sprint Goal in Sprint Planning and that the Developers inspect Sprint Goal progress and replan their work for the day in the Daily Scrum. This alone should eliminate check-in meetings.
- If your Product Owner is seldom available, this is an impediment for the Scrum Master to focus on. Start by having an open conversation with the Product Owner and Developers. Let them know the impact of delayed feedback and decision-making. Your Scrum Team needs an engaged Product Owner to be effective. The Product Owner is critically important and is often needed full-time on a Scrum Team.
- Encourage collaboration with stakeholders, and let your teammates know that interacting with them is okay and that they never have to wait until the end of the Sprint to ask questions.
- Work with leaders who are suggesting the Scrum Team hold these meetings. Help leaders understand the importance of a self-managing team and that mandating such a meeting goes against the grain of self-management. Help leaders and stakeholders to trust the Scrum Team and live by the Scrum value of respect. Let's leave the Developers alone to get work done and trust them as professionals.
- Every Sprint is a feedback loop. Ask the Scrum Team if shorter Sprints would be beneficial. Try shortening a Sprint from a month to two weeks or two weeks to one week.
Let's leave the Developers alone to get work done and trust them as professionals.
Conclusion
The Mid Sprint Check-in, Demo, or Review: these meetings make Scrum much less effective while giving the illusion of control and predictability and may be masking other problems.
If Scrum is being implemented effectively, the Scrum Team has everything it needs within the five prescribed Scrum events to deliver on the Sprint Goal and at least one valuable and useful product Increment. Ensure there is an engaged Product Owner. Organizations need to trust and support Scrum Teams. Coach leaders and others outside the Scrum team on better ways to interact with them. Help remove systemic and organizational impediments.
But don't add another meeting to their calendars - you're probably covering up an impediment. Your Scrum Team doesn't want another meeting on their calendars and will thank you for it.