0

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.

Improve this question

1 Answer 1

Reset to default
3

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

Improve this answer
16
  • How does this address the commitment part? How do I use my tool ( Version One, DevOps, etc. ) to see how I am doing in my Sprint? I appreciate the answer, not sure I agree or if its correct.
    – user255194
    Mar 27, 2019 at 16:15
  • 1
    You don't "commit to your work" anymore, the team estimates what will be achieved in the sprint and works together to attempt to achieve it.
    – Ewan
    Mar 27, 2019 at 16:18
  • This is interesting....the team doesn't write code, a resource does.
    – user255194
    Mar 27, 2019 at 16:19
  • Maybe you could outline your problem with it a bit more. I mean you still get tasks each sprint, you still estimate as a team etc you just dont know which tasks you will end up doing in advance
    – Ewan
    Mar 27, 2019 at 16:19
  • 3
    The commitment comes from the team. Individuals in the team hold each other accountable. This requires a higher level of support and interaction inside of the team, but also leads to better teamwork and consistently results in more effective teams. To Ewan's point, the word commitment has somewhat fallen out of favor because sometimes commitments are used in a dysfunctional way. In a healthy company, we could safely call targeting work and trying to achieve it commitment.
    – Daniel
    Mar 27, 2019 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.