[Open Assess Question] Development Team members volunteer to own a Sprint Backlog item:

Hi Alexandre,

I think, the key word here is "own". In Scrum, the owner is ultimately responsible for his estate. No one else can tell him how to handle it.
But for the Development Team the shared ownership is important because it
- protects the individual from "punishment"
- fosters motivation of reaching the Sprint Goal
- enables and motivates all individuals to counsel and support each other
- decreases the probability that some Sprint Backlog Items are ignored
- increases the probability that side effects are detected
- is the only way, the team's commitment to the Sprint Backlog is valid.

Your suggestion to "check" the item as "Work In Progress by XYZ" is still legitimate - I think, it corresponds to "each [Sprint Backlog Item] may be done by an individual development team member".

What do you say?

Also, team ownership of Sprint Backlog items can help to limit Work In Progress. Single piece flow may even become possible. This improves throughput and can help to de-risk a Sprint as value is delivered earlier with a potentially more even burndown.

Hi Alexandre,

I see two reasons why a single team member should not own a Sprint Backlog Item.
1) To convert a SBI to potential releasable software according to the definition of done, it requires a very broad skill set. (requirement definition, design, coding, testing, integration etc etc).
2) When individuals own single SBI’s, the Dev team will miss out on collaboration. I can be that some single SBI are complete, but others are not. Jeopardizing the sprint goal and the concept of a releasable increment.

Hello all, sorry for late reply as i did not get notified by not check the "Subscribe" option.

@Anke:
- Can you explain the following sentence in another words? English is not my native language and I cannot fully understand it:

"In Scrum, the owner is ultimately responsible for his estate. No one else can tell him how to handle it. "

- Regarding your point, I can understand your arguments although it could be debatable that, for instance, an Individual "owning" a SBI could "- fosters motivation of reaching the Sprint Goal " by pushing himself to complete the task/SBI.
=====

@Ian:
- I understand your point. Indeed it could be an explanationg. Nevertheless, there are might be some SBI that do not have dependencies and could be accomplised different team members.
====

@Christiaan:
- Maybe I am not fully understanding Scrum. As I was writting a reply to your advice, I remembered the core-value of agile: COLLABORATION - so now I understand what the assessment question is asking and how I should respond.

@All:
Howvever, sorry for my struggle, should not an subset of the Scrum dev team be able to "own" certain SBIs?

Imagine that my Sprint Goal is to complete 3 new and independent features in an existing application, and considering that the Scrum Team is comprised by 4 dev members, would not be okay for sub-team A (2 members) attack on the hardcore implementation of feature ALPHA and sub-team B implement the feature BETA in the first weeks?
I do believe that the design should be agreed by all dev team members and testing done by automation and/or other sub-team

The reasoning for this approach would be faster development and human resourse optimization.

Thoughts?



Thanks in advance

Hi everyone,

This is my very first post, so forgive me if I have it all backwards. I would argue that the SBI's have to be owned by the whole team because the team is collectively responsible for reaching the goal: an increment meeting the definition of done. This can only be achieved with everyone contributing to the best of their ability and is more than simply a collection of all of the SBI's being 'done'.

I sail racing yachts, often our bowman (the guy/girl on the front of the boat) would make the joke that, as always, he had crossed the line first. This is amusing because the goal of the race is to get the boat over the line as quickly as possible, not which crewmember got over the line first. This of course depends on the bowman doing all of his tasks properly but more importantly, the entire crew need to work together. Collectively owning what needs to be done is the only thing makes sense, not individually owning part of what needs to be done because the individual items have no meaning unless seen as part of the.

Also, Alexandre mentions sub-teams, which is a 'faux pas' in Scrum, presumably for the same reason - a winning team does not benefit from a winning and losing sub-team. Feature ALPHA being finished faster at the cost of feature BETA taking longer results in a net loss unless the people working on ALPHA have no problem helping to finish BETA. With internal competition in the team, presumably the ALPHA team would hang back and wait for BETA team to finish.

@Dennis:
Hi,
I do understand your concern of non collaboration. My example was established for work optimization and scrum agile development. That being said, I believe that the Sprint goal is owned by all and work(sbi) can be delegated and, in a flexible way, transferred or shared by individuals and sub teams.

Thanks for your input :)

@Dennis: hey, that's a nice example - fitting and very vivid! :-)

@Alexandre:
I am not a native speaker either, sorry that my language confused you... Here my explanation:

Whenever the Scrum Guide speaks of ownership, the owner has the following privileges/duties:
- he is responsible for what he owns
- no one else is responsible for what he owns
- he can delegate sub-tasks but he can't delegate the responsibililty
- he can report the progress or state of what he owns (e.g. "Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.")
- no one else can tell him how to handle what he owns (e.g. "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality")
- others can only influence the "owned issue" by convincing the owner to do something with it

All these things must be shared in the Development Team.

It depends on what is meant by

"check" the item as "Work In Progress by XYZ"

.

If that is used to communicate to the team, then that is fine.

"Working on" and "owning" are not the same. The word "own" implies responsibility. In Scrum, the team has the responsibility to deliver, The team succeeds or the team fails.

Hi, does someone know what should be the correct answer here?

Pick 4 activities that are the responsibility of the Development Team.

Options are :

• Using Story Point estimations.
• Provide estimates
• Break down epic user stories into smaller ones
• Design software
• Make technical decisions
• Volunteer for tasks

I would say

• Provide estimates
• Design software
• Make technical decisions
• Volunteer for tasks

Thank you!

Since Story Points and User Stories are not mentioned anywhere in the Scrum Guide, I think the answer is obvious. But even with that I would question the validity of the question.  The last choice "Volunteer for tasks" is questionable.  It could be meant to allude to self-organization or self-management but it still doesn't seem right.  Also the mention of "the Development Team" shows that a minimum, it has not been updated to reflect the current edition of the Scrum Guide.