Definition of Ready and Definition of Done

[SaschaWildgrube]

It would be great if we at least had consensus about what a Definition of Ready and a Definition of Done is in the first place.

There are so many different opinions, variants, beliefs.

It is what it is. So here is my contribution to the cacophony:

The Definition of Ready is the central building block for the first quality gate that any backlog item must pass.  It is important that the team has a say in what should be contained in the Definition of Ready. However, it is strongly recommended to include the following points:

• Description of desired outcome / Use case
• Affected applications
• Affected personas and technical users
• Affected process(es)
• Affected data entities
• New and modified fields (including labels)
• Affected GUIs (Classic, Portal, Mobile)
• Relevant GUI languages
• Affected notifications
• Affected technical interfaces
• Required access restrictions (per persona)
• Data Protection/GDPR/Compliance implications
• Required documentation
• Proposed test data
• Proposed test cases
• Proposed data quality checks

When presented to teams for the first time this list may cause some concerns – especially amongst product owners or other stakeholders representing the business. They might argue that a good portion of these topics cannot be provided by them.

But passing the first quality gate is NOT a hand-over from product owners to developers!

It is important to understand that it remains a team effort to describe a backlog item in a way that it is compliant with the Definition of Ready. It requires the business to describe the need, the architects to make decisions on which applications to change and the development team to fill in implementation details where needed.

The Definition of Ready is the checklist to ensure that a backlog item can be worked on by the development team. It does not mean all potential questions are answered yet.

The Definition of Done is the central guidance and checklist for the second quality gate: The Backlog item is “Done”.

In many agile organizations, both the “ready” and the “done” state are seen as hand-over points where the work (or responsibility for something) is handed over from one team to another. This perspective might seem comforting, but it is not helpful.

A process will not work well when things are thrown over the fence, and then thrown back if they do not comply with a set of rigid rules.

At all stages it remains a team effort – to define the rules, to use them, to apply them, to review and change them.

The Definition of Done is often used for protection by a development team – where a team tries to defend a way of working which they perceive as good quality against business stakeholders who want to get new features out of the door as fast as possible at the lowest possible cost.

Deployment Automation and the embedded use of automated quality checks is intended to bring some relief to this conflict. Once there is a baseline of quality requirements which are checked as part of every deployment, both the developer team and product owners know that if they do not deliver according to the agreed quality levels – nothing will be shipped. Period.

The Definition of Done is a pre–check after the completion of the development work on a single backlog item – before the feature is shipped as part of an application version. The line items in the following proposal should hence be considered as non-negotiable, others can be added at the team’s discretion. The question is less “if” these checks should be performed, the question is rather “when” they should be performed:

• All described features are implemented
• Implementation is peer reviewed
• All described (and relevant) test cases covered in ATF tests
• All related (new or changed)ATF tests are peer reviewed
• Compliance to the Coding Guideline (i.e., no Instance Scan findings)
• All related ATF tests pass
• All technical documentation written
• All changes have been documented in the Release Notes
• Validated by Product Owner (explorative test)
• Application dependencies are verified and updated if needed

The Definition of Ready and the Definition of Done are two vital building block of a mature development and deployment process.

Ready the full story here:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf