We are following scrum in our project. I see most of the times the scrum master allocates the tasks for us. However, I read from many scrum books that scrum works the other way around (the 'pull' approach) and team members pick up tasks or features. Is scrum master assigning tasks the correct approach or does it go against the agile ideology?

  • 4
    You are asking the question in a way the suggests you think there is a correct way to implement scrum. This is not how you should look at it. Scrum is a basic framework with some very generic guidelines. But every team and every project must adapt the guidelines to suit there current needs. Without a lot more details about your team it is impossible to give specific advice. Feb 22, 2011 at 8:29
  • +1 Martin - Exactly. It's a framework. No need to be dogmatic or purist in your approach. Feb 22, 2011 at 15:04
  • 4
    @Scout: A ScrumMaster acting as a command-and-control project manager is neither Scrum nor agile. Feb 22, 2011 at 17:58
  • @MartinWickman - He hasn't mentioned that the team feels they are being "commmanded". Maybe they've abdicated this responsibility and choose to focus on writing code instead of picking things to work on. "If you choose not to decide, you still have made a choice." Peart
    – JeffO
    Apr 13, 2012 at 15:15

6 Answers 6


According to the Wikipedia Article on Scrum, Sprint tasks are not assigned by the ScrumMaster:

Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in.

Furthermore, the definition of a ScrumMaster is that he/she is the person responsible for making sure people follow the rules of the Scrum process.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

The ScrumMaster does not assign tasks, plain and simple. The team is self-organizing, and decisions of who works on what is decided by the team.

This is true Scrum. Many organizations may of course use variations of this, however.

  • Yes. PO prioritizes. Team members estimate and select. Simple and powerful. Feb 22, 2011 at 18:01

That's the way it's supposed to work, but as with all things that work great in theory...it doesn't always actually work.

There's dependencies, customer wants, and drivers from the outside. Some things just have to get done before you can work on that fancy widget everyone wants to work on.

There's basic developer abilities driving from the inside. Some things are just hard and some people are just better. Sure, when working within an infinite timeline I can just let you figure it out; but when something's got to get done then assigning to the person best placed to get it done fastest and best is the one that's getting the job.

And then there's personality issues like over-controlling Scrum Master and/or developers who can't tie their own shoes without being told to. My team, for example, has both. Simply works better for everyone to ignore this little fact about Scrum in such cases.

In other words, don't just do it because the process says to. Do what works. Screw the rest.

Of course, then there's also the other basic fact of human existence....maybe you don't even know who the Scrum Master actually is. Maybe it's not the person with that title. Maybe you don't even have one.

  • "Some things just have to get done before you can work on that fancy widget everyone wants to work on." If this is an occasional thing, sure. If not, maybe you should be using shorter sprints - or maybe Scrum is not the right approach for your team. Dec 12, 2013 at 20:21


Scrum is totally clear on this. The Development Team, as a group, is responsible for completing the items in the Sprint backlog. They are also completely in control of how they go about getting the development done and nobody is allowed to tell them how to do it.

As a coach, the Scrum Master does have a role in pointing it out when he sees the Team is in danger of missing Sprint objectives for whatever reason. But then he needs to ask them to figure out how they are going to deal with it, and then get out of their way.

Another approach could be to let the Team complete the Sprint, hold them responsible for the lack of results and then let it get discussed in the Sprint Retrospective.


Like any ideology, there are times when the rule book needs to be thrown away, or carefully ignored.

Use some judgement as to what seems appropriate. Just be careful about somebody becoming a de-facto project manager - or worse, bullying people into doing certain things.

There's a big difference between task allocation by dictate (you SHALL do X) and allocation by discussion and agreement. Sometimes the agreement might be lukewarm.

Then again, maybe the team needs directing... its hard to know.

However, I'd be concerned about any process at all that insists you must follow the process to the letter with no room for wiggle or judgement. Such a process is a substitute for thinking.

  • Thinking is hard and I can only do so much per day. May as well let something or someone else think about the little stuff. Feb 22, 2011 at 5:21
  • 1
    In scrum you delegate this responsibility to the team. You don't stop thinking. In fact you think collectively. So decisions are better.
    – user2567
    Feb 22, 2011 at 6:18
  • 2
    I went through a case where no one on the team would pull a task. Despite repeated attempts to encourage the initiative to just grab a card from the board, work would stop until I myself pulled the card and handed it over. I think that stems from a transition mentality. When the engineers are used to having assignments pushed on their plates, it can be hard to turn that around.
    – smithco
    Feb 22, 2011 at 6:20

In my opinion the scummaster shouldn't do that, team members should themselves pick up tasks. If the scrummaster is only doing the administration as is the case in our team is see no problem. Our scrum master makes sure the paper scrum board stays in sync with the excel file. The role of scrum master should be a facilitating one we're he/she makes sure you can do your work unhindered. This is the way we work. Do you know why your scrummaster does this? Is he a project manager afraid to become obsolete? Is he afraid the team will not pick up tasks themselves? It might be a good idea to discuss this during a retrospective.


I've been a scrum master in both types of environments (where I pushed tasks to individuals and where individuals pulls tasks).

O the Push team, the development resources were not interchangeable. The Windows Client work had to go to the windows developer and the web work to the web developer. So I was able to push tasks to resources during planning sessions. I was also able to do individual capacity planning to know when to stop pushing.

The pull method worked well on a team where any task could be picked up by any resources. But, I couldn't do individual capacity planning during the planning session, instead I had to depend on average velocity to know when enough was enough. (It took ~3-4 sprints before we had a good idea on velocity).

I came across an interesting article outlining pros/cons of Push vs. Pull.

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.