Agile process, assigning estimated tasks to people in a Sprint

Question

Today I was surprised to hear that our Scrum Master and Product Owner decided that they wanted us to consider a change to how Sprint Planning was done. The change essentially is that all of the Stories would be broken down into tasks, assigned estimates, but not assigned to a specific resource.

To me, this basically blows up the accountability aspect of the process, and there is a high probability of a bunch of un-assigned tasks being left un-finished in the sprint.

Part of the deal with Agile is that as a Developer I commit to the work I will do in the Sprint. Even if production issue or unknown things happen during the sprint. If it is a big enough disruption, the team steps up and helps or some work is pushed into the next Sprint.

Am I wrong in that this approach is not good? Are there any positives to this approach I may be missing? How does a resource measure how much work they have left to do in the Sprint?

FWIW: We do not have dedicated roles here. We are a smallish shop where a developer can do production support, BA work, QA, etc. Everyone on most of the teams are wearing multiple hats.

Answer 1

Not pre-assigning the tasks to people is the correct approach in Scrum. The concept of "committing to the sprint goal" has been deprecated somewhat since the original version.

The idea is that when you finish a task you select the next highest priority one, rather than skipping over those pre-assigned to other developers. This means that if one Task ends up taking longer than expected, it doesn't hold up other high priority tasks.

It also prevents some human problems such as developers grabbing all the "good tasks" at the start of the sprint and leaving others with the boring or no tasks to do.

It promotes cross training and team work over key worker reliance.

In practice though I think there tends to end up being some unofficial task assignment. Developers end up owning 'their' code, I wouldn't try and enforce it too rigorously.

--Edit:

So from your comments it seems that your objection is based on the fact that without preassigned tasks individual developers don't have control of how much work they will individually have to complete for all the tasks in the sprint to be completed by the end of the sprint.

However, from a management perspective this is not a good thing.

• A fast developer that finishes all their tasks can go home early, even if a slow developer is still on their first one!
• A slower than expected task holds up high priority items assigned to the same developer
• Developers are not exposed to each others software. "I can't do that task its X's code"
• If a developer leaves/is ill/on holiday who does their tasks?

Management wants the most high priority task in a sprint to be finished as possible. Pre-assigning works against that.

Also, estimation is a problem. With preassigned tasks, if i estimate that my tasks are all super hard and I can only fit 2 in the next sprint, but somehow, someway I work extra hard and struggle to get them both finished on time there is no way to know whether I worked really hard, or just overestimated the tasks and took it easy.

The developers are incentivised to over estimate.

With a pool of unassigned tasks the estimation is shared amongst the team and the 'best' developer is the one who completes the most points.

The developers are incentivised to estimate fairly and complete tasks