Scrum Masters can sometimes fall into the trap of managing the process rather than coaching the team. While it might seem helpful to update tickets, close backlog items, or move tasks around, this kind of administrative work actually disempowers the team and takes the Scrum Master away from their real job: helping people grow, removing obstacles, and improving the adoption of Scrum.
Developers on a self-managing Scrum Team should be responsible for keeping the Sprint Backlog up-to-date. Developers should update their own tickets as they work rather than relying on the Scrum Master to do it for them. This ensures transparency, keeps progress visible in real-time, and prevents the Scrum Master from becoming a bottleneck.
But updating Sprint backlog items isn’t the only clerical task that Scrum Masters mistakenly take on. Here are some other common examples:
Creating and Managing Tasks
Some teams create tasks to break down work within a Product Backlog item. This is a great practice, but developers should be the ones adding and adjusting their own tasks—not dictating them to the Scrum Master. When developers create and update their own tasks, they can refine their plan as they go, adjusting to new insights and changing needs. This also increases transparency, allowing any team member to check the Sprint Backlog at any time and see how their teammates are approaching their work.
2. Handling Security Requests
When I was a new Scrum Master, I wanted to help my team, so I volunteered to submit all their security requests. It didn’t take long for me to fall behind. At one Daily Scrum, it became clear that developers were waiting for me to submit their requests, and it was causing delays to their work. After several days of this, someone finally asked, "Can’t we just submit our own security requests?"
Of course, they could - and they should have been doing it all along. By trying to be helpful, I had actually made myself into a roadblock.
3. Managing Stakeholder Communication
Some Scrum Masters act as gatekeepers between the team and stakeholders, thinking they are protecting their team’s focus. I once had a Scrum Master tell me, “No one should talk to the developers except for me!” While the intention may have been good (although that is debatable), the result was an unnecessarily bureaucratic process that harmed collaboration and frustrated stakeholders. Instead of fostering teamwork, this approach created an adversarial relationship.
Developers should be able to engage with stakeholders when needed - especially when collaborating to deliver the Sprint Goal or refining backlog items at the Product Owner’s request. At the same time, stakeholders should go to the Product Owner for new work requests since the Product Backlog remains the single source of requirements. The key is to enable direct collaboration without undermining the Product Owner’s accountability.
The Real Work of a Scrum Master
Rather than focusing on clerical work, Scrum Masters should focus on coaching their teams to be self-managing. This means:
Helping team members identify and remove blockers, rather than simply tracking them.
Encouraging direct collaboration, rather than becoming a gatekeeper.
Creating an environment where developers take ownership of their work, rather than relying on the Scrum Master to maintain process compliance.
By shifting away from administrative tasks and toward coaching, Scrum Masters help their teams become truly self-managing. This builds accountability, improves collaboration, and allows the Scrum Master to invest time where it actually makes a difference—helping the team deliver value.
Rebel Scrum is the host of the annual Scrum Day Madison conference, scheduled for October 16, 2025, in Madison, Wisconsin.