By , Professional Scrum Trainer, Simon Reindl Scrum.org 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 where the Definition of Done is, and what are the next steps. 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. 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! 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. 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. 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. 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. 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: . 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. https://www.slideshare.net/WinOpsConf/ian-margetts-asos-journey-to-continuous-deployment Originally published at www.advancedproductdelivery.com on March 1, 2019.

Flow

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Improving your Definition of Done

Too Long; Didn't Read

Coin Mentioned

Scrum.org

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Improving your Definition of Done

Too Long; Didn't Read

Coin Mentioned

Scrum.org

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES