Definition of Done
How does Definition of “Done” help to the Scrum Team?
DoD ensures artifact transparency but not inspection and adaptation ?
Can someone please clarify in detail ? thank you
What do *you* think the likely impact would be on transparency, inspection and adaptation if a Scrum Team isn't clear about what "Done" means?
For us the 'Definition of Done' helps in several ways:
It avoids the 'done but still needs...' where maybe code is complete for example but not integrated or someone else needs to do something
It helps us on a practical front if a request comes down the line for 'a really small change that should just take x amount of time' as we can point to the definition of done and remind people there are a lot of other tasks to be done before the increment is potentially releasable even if the code change is trivial
We also get the benefit of a check list of items to act as an aide memoir similar to what happens in an airline cockpit!
Here is what I've noticed.
A DoD that truly expresses all the work needed before a feature can be released enables the team to know if it is cross-functional and what it needs to learn to do in order to become cross-functional.
A DoD defines the effort needed to make releasable any item of work and therefore enables a team to forecast what it can complete in a Sprint.
A DoD enables a Scrum Team to build trust with the organization by making transparent what it will deliver.
Consistent adherence to a strong DoD reduces waste in the form of rework and especially rework amongst multiple teams working on the same product.
The DoD is the transparent manifestation of the Scrum Team's commitment to producing working software often. When releasable software available often, it may be released and inspected in the market. This is a foundational benefit of agility that the Scrum Team will reap by committing to creating and adhering to the Definition of Done.
Agree with Jason
As Scrum team matures it is expected to stringent its DoD.
@Jason, you phrased it so much better than me! Nice one.
One thing I've noticed to be careful of though is making sure that a) the DoD gets inspected as you move from project to project and checked for appropriateness and b) need to be careful about scrutinising what's done and being sure that yes, every part of the DoD is met. Sometime it's easy to just give a proforma once over
The Definition of Done is a statement of group professionalism and creates organizational transparency. A Development team spurs other teams on to feats of audacious excellence. They balance their personal conviction with the needs of the organization while not compromising either. They craft a continuously higher standard of working and being. Forgive me for the exultant language, I've had a few drinks today :).
Of course, the DoD should change as the craft improves and as the development team progresses. Ideally, this progression is constantly towards higher quality, customer satisfaction, and organizational benefit. This is done primarily during Retrospective.
From the above good answers it can be seen that a DoD provides *transparency* over:
1. the work that has been done, and the level of quality thus far attained
2. the work that remains to be done in building future deliverables of the asserted quality
To the original poster's point: the first of these illustrates how a DoD can support the *inspection* of progress, while the second would allow the *adaptation* of the product to revised levels of quality.
thank you everyone.