AgileByExample

Rafał Markowicz

Rafał is an experienced Scrum Master and a software developer working for IT since 2001. Starting from 2007, he becomes an Agile practitioner using Scrum and other Agile methods. Today, Rafał works as a consultant, an Agile coach and a Professional Scrum Trainer (PST) at Scrum.org, helping organizations and teams. He remains an active developer specialized in test automation and quality assurance.

Workshop—Let’s define the Definition of Done

The crucial condition for the empirical process control is the transparency of what is really done. By having an adequate level of transparency, the teams and the organizations can make informed decisions about the next steps. If the level of transparency is insufficient, assumptions emerge, and the empiricism vanishes.

To be able to learn what is done the teams define their policies (in Kanban) or the Definition of Done (in Scrum). In many cases, this leads to an unpleasant discovery: the created set of policies / the Definition of Done (DoD) exceeds the skills or capabilities of the team. How to handle that situation?

But that is not the only challenge for the teams: can the policies / DoD ever be complete? The team soon figures out that there is always something that can be improved, and the set of policies / DoD is never static. Thus, they must find the answer to how to handle the evolution of its policies / DoD.

Yet another challenge is to make the set of policies / DoD transparent on their own. The more complex work the teams does, the more elaborated become their policies / DoD. How to avoid losing transparency and prevent from opening any gate for regression?

Then, to differentiate what is done and what is not done, the team uses the following paradigm: “if we cannot prove it is done, then it is not done”. However, the policies / DoD must somehow be captured in words even though we all know that the same sentence may often be interpreted in multiple ways. Is the team really doomed to make mistakes when assessing what was done?

During the workshop, we will address the abovementioned challenges. The participants
will:
- Create the Definition of Done for a product
- Identify what should be taken into consideration when crafting DoD
- Learn about different categories of statements that can be included in DoD
- Outline the typical process in which DoD can be crafted
- Learn how the accountabilities in Scrum (Developers, Product Owner and Scrum Master) impact the DoD and what is the role of architects, managers and other people not being part of the team
- Understand different levels of done and how to leverage DoD whenever it becomes possible
- Discuss various examples of vague statements from exemplary Definitions and improve them
- Learn how to map existing standards and policies into DoD
- Create “DoD Canvas” – a simple tool that can be used to stimulate the discussion during the creation or update of DoD

The workshop is intended for the Scrum Team members and those who work in Kanban – as it is their accountability to define the policies / DoD. However, the managers and the architects do have an impact (intentional or not), thus they may benefit from a better understanding of the process in which done is defined.


2018


Workshop—You ain’t gonna need retromat

2017


Workshop—How can Scrum Masters help Product Owners in Product Backlog creation