Skip to main content

Improving your Definition of Done

March 1, 2019

The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on what the Definition of Done is, and what the next steps are.

The intent is to provide a structure for the teams to reflect, and then build a plan on what to introduce to improve the quality of their Product Increment. This could be run during a Sprint Retrospective, before starting a team, or at any time during a Sprint.

Setup

Draw three nested triangles on a whiteboard or flip chart, as show in the image below. Label the centre rectangle “Now”, the middle rectangle “Next”, and the outer rectangle “Future”. Use this to guide the team. I like using colors to emphasize the green future!

Invitation

Invite the Scrum Team to build a path to a more rigorous Definition of Done, that would mean that the Product Increment can be released with no further work.

Process

Generation

The team brainstorms everything they would want to be part of the DoD, assuming they can do anything. This should include anything at all, without any constraints or boundaries. Individually team members write each item on a separate post-it and place all of the them on the wall beside the rectangle.

 

Now

The Team collectively moves the items they believe they are meeting into the space labelled “Now.” As a team they need to agree that the items in there are what the team are currently doing, or capable of doing in the next Sprint. Everything in this list should reflect current working practices. Typical examples include, checked in code, all unit tests passing, peer review.

It is critical to highlight that the team will be held accountable to this definition, in the next Sprint.

 

Next

Do the same for the space labelled “Next”. This will consist of items that the team could add to their definition of Done in the short term. These may require a little research, practice or change in behavior. This isn’t about planning when to do them, more an indication of intent. Typical examples include: pair programming, Test Driven Development, automated UI testing, automated deployment to an environment.

There is a reason that the team hasn’t been able to put these in their current definition, as they require some work and effort or purchases to be able to achieve.

 

Future

Do the same for the space labelled “Future”. This will be the items that require significant investment of time, energy and materials to be able to accomplish. This may require purchase of equipment or tools, negotiation to use tools within a tightly controlled environment, or significant changes to team practices. These aspects are the more challenging to achieve.

Example of Flipchart
Done Exercise

Call to action

The team updates their Definition of “Done” to include the “Now” items. The items may need to be broken down for more granularity or re-worded for more clarity. I would encourage you to complete this now, so that you have a clear definition of Done agreed.

Imagine running this at a Nexus/scaled level - creates some great discussions!

The remaining items can then be ordered in to a rough Backlog. These are then captured as actions so that the entire team has transparency around what they are going to include next. The rate at which you pull these into your Definition of Done will be dependent on the what the Scrum team can accommodate. It is critical that everyone appreciates that this will improve the outcomes of the whole organization.

 

Conclusion

Done is central to transparency, and having a Done Increment that can be released is the key indicator of an effective Scrum Team. To get to this place, requires effort and focus. The whole team and their stakeholders need to support a ruthless focus on quality, to achieve this value.

A real example of how an organization embraced this, and reaped the rewards is the fashion retailer ASOS. Read about their story here: https://www.slideshare.net/WinOpsConf/ian-margetts-asos-journey-to-continuous-deployment. I was fortunate enough to be there for part of their journey, and the effort to achieve the high levels of flow were significant, however the efforts repaid the organization in being able to support exponential growth.


What did you think about this post?