The last couple of posts I’ve written have been about the Product Backlog and Product Goal then the Sprint Backlog and Sprint Goal. Today I’m going to focus on the Increment and it’s Commitment the Definition of done. These are slightly different to the previous two Artefacts and Commitments, the Backlogs and Commitments described above show the current progress of work and the vision of what that work will look like when it’s delivered.
The Increment is the piece of work which is being delivered to the customer at the end of the Sprint. These should be as small as possible, however it’s possible that it may be the entire Sprint’s worth of development. The Increment is the next piece of the product which has been added to create more value. Scrum.org has a nice defintion of an increment.
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.
The Scrum Guide 2020
This is different to the previous to artefacts because it doesn’t describe the current state of what’s being worked on for the purposes of inspection, is is what’s being worked on.
However, as with previous artefacts it does come with a commitment. Where the Sprint Goal and Product Goal descibed the objectives we were working against the Definition of Done is a commitment to create transparency over what has been delivered.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The Scrum Guide 2020
One of the biggest frustrations in modern software development is when something is “done” but exactly what that entails is a little hazy. One team may mean code complete, another may mean tested, another may mean deployed to a customer. The Definition of Done creates a shared agreement of what the team understands “Done” to mean. This prevents the awkward scenario where a stakeholder is expecting tested functionality but gets only code complete stories.
It also makes estimation easier because everyone has a clear understanding of what is expected.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
The Scrum Guide
If a team is working as part of a Nexus of Scrum Teams developing a single product, or if they’re part of an organisation providing components to another team then the Definition of Done should be shared to ensure that all teams share the same understanding of when something can be said to be Done.
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
The Scrum Guide 2020
Teams which do not have a clear defintion of done experience friction when engaging with stakeholders, uncertainty when it comes to estimates, and ambiguity when planning out work.
A good Definition of Done should include items like:
- Acceptance Tests Pass
- Non Functional Tests Passed
- Documentation Created
- Deployment Pipelines Created
It may also include “deployed to customer” if a team is following Continuous Deployment practices. However, for the purposes of Scrum we commit that our increments will only be “Potentially Shippable”.
One final point, the Definition of Done ensures that quality does not drop as functionality is added. The Scrum Guide states that quality does not decrease during the Sprint. The Definition of Done helps us verify that each and every increment is complete and quality is maintained before it is declared complete.
Hopefully this has been helpful, I think it may be time to look at the Scrum Values!
dotdotdev.com 