Using the Definition of Done in the Retrospective

Intermediate

difficulty

Stage 3

Agile IQ® Level

Definition of Done

Practices

Scrum

Framework

Introduction

The Definition of Done (DOD) is a formal description of the state of the Increment when it meets the quality measures required for the product. It helps avoid rework by stating, upfront, what the team needs to do to build-in quality.

When quality slips, defects and rework increases, it’s important to look at the Definition of Done in the Retrospective.

Things to try

Remember

Improving the Definition of Done reduces rework and defects by improving quality. The longer your Definition of Done the more work your team will need to deliver.

Did some items not meet the Definition of Done?

Why did some items not meet the Definition of Done?
Is the Definition of Done too strict?
Does everyone understand the Definition of Done?
Were tasks created in Sprint Planning to help the team meet the Definition of Done for relevant Backlog items?

Why are there defects?

What’s the state of the product’s health?
How do we classify defects?
Are the defects only minor or major?
Are there common areas of the product where the defects are occurring?
What causes these defects? Is it something we can avoid?
How can we adapt our Definition of Done to avoid defects in the future?

Rework as defects

For non-software teams, rework means a focus away from delivery of value.

Why is rework occurring?
Is rework simply user feedback for new work or adjustments to work?
How do we distinguish between new work requests and rework?
If we had a template to work from would the rework go away?
If we had a checklist of tasks for specific types of work, would the rework go away?
Do we need to establish definitions for rework versus work requests?