Skip to main content

Unassigned tasks

Last post 01:51 am June 12, 2019 by Swati Pathak
4 replies
09:03 am June 10, 2019

Bunch of tasks remain unassigned till half of the sprint is over, sometimes remains unassigned and undone too.

Developers prefer to wait how the task goes in hand, which I feel is wrong, because its already estimated after a long thought. I think they should assign all the tasks based on the capacity, instesd of leaving it open. Am I correct ?


10:08 am June 10, 2019

Bunch of tasks remain unassigned till half of the sprint is over, sometimes remains unassigned and undone too.

There's nothing wrong with work from the Sprint Backlog remaining unassigned. However, if the work remains undone at the end of the Sprint, that may be something to investigate and discuss at the Sprint Retrospective. It could indicate any number of problems in the process that should probably be addressed. Something else to consider, though, is the Sprint Goal - even if work is left in an undone state, has the Sprint Goal been accomplished by the Development Team? Repeatedly failing to achieve the Sprint Goal is, in my opinion, an even bigger issue than having undone items in the Sprint Backlog.

Developers prefer to wait how the task goes in hand, which I feel is wrong, because its already estimated after a long thought. I think they should assign all the tasks based on the capacity, instesd of leaving it open. Am I correct ?

The Development Team is the only one who can determine the work brought into the Sprint and negotiates with the Product Owner regarding the size of the Sprint Backlog and the Sprint Goals for each Sprint. The Development Team is also the only one who can decide how to perform the work in the Sprint Backlog.

Personally, I've seen teams work in different ways. Some teams do identify a primary person, and sometimes a partner to ensure skill training and cross-functionality early in a Sprint. Other teams leave Sprint Planning with a few items assigned and the rest unassigned. The decision has to come from the team, though - they are a self-organizing entity.


11:25 am June 10, 2019

Bunch of tasks remain unassigned till half of the sprint is over, sometimes remains unassigned and undone too.

If there was a pull-based workflow, wouldn't you expect many of the tasks to remain on the Sprint Backlog half-way through the Sprint? What problem are you actually trying to solve? Are the team meeting their Sprint Goals?

Developers prefer to wait how the task goes in hand, which I feel is wrong, because its already estimated after a long thought. I think they should assign all the tasks based on the capacity, instesd of leaving it open. Am I correct ?

Why do you think that assigning work based on capacity, rather than pulling work based on capacity, would help?


03:43 pm June 10, 2019

I actually coach that tasks are not assigned and are instead taken.  @Ian mentioned, working in a pull system based on capacity is actually something I have see be much more effective.  Assigning all work at the beginning can result in one person finishing all of their tasks and taking the "I have nothing to do" stance.

@Thomas and @Ian both touched that focusing on task assignment and completion is probably not the best use of your time.  Focus on the accomplishment of the Spring Goal.  How the Development decides to self-organize the work is entirely up to them but accomplishing the Sprint Goal is the responsibility of the entire Scrum Team.

Like @Thomas, I have had teams operate in different ways and none of them are more "right" than the other. It is all up to the Development Team to decide what is best for them. 


01:51 am June 12, 2019

Thanks a lot, for your precious time.

I am very clear now. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.