Unassigned tasks

Last post 01:51 am June 12, 2019
by Swati Pathak
4 replies
Author
Messages
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.