Being a Scrum Master isn’t easy.
Give a team too much advice, and they’ll start relying on the Scrum Master to make every decision. But don’t give enough, and the team’s growth will stall.
Solve too many problems yourself, and the team may start expecting you to fix every issue. Ignore some problems, and they might not even inform you about impediments.
Scrum Masters must walk a fine line, and it’s easy to slip up. In this post, I’ll cover four common mistakes Scrum Masters make and offer practical tips to overcome each one.
Mistake #1: Letting Work Spill Over into the Next Sprint
One of the worst habits a Scrum team can develop is allowing work to spillover from one sprint to the next. This happens when a team fails to complete all the planned backlog items and simply rolls them into the next sprint.
“A Scrum team shouldn’t take a cavalier attitude toward failing to finish.”
While it’s okay, and even desirable, to not finish everything, every time—it means the team is planning ambitiously—it shouldn’t become routine.
A Scrum team should not take a cavalier attitude toward failing to finish. If it does, sprints lose meaning, becoming arbitrary boundaries rather than clear cycles of work.
Teams should feel a slight sense of urgency as the sprint nears its end.
How to Fix Spillover
If spillover is a recurring problem for your team, try these two things.
First, break the habit by planning hyper-conservatively for the next sprint or two. Encourage the team to plan its next sprint such that they can definitely finish everything. Then, if they finish everything, they can add more to the sprint.
Next, highlight the occurrence and remind teams that habitually not finishing is a problem. One way to do this is to bring it up in retrospectives and ask them to discuss why it happened.
I’m not suggesting that you make them feel bad or demoralized. I only want them to feel as concerned as I do right now. I’m trying to cut down on soda. I’m making progress and haven’t had any for a week. But today I just felt like having a soda while writing this. So I did.
I don’t feel guilty, but I’ll just make sure I definitely don’t have another tomorrow as I don’t want to get back in that habit.
Learn more in Spillover in Agile: 3 Ways to Break the Unfinished Work Habit.
Mistake #2: Running the Daily Scrum
A second mistake I see Scrum Masters make frequently is running the daily scrum meeting. While it's important for the Scrum Master to participate and give an update, they should not take on the role of conducting the meeting (for example, calling on people to speak).
Daily scrums do not need a traffic cop calling on people. When a Scrum Master runs the meeting that way, the discussion becomes too directed at the Scrum Master. A daily scrum is not a status meeting solely for the benefit of the Scrum Master!
“Ideally, an outsider observing should not be able to immediately tell who the Scrum Master is.”
It’s normal when a team is first getting started for the Scrum Master to take a more active role in the daily scrum. However, the goal is for the team to fully own the meeting. Ideally, an outsider observing should not be able to immediately tell who the Scrum Master is. While there may be occasional guidance, the Scrum Master shouldn’t dominate the meeting.
The Fix for Running the Daily Scrum
I like to start a new team by leading the first two or three meetings. Then, I transition to simply saying, 'OK, everyone, it’s time to start,' maybe prompting with 'Who wants to go first?' Soon after, I stop saying even that.
Eventually, I move to just checking my watch when it’s time to start and, if necessary, giving a gentle prompt—like clearing my throat. The idea is to gradually reduce my involvement until the team naturally initiates the meeting.
Of course, I don’t remain silent throughout the daily scrum. I may prompt someone to share more details or politely interrupt when discussions veer off track, saying something like, “Maybe we should dive deeper after the daily scrum.”
To dive deeper, read “Tips for Effective and Efficient Daily Scrums.”
Mistake #3: Allowing the Team to Burn Out
The third mistake I see Scrum Masters make is that they allow teams to go beyond a sustainable pace and burn out.
I’m not a fan of much of the Scrum vocabulary but the term sprint seems especially troublesome. When I sprint while running, I tire quickly and often walk to recover.
That’s a horrible metaphor for how we’d like the team to work. Ideally, one sprint ends and the next begins. Teams shouldn’t begin their next sprint still trying to recover from their last.
“Teams shouldn’t begin their next sprint still trying to recover from their last.”
Burnout happens when teams consistently overcommit during sprint planning, usually out of an abundance of optimism about how much work they can finish during a sprint.
How to Prevent Burn Out
The first thing Scrum Masters can do to prevent team burnout is to be on the lookout for teams (and team members) who seem to be committing to more work during sprint planning than they have historically completed inside a sprint.
Another great way for a Scrum Master to guard against burnout is by talking to the product owner about giving a team time to work on things of their own choosing.
I like to do this by introducing a cycle I call 6 x 2 + 1 (“six times two plus one”).
The 6 x 2 + 1 Sprint Cycle
6 x 2 + 1 refers to six two-week sprints followed by a one-week sprint. What the team works on in the one-week sprint is entirely up to them.
“What the team works on in the one-week sprint is entirely up to them.”
Some people will use the bonus sprint for personal development (reading, video training, etc.). Others might use it to refactor some ugly code that the product owner hasn’t prioritized. (Here’s some advice on how to convince a product owner to prioritize refactoring.and how to fit refactoring into your sprints.)
Still others might try an experiment that they believe could lead to a great new feature. But it’s entirely up to the team.
Introducing a cycle like this actually benefits more than just the team. The 6 x 2 + 1 sprint cycle gives the product owner a week without any “distractions” from the team, too. (This is often the selling point that gets a product owner on board.)
This cycle can also benefit the organization if it is one that needs to make commitments like, “We’ll deliver this set of features in 3 months.” The 13th week of the 6 x 2 + 1 cycle can be used for a normal sprint if the team gets behind on a deadline. The team can then be given a week for their own work a sprint or two later after the deadline has been met.
Mistake #4: Avoiding Difficult Conversations
Scrum Masters often find themselves navigating tough conversations, from addressing recurring issues to challenging misconceptions about agile practices. Avoiding these discussions can lead to unresolved problems and low morale.
How to Gear Up for a Tough Conversation
- Embrace Discomfort: Accept that uncomfortable conversations are part of fostering a transparent, high-performing team.
- Practice: Give thought to what questions you will ask and how you will approach the conversation. Role play with a fellow Scrum Master or even an AI agent.
- Prepare Thoughtfully: Consider multiple viewpoints and set clear goals before initiating a conversation.
- See It as Growth: Frame tough conversations as opportunities to build trust and team cohesion.
Final Thoughts
Great Scrum Masters balance guidance and autonomy, offer support without being controlling, facilitate without dominating, and face tough conversations head on. Mountain Goat is here to help, whether it’s AI prompts to help you practice or training to help you (and your team) improve, we’ve got you covered.
Last update: May 15th, 2025
