3

Currently in our project the situation is that we can have several goals. And it works fine for us to make a team member responsible for acheiving a particular goal.

But recently I tried to pass "Scrum Open" test and saw a statement in one of the questions that put me in doubt. It was:

"Sprint Backlog and all of its items are collectively owned by the Development Team. No individual team member can claim ownership over an item as this would block communication and collaboration."

So I wonder: is it ok to make a developer responsible for a goal in Scrum? Does it break any of Scrum rules? What disadvantages could be there?

Improve this question

3 Answers 3

Reset to default
4

No

Scrum upholds the following principles and recommendations that go against this practice.

  • Team responsibility - The team commits to the sprint goal, the individual members commit to the team.
  • Swarming - The team should work together on tasks when possible and sensible. Having 3 out of 4 tasks complete is preferable to having all tasks 3/4 complete.

Further concerns about assigning responsibilities:

  • This can erode team cohesion by making it feel more like working in their own little corner than like contributing to a common goal. There's nothing wrong with "assigning" work - not all tasks can be sensibly swarmed.
  • It can lead to specialization. Some specialization can be unavoidable in areas where you need particular talent or excellence but you should always strive for cross functionality. Having a team where everyone can do everything makes you more flexible.
  • It can suppress cooperation and coaching. Lets say two of your devs are struggling with their goals. One is reasonably sure he can do it, albeit just barely. The other one realizes he needs advice and guidance by the former. If they are personally responsible for their goals then the former is going to be less inclined to risk his own goal to help the other achieve his.
  • It can lead to jealousy and resentment when one dev consistently gets the "sexy" goals that are rewared with praise. It can then also lead to fighting over who gets which goal.

Obviously these are only dangers not prophecies. But what are you gaining for your risk?

Improve this answer
2
  • 1
    Swarming is not a principle in the Scrum framework, though it is commonly considered a best practice.
    – Alan Larimer
    Commented Nov 30, 2017 at 1:02
  • @AlanLarimer true, it's not an explicit part of Scrum but you could argue it's a consequence of the focus on creating value. Unfinished work has no value.
    – Kempeth
    Commented Nov 30, 2017 at 7:59
3

The Scrum institute definition of Accountability in a team is:

The Scrum Team as a whole is responsible to deliver the committed delivery in time and with the defined quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team.

In my personal opinion, if the whole team agrees to assign a goal to a specific developer and have them accountable for it, then the team must study the risk carefully, and make a plan B in case something went wrong and the developer couldn't deliver on time to avoid failing the sprint goals.

Scrum is about having a self-organized team, so in concept it's OK to assign a goal to a specific developer but the team must be prepared to the risks of the decision if any.

Improve this answer
4
  • 2
    I agree theoretically, but I've also never seen this done in a healthy way.
    – Daniel
    Commented Nov 26, 2017 at 23:27
  • 1
    This is basically what is happening more or less. But after some thoughts I agreed with @kempeth's concerns. And of course I will discuss it with the team!
    – Anton Belonovich
    Commented Nov 28, 2017 at 9:31
  • 1
    The team can collectively agree to give the in-Sprint work to a single individual, but cannot (per the framework principles) assign ownership of the backlog item to a single individual. The framework is quite clear that the Scrum Team owns all work, including the success or failure thereof, as a group.
    – Todd A. Jacobs ♦
    Commented Dec 1, 2017 at 17:25
  • This is traditional (poor) management and not within the rules of the Scrum framework.
    – Alan Larimer
    Commented Jan 29, 2018 at 23:37
2

is it ok to make a developer responsible for a goal in Scrum? Does it break any of Scrum rules?

The rules are defined in The Scrum Guide.

"They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality" Therefore a single Development Team member could be responsible for a single Product Backlog Item in the Sprint Backlog.

There is only one Sprint Goal. "The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment."

What disadvantages could be there?

Isolation silos, by function or even individuals, results in a disjointed effort, complexities in coordination, and waste through hand offs. "Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."

Improve this answer

Your Answer

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

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