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.

  • What do you mean by "admin task"? Are these all IT/infrastructure/system administration tasks? Or is there more to it?
    – Thomas Owens
    Commented Apr 25, 2012 at 17:56
  • Would be great if you can make your final question more specific, like "What administrative tasks can I do to minimize the team's dependency on X?" The way you've worded your question (i.e What tasks do you do for your team...) moves it dangerously within polling territory. Can you please edit it? It's a great question otherwise, and I think you'll get better answers that actually solve the problem rather than just simply surveying the community for information that may or may not solve a problem. :)
    – jmort253
    Commented Apr 25, 2012 at 22:01
  • Ok, this wasn't as hard as I thought to fix :) I edited the last paragraph for you, and I edited the question title. I'm sure I didn't lose the vibe or main idea of your question, but if so, please feel free to edit more and clarify! Great question! +1
    – jmort253
    Commented Apr 25, 2012 at 22:07
  • @ThomasOwens it's just like you've said. For example updating production database is one of those. Commented Apr 26, 2012 at 8:20
  • 1
    @jmort253 I got your point, you're right. Thanks for editing :) Commented Apr 26, 2012 at 8:29

5 Answers 5


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.

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.

  • as you write, adding tasks to jira is not a big deal. But for me it's like doing something in place of a team and I want to avoid it. On the other hand doing so may speed up a team a little bit, don't you think? Commented Apr 26, 2012 at 15:00
  • I agree. I got the feeling that the team didn't want to add tasks? I think it may very well be a good idea for you to do it, as long as the team realizes they are responsible, and add tasks to Jira if you're not there, or have better things to do :-)
    – Magnus
    Commented Apr 27, 2012 at 6:17

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!

  • I like your suggestions. The concept to put administrative tasks on board has run through my mind and after you answer I think I have an idea what to do...:) Commented May 2, 2012 at 9:34

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.

  • Thanks for the answer. In my question I didn't suggest, that Scrum Master PERFORMS any of those tasks. What I meant was that there is a tool to maintain them and, in this case, should Scrum Master or the team create those tasks? I believe, that it can boost team performance, as Scrum Master takes care of tasks that do not give business value to the customer and team may focus on such. But is adding-business-value a good criteria to decide who should perform administrative stuff? BTW, personally I don't agree that SM role may be played by someone on dev team. There's no healty distance then :) Commented Apr 26, 2012 at 11:37
  • @BartekKobyłecki Can you edit your question, then, be more clear? Your title is As a Scrum Master, what sort of administrative tasks should I do and what should the team do? and in the comments I asked what you mean by administrative tasks, and you said that it refers to IT/system administration tasks like working with databases. There's a difference between process tasks (working with stories, maintaining the backlog) and IT tasks (database administration, configuring hardware, deploying to production environments). Exactly which task are you asking about, since I'm no longer clear on it?
    – Thomas Owens
    Commented Apr 26, 2012 at 11:45
  • By administrative tasks I mean: creating JIRA tasks for sprint (not performing them), creating tasks for administrators team (not performing them). Commented Apr 26, 2012 at 14:53
  • @BartekKobyłecki Can you edit the clarification into your question? I'll update this answer when I get a chance to.
    – Thomas Owens
    Commented Apr 26, 2012 at 15:22
  • as I can see this question is understood by others in community, which I conclude from the answers. I've changed 'do' into 'perform' in description after you suggestion. Commented May 2, 2012 at 9:24

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.