As a Scrum Master, what sort of administrative tasks should I do and what should the team do?

Question

I have a 'do it myself or leave it for the team' dillema for some sort of tasks.

Let me introduce an example, to be clear what I mean: there is a team, which uses jira* as a task container. Every sprint tasks are created in this tool.

After technical planning meeting, where team divides stories into tasks, there are plenty (15 or so) of them to create. Sometimes there is nothing to describe within them, but there are also more complicated, which require some additional technical information.

The other example are admin tasks. In most cases they have to be done for the sake of new features hence are created by dev teams. Admins are outside of dev teams and it is one of their duties, to resolve tasks that concern infrastructure. Sometimes admin tasks are known before sprint is started, sometimes they appear during a sprint. In each case they need to be well described, to make sure that responsible admin will know what to do.

There could be many similar tasks to the ones mentioned above. My intention is to find a pattern (as I believe that there is no the only solution) when they should be created and described (not performed) by Scrum Master and when by the team.

So, I'm wondering what administrative tasks should I as Scrum Master do for the team and what are rules should I follow in this regard? My own purpose is to minimize team dependency (ie Scrum Master is not in the office on planning day, and the sprint is dead on start).

* Jira is a must, because it's a part of larger tool, which automatically delivers code on test environment.

Answer 1

For me the answer depends on your actual role and future plans.

1. If you consider yourself as a by the book Scrum Master, then raise this issue after a team meeting - possibly after the daily gathering - and let the team care of the administrative tasks. Unfortunately, software development is not just about writing software, there are other tasks one has to take care of. It is their task now.
2. If you consider yourself as Scrum Master, who is part of the team, then you also have to raise the issue saying that this may not be the best assignment for you. However, it may happen that you'll still have to do the tasks, because the team may decide that you are the best person to do it.
3. If you are a coach who has happened to be called a Scrum Master, then find out whether the task creation adds any value to the team's work. If the answer is 'yes', then find a way how to mentor the team so that they can do the minimum of these activities by their own - I somehow feel that these tasks don't add too much value to the whole.

Answer 2

The team owns the sprint backlog, and they should be collectively committed to succeed with the sprint. This means they should also take responsibility for adding necessary tasks to whatever tool is being used.

Perhaps it is more efficient to let the scrum master do some administrative tasks to facilitate for the team, but this doesn't mean the scrum master is responsible for the sprint backlog.

Adding administrative tasks to Jira sounds like a small task, and if doing this becomes a problem (people refusing to do it) it seems like you have more serious issues to deal with. I suggest you bring it up on the next retrospective.

The important thing is to come to an agreement everybody commits to.

Answer 3

In every team, there's usually one role which is the busiest. In software teams, in my experience, it's either been the developer, or the tester.

To help the team be as effective as possible, get as much of the work out of the way of the busy role as you can (Theory of Constraints). If the devs are always busy, and they don't need to do some piece of work themselves, then they should feel able to pass it off to whoever has time. Similarly with the testers, if they're the constrained role.

There may be some administrative tasks that they feel they need to keep - for instance, writing technical details may help them to clarify what they need to do in their own minds. However, forcing busy people to do something that's of no benefit to the work being done is wasteful. Ask the team which tasks they'd like you to do.

If you're looking for a pattern that will help you work out when the developers have time or when the testers have time, consider implementing a pull system like Kanban, with its limited work in progress. Cumulative Flow Diagrams (aka Finger Charts) are also a good way of spotting a widening gap which indicates a constraint. You can even put the Scrum Master and Admin tasks on the board, so that developers can see if the work starts piling up and you become the constrained role, so they can take some of the work back for themselves - but I've never seen the Scrum Master become the constrained role yet!

Answer 4

The purpose of the Scrum Master is to enable the team to perform at its highest levels by managing the process. The common tasks associated with this role include working with the Product Owner to ensure that the backlog is properly filled with appropriately written user stories, to ensure that the team doesn't overload with too many story points or underload with too few story points for a sprint (balancing workload with projected value added), guiding the retrospective and planning meetings, and generally resolving any roadblocks that arise during the project to make sure that the team can move forward.

The optimal solution would be to integrate the system administrators and IT staff into the Scrum process as part of the cross-functional team, with associated stories and tasks in stories. Another solution might be to treat the administration team as a black box that must complete assigned tasks, and the Scrum Master would just ensure that the team has what is needed to complete each story within the sprint.

How the stories get added to the backlog doesn't matter that much. Those that are known at the beginning can be added to the sprint backlog immediately during the planning meeting. Like you mentioned, some tasks might not be known at the start. The person who needs the task can ensure that it gets added, and could probably do a better job of describing what needs to be done to properly meet the requirement and deliver the feature.

As Scrum Master, your first job should be to make sure that stories get added and tracked by the person or people who are best capable of writing them. That could be the Scrum Master, that could be a developer. Then, the Scrum Master needs to follow up with the administration team to make sure the tasks are getting done on schedule. All of these would fall under "helping the Development Team to create high-value products" and "removing impediments to the Development Team's progress", both of which are services that the Scrum Master provides to the Development Team.

There are a number of posts about the Scrum Master position on the Mountain Goat Software blog, if you want to read more about the role itself.

Answer 5

I made it quite clear from the beginning that being a Scrum Master doesn't equal being the secretary / admin of the team. With this I avoided situations like, when for example there are no markers available, everyone would turn to me to put a ticket to Office Management.

What we agreed on is this:

1. User stories are written by the devs. There is no question there - the Scrum Master doesn't write any user story, it's not part of our job and it doesn't help the devs write good user stories. They own the Sprint Backlog afterall. I am there in case they need advice.
2. Admin tasks are done through rotation by members of the team. The rule is though, whoever sees a needs first, tries to solve it. If I collect needs from 15 people, my job will be to run around and solve admin tasks, which is not the SM's job.
3. HR stuff: hiring, induction etc. is owned by the devs - mostly Seniors. It's part of the job in the end.
4. Anything else is discussed and agreed with the team, making sure that all roles present are considered equally (the SM role is not less important than the dev or the PO and so on).
5. We also have a general weekly meeting - with the entire team, all Scrum teams - where we discuss needs, challenges, issues. Here we appoint a person to solve many of the issues (rotation again).

Scrum teams are self-managed. That means if a problem arises, it's not the SM who's meant to solve it, the SM has to help the team come up with a fair solution. If you jump in and do the work for them, solve anything that comes up, you're not a Scrum Master, but a Personal Assistant. And there is no learning for them there - to act like a true self-managed team.