Done is not just a document
I see Scrum's "Definition of Done" being off as Done is often treated as an artifact, but as not an agreement between people.
People agree on if something is done. Any document is just a tool for communication about this.
https://scrumguides.org/scrum-guide.html#increment
I'm shocked by reading the section of 'Commitment: Definition of Done'.
It just talks about artifacts. 'Definition of Done is a formal description'
I don't not see much of the first principal of the Agile Manifesto shining through.
I work since 10 years mostly in Scrum in different teams.
By my experience we achieve the most satisfying results for the product owner and customers when the developers (including testers etc.) have constant exchange (at least) with product owner.
"Fail fast, fail often", show it often and get feedback (while staying in the focus of the story).
Short feedback loops are important!
At least clarify unknowns and don't make arbitrary assumption when you have someone you can ask.
'Definition of Done is a formal description'
No formal description can fit perfectly to every backlog item you work on.
Sometimes you have to exclude things, sometimes you have to include story-specific criteria.
And every general criteria is different for every story.
e.g. 'create user documentation'. How much is enough? The DoD can't tell you, but your team mates and the stakeholders.
Surely you should not have feature-creep at a story and changing already defined details every minute should not happen.
This is the extreme I also not endorse.
Finally only responsible people will create a good product.
This includes to trust each other, communicate, and not just to rely on artifacts.
It is not 'Done', it is 'done'. Not a noun but an adjective. The same as it should not be 'Agile', but 'agile'.
Rewrite of the guide's Increment section
To make my point more clearly I rewrote the Increment section v2020 to fit more to the first Agile principal by my understanding.
| My text | Original |
| (I'm fine with this part) | An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. |
Work cannot be considered part of an Increment unless the team agrees it to be done by different criteria. Commitment: Shared understanding of DoneFor every Increment agrees the team on quality measures required for the product to be meet to consider it Done. The moment the team agrees a Product Backlog item to be Done, an Increment is born. Having a shared understanding of what work was completed as part of the Increment creates transparency. If a team does not agrees on a Product Backlog item to be Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. It may help to note most of this quality measures in a document, a so called Definition of Done. This document is just a starting point as the team may find necessary quality measures for an Increment later on. If an understanding of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must agree on their understanding of Done appropriate for the product. The Developers are required agree on a shared understanding of Done. If there are multiple Scrum Teams working together on a product, they must mutually agree on the same understanding of Done. | Work cannot be considered part of an Increment unless it meets the Definition of Done. Commitment: Definition of DoneThe Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done. |
What are your thoughts on this?
How do you and your team decided about what you consider done?