Question ( who is responsible , DoD)?

Nice question. I had that question and with some research I end up with below from Scrum Guide:

If the definition of "done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If "done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product

As I understand, if the DoD is not a part of conventions, standards or guidelines of the development organization then it should defined by Dev Team. Otherwise I don't know. So in my opinion A or B could be an answer.


Regards,
Aria

The SCRUM Guide states: "During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate."
So C is correct.

@Aria & Ludwig: Thank you for your early answers.

by re-reading the Scrum Guide I found also on page 12 ,14 what you addressed above.

May be we should differentiate between:

I) defining (initial creating) of DoD

II) adapting (mainly improving) of DoD

Is the following assumption correct?

I) --> development organization / Dev. Team
II) --> Scrum Team (Dev.+ SM+PO) as Team matures

any other ideas?

@Ian: You have always good answers

I wonder if there is an inconsistency in the Scrum Guide. There is an earlier thread in which this matter is discussed:

https://www.scrum.org/Forums/aft/486

The best way I can rationalize the Guide's advice is as follows. If we accept that an organizational DoD is the starting point for a team's DoD, then the team's first cut of its DoD must, by definition, be independent of the product. As such, it is the Dev Team and not the Scrum Team who initially supply it. It must however then be subject to amendment by the Scrum Team, including the PO, so specific product requirements can be met.

I suppose that in the case where there is no organizational DoD, the starting point would simply reflect the Dev Team's actual capabilities given their broad understanding of the product. Even so, the idea of "the Development Team of the Scrum Team" producing a DoD "appropriate for the product", and not the Scrum Team including the PO doing that very important job, seems convoluted to me.

> @Ian: You always have good answers

Oh no I don't..

Posted By Ian Mitchell on 25 Apr 2014 03:49 AM
I suppose that in the case where there is no organizational DoD, the starting point would simply reflect the Dev Team's actual capabilities given their broad understanding of the product. Even so, the idea of "the Development Team of the Scrum Team" producing a DoD "appropriate for the product", and not the Scrum Team including the PO doing that very important job, seems convoluted to me.

> @Ian: You always have good answers

Oh no I don't..

I'm also thinking about what role would a SM play in defining and maintaining a DoD.

What about the scrum-master poking from time to time the Dev Team "are you really done accordingly to the DOD" ?
What about the scrum-master helping the PO & the Dev team during the retrospective to reflect on their current DOD ?
For young-team, they often put somethime like "Unit Test OK" in they DOD, and I think it is a good start.
They fell OK with that bu after a few Sprint, I ask them "what do you mean by UT OK ?". Their scratch their head and then they replace it by "have a XX% coverage" or "have a growing coverage sprint by sprint".

My (highly questionnable) point of view is that the scrum-master is responsible to push the team to have a more and more stringent DOD.

It's generally better to encourage an organizational *pull* for better practice, rather than to try and push. However I'd certainly agree that the Scrum Master has a significant role to play in establishing a good Definition of Done. When the guide says '...the Development Team of the Scrum Team must define a definition of “done” appropriate for the product' it doesn't make the SM's contribution, or any required input from the PO, very clear. In fact it almost appears to censure their involvement.

Maybe, the purpose of having only the dev-team responsible for defining and maintaining the DOD is to maximize the commitment of the dev-team, like using planning-poker within the dev-team instead of external estimates ?

I mean, as a dev-team member, I personally will be more committed to stick to a DOD I defined than a forced DOD.

I would say that the PO and the SM have some responsibilities regarding the DOD, but not the one of "defining and maintaining" it, but more on negotiating it with the dev team, in order to have the required level of quality (no bug, no gold platting, necessary but adequate doc...)

The best answer would be C) Scrum Team. The scrum team involves Dev team, Scrum Master and the P.O. The defination of done should be discused and agreed all the team members hence to conclude when the BPIs are called done. This should be defined in presence of all team members and shared to all to bring transparency. Still responsibility lies with P.O. as he is solely responsible for the outcome of the sprint i.e. potentially shipable product increment. Makes sense?

B) The DT + PO are responsible for defining and maintaining the DoD.

Regardless of who defines the DoD, The DT and the PO uses its existence to foster a shared understanding of the product. The articulation of shared understanding is the DoD and therefore the responsibility of the DT and PO.

The SM is responsible for facilitating all the parts that make up scrum. Since DoD is a communication and process tool, the SM facilitates its discussion during the restrospectives.

Side question, if a team isn't fully cross-functional enough to complete a sprint, who bears responsibility to make them whole?

The Development Team defines the definition of "Done". It is essential for the entire Scrum Team including Product Owner to be well aware of the definition. However, there is no need for approval from Product Owner.

While a Product Owner needs to be involved and made understood about the conditions, it is the Development Team’s responsibility to define the conditions in a verifiable way, because many of these conditions are usually around technical quality. For example, Product Owner may want a condition such as “The Increment should be thoroughly tested because it will be released to production”, and Development Team may define it such as “The Increment should pass all the automated unit tests with 95% code coverage”


Retrospective is a formal opportunity for entire Scrum Team to review and inspect the DoD