TL;DR
The Scrum Master for my team cancels the daily stand up if we have another meeting that day...Is canceling the stand-up like this a good idea?
Like many things, the answer is "maybe." Generically, the answer should be no; the daily standups should be held regardless of whatever else you may have on the calendar that day. However, there are certainly extenuating circumstances based on whether the purpose of the ceremony has been obviated.
A list of examples and some sample decision-making criteria are provided below.
Different Ceremonies; Different Purposes
Hold Standups to Coordinate Work Increments
The daily standup is a meeting that enables the Scrum Team to coordinate the current day's work increment. So, the utility value of the ceremony is dependent on whether or not there is a daily work increment, or whether status updates and blockers are relevant to the 24-hour period in progress.
In other words, if there is work in progress or work to be done, you should not cancel the daily standup even if you have other ceremonies that day. However, there may be some legitimate exceptions. For example:
- If you have your daily standup at 9:00am every day, but your Sprint Review is at 9:00am on Fridays, then there's no point in holding the standup as there will be no work increment.
- If you have your daily standup at 10:00am every day, and your Sprint Review is at 2:00pm on Fridays, then there probably is value in holding the standup to discuss:
- The status of the previous day's stories.
- Sprint Backlog items related to the current day's Sprint Review.
- Any tasks that must be coordinated in advance of the Sprint Review demos that day.
- Any blockers that affect preparing for the Sprint Review.
- Any tasks, blockers, or issues that should be added to the list for the Sprint Retrospective.
Don't Hijack Other Ceremonies
However, you shouldn't cancel the standup just because you have other meetings. You don't want to hijack the focus of Sprint Planning, Backlog Refinement, Sprint Reviews, or Sprint Retrospectives to address things that belong in the daily standup. Doing so is usually a false economy that practitioners implement under the mistaken notion that skipping the meeting reduces overhead. In fact, it is likely to have the opposite effect, as team members fail to coordinate or must reimplement the standup (badly) outside of a formal ceremony.
Don't do that.
Guidelines for Choosing Slack Time Over "Efficiency"
Every meeting should have a well-defined purpose and an expected outcome. The purpose of the standup is for coordinating the current day's work increment for the whole team. Other meetings may focus on specific tasks, engineering issues, problem solving, and so forth, but they are not a substitute for the team-based dependency coordination that is the raison d'être for the daily standup.
However, if your Sprints are structured in such a way that there is no increment to be worked on that day, and no dependencies that need to be resolved or statused from the previous day, you should consider replacing that day's standup with the appropriate ceremony. For example, with Sprints that end on a Friday and start on a Monday:
- If you hold your stand-ups at 9:00am every day, you might hold the standup before Sprint Planning even though there's no work increment, allowing team members to coordinate about administrivia or intra-team action items resulting from a Sprint Retrospective.
- If you hold your stand-ups during core hours, you might replace the usual 11:00am standup with Sprint Planning on Mondays in order to give team members some slack time to do things like catch up on emails, update desktop tools, or other personal overhead or technical debt.
The key determinant is whether there is something to be coordinated within the team or not. Don't make the mistake of trading essential slack time for the false economies of the 100% utilization fallacy or a "savings" in meeting overhead that actually reduces effective communication within the team. Those are sure-fire ways to reduce the overall effectiveness of your Scrum implementation, so just don't. :)