Agile Software Development

How to Fix Three Mistakes Scrum Masters Make

Everyone is fallible, except maybe Mr. Rogers or Fonzie from Happy Days, and neither of them was ever a scrum master. That means everyone is going to goof up in scrum at one point or another. So in a post at Mountain Goat Software, Mike Cohn describes three common mistakes scrum masters make and how to fix them:

  1. Letting work drag on into the next sprint
  2. Actively running the daily standup him or herself
  3. Allowing a team to burn out


Not all work is always going to get finished on schedule in every sprint. But it should the large majority of the time. If you allow spillover to become a habit, then it defeats the purpose of doing sprints at all. The good news though is that habits can be broken. To do this, Cohn says to first plan one sprint that is purposely light in order to guarantee that all the work gets done for once. Then gradually add on more work until the team finds its sweet spot. But in the meantime, Cohn also says to make the team feel “just a little bit guilty” about not finishing their work. After all, time is money, and the business is counting on their output.

Another mistake is when scrum masters take it upon themselves to run the standup every day. It is going too far if scrum masters manage the meeting like this. Instead, they should just ensure that everyone understands the rules of standups and then allow the team to run it themselves. Over time—and from the scrum master’s initial silence—the team will realize it needs to get the ball rolling themselves. Scrum masters can still of course chime in when they think clarification on a topic is needed though. But Cohn challenges you to imagine that an outsider walks in on your team during the standup—if that person is unable to identify who the scrum master is, then you are probably doing a good job.

The last mistake Cohn addresses is allowing your team to burn out. Teams should work at a sustainably high pace, not an ever-escalating pace that causes people’s hair to fall out. Toward that end, Cohn suggests this idea:

… 6 x 2 + 1 (“six times two plus one”). This 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. Some people will use it for personal development (reading, video training, etc.). Others might use it to refactor some ugly code that the product owner hasn’t prioritized. 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 product owner now has a week without any “distractions” from the team. This is often the selling point that gets a product owner on board with this.

You can view the original post here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.