Roles in scrum are Product Owner, Scrum Master, and Scrum Team. A user story should also break down into smaller pieces called tasks. A task seems to have four phases, namely, definition, assignment, implementation, and following.

Who should do what in Scrum about tasks? Is it the responsibility of scrum master to update remaining hours of a task, or is it the responsibility of the developer (scrum team)? Should developers assign tasks to themselves or is it the responsibility of scrum master accompanied by product owner?


Agile follows several principles. One of them is: Empower people. Because of that tasks should be defined by team and tasks should be selected by team members. Tasks should not be assigned to team member. The team should be self organizing and because of that distribution of hard / easy / interesting / boring tasks should be even.

Scrum master should ensure that team follows Scrum principles. He is not a project manager.

This is theory and it works for mature teams. For Scrum beginners it can be sometimes hard but you should at least insist that team members will select task themselves instead of assign them.

update remaining hours of a task

In my opinion estimating tasks and maintaining remaining time is waste. You did commitment on set of user stories so it doesn't matter how long will each task take. The only important is if user story will be completed or not.

  • 3
    I disagree that estimating tasks and maintaining remaining time is a waste. I found that that the "remaining time" is the best early warning sign you can get when things start going unexpectedly. It doesn't have to be super accurate, but the Scrum master needs to be aware if an estimate is A) not changing or B) increasing. This can often happen if there is a hidden (even to the developer) impediment. In a new scrum team this helps with the transparency also, and helps prevent the "I did x yesterday, I'm going to do more x today" stand up. – Brook Aug 1 '11 at 14:59
  • @Brook: That is the reason why Scrum uses Burndown chart. If you use burndown chart to show completed user stories (with complexity defined by story points) you will still have such feedback. In my experience that feedback will be even better because you will not end (example) with 10 hours of not completed work which means 10 user stories with each 1 hour missing. – Ladislav Mrnka Aug 1 '11 at 15:05
  • If I could I would give this answer +10. Spot on, absolutely correct. – wolfgangsz Aug 1 '11 at 15:41
  • @Ladislav Mrnka: You will get similar data out of the burn down, but having the work remaining gives you finer detail, and can warn you sooner. It's a moot point if all your tasks take < day, but occasionally when a task does take > 1 day, the work remaining can give a quick indicator as to whether or not to be worried. I typically don't ask people to give it a ton of thought, just whatever their gut feel is, so it's not that cumbersome of a metric to add. – Brook Aug 1 '11 at 18:23
  • Sooner? Sprint should be "short" - how sooner should you be warned? I used very simple rule. If we don't have at least 1/3 of user stories (story points) done at the half of the sprint we will most probably not be able to deliver everything we committed. It worked quite well and we didn't have to estimate anything. With sprints taking 2 or 3 weeks you don't need much more. – Ladislav Mrnka Aug 2 '11 at 19:59

Should developers assign tasks to themselves or is it the responsibility of scrum master accompanied by product owner?

I places where I've worked that have followed Scrum we've done both, though ideally developers should pick their own tasks. Ultimately it doesn't matter as long as all the tasks get done.

There are pros and cons to each approach.

Letting the team pick their own:

  • pros - the team feel ownership of the task, they pick ones they feel they can do a good job on. Ownership is an important aspect of development that a lot of people overlook.
  • cons - some tasks are left until the end when they would be better off done first.

Having tasks assigned:

  • pros - all tasks are considered equally and none are possibly left out.
  • cons - the team members don't necessarily feel ownership of the task.

In real life you need to take a pragmatic approach. There will be times when tasks have to be assigned, but these should be few in number.

  • +1 - for someone having the final say. Someone has to be in charge. – JeffO Aug 1 '11 at 12:32
  • 2
    I appreciate that a certain pragmatism is a useful thing, but assigning tasks to developers is definitely NOT the Scrum way of doing things. – wolfgangsz Aug 1 '11 at 15:39
  • @ChrisF: Can you clarify where in Scrum it says that ScrumMaster has overruling authority and that others are allowed to assign tasks for the developers? – Martin Wickman Aug 1 '11 at 21:04
  • @Martin - no I can't. Mainly because it's been a while since I worked with Scrum. However, the pragmatist in me states that at some point someone will have to make a decision. – ChrisF Aug 1 '11 at 22:34
  • A little late in the game, but my 2¢ - I think if some tasks are left to the end when they should have been done first that means that your Scrum Master (and Product Owner) aren't putting enough emphasis on those tasks. – Wayne Werner Feb 1 '12 at 19:31

In our scrum process, we do the following:

The tasks are defined by the group of developers, who most likely will be implementing the user story.

At least two developers are responsible for the implementation of a user story, hence they will be assigned to the tasks automatically (if they can work in parallel, they will take a task most suited to them according to their knowledge and personal flavor. Otherwise they will pair program).


Who updates remaining hours of a task?

Only the developers can know how much work remains, so they provide the information. Exactly who updates the hours is not important.

Should developers assign tasks to themselves?

Yes. The act of selecting tasks for yourself is powerful because it makes you strongly committed to completing it in a way not possible if someone else would assign it for you.


Scrum Guide

Everything to do with tasks is the responsibility of the team in Scrum. The team will generally come up with a decomposition of stories into tasks during the second half of the sprint planning meeting but new tasks can be introduced or tasks can be removed at any time during the sprint as new information comes to light. In my opinion, this daily feedback loop is an important part of Scrum.

The ScrumMaster is not the team lead or its manager. The role of the ScrumMaster is to facilitate the Scrum process and remove impediments. The ScrumMaster does not assign tasks to developers. The product owner does not assign tasks to developers. The team delivers value to the produt owner (and by extenstion the customer) by implementing the user stories.

The team is responsible for all estimates. So it owns the estimates for the tasks (and stories) on the board.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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