Many of the team members often ask the question, is DOD similar to SOD? If yes, what different are we doing from earlier?
SOD stands for Steps of Doneness, and DOD is Definition of Done.
Ten years before, when I used to be the Project Manager and held the reins of the project triangle of Scope, Cost, and Time with Quality representing the center of all, I would own the creation and tracking of SOD. I used to ensure that I have accounted for every single minute spent on the project. SODs used to look something like this:
This SOD used to have 31 steps before marking anything “done”.
The first row will have the list of steps that the development team and QA team will complete.
The second row consisted of the % of the effort that that particular step must take. A team of developers, architects, and QA used to finalize this % distribution of effort after multiple rounds of discussions amongst themselves.
In the third row, every team member will mark “Y” as soon as they have completed the step. Every day, the project manager will monitor this SOD and observe the % completion of the item that is under development.
Each day, the project manager was busy as they had to track the SOD, and on the day of status reporting (once a week), the project manager had to start the day very early to create the status report based on this SOD and please the stakeholders.
I also had the same story, and since I had the complete project to manage, I hired a project coordinator who will do all these clerical jobs. This project coordinator will then later turn into a seasoned project manager.
On the other hand, Scrum Guide mentions the following for Definition of Done –
“When a Product Backlog item or an increment is described as “Done”, everyone must understand what “Done” means.” — The Scrum Guide, 2017
As compared, in SOD, everyone understands their step, and the Project Manager has the view of all the steps. Moreover, it’s a foreign language for external stakeholders. This statement brings the point that DOD is much more valuable and may be formulated in a way to be both transparent and understandable to every stakeholder.
“This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product increment” — The Scrum Guide, 2017
Whereas, in SOD, it is mostly the project manager who had the complete visibility on completion of the group of “items”.
“The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning” — The Scrum Guide, 2017
As compared, SOD does not become an input to planning; instead, SOD used to be one of the most effective tools to track the % completeness of the development.
“If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum” — The Scrum Guide, 2017
This statement is true for SOD as well. Usually, a software organization has defined their standard definitions of SOD in the so-called “PM Hands-On Manual,” which is used as base definition and enhanced further for each project, if needed. The project “at least” must follow the base definition; otherwise, it is called non-compliance, and the Project Manager is accountable for this non-compliance in the project. The Project Manager must take deviation for this non-compliance from governing quality department.
“If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”. — The Scrum Guide, 2017
This statement is true for SOD. The Project Manager and the team will define the SOD; however, they will define it to the best granular level possible.
Based on the above thoughts, I believe, we can achieve a much more valuable outcome through DOD rather than SOD.
“The Development Team self-organizes to undertake the work in the Sprint Backlog…”. — The Scrum Guide, 2017
Definition of Done gives the flexibility to the development team to self-organize and undertake the work. It helps them to inspect and adapt as needed to accomplish the sprint goal. As compared, SOD mandates the team to follow the steps as mentioned in steps of doneness allowing no room for creativity to increase the effectiveness of the development team.
As described by Stephanie Ockerman & Simon Reindl in their book titled “Mastering Professional Scrum”, Definition of Done provides the benefits of
(1). Transparency of process, (2). Transparency of the Increment, (3). Transparency about where we are, (4). Transparency about where we are going and (5). Transparency about planning a sprint.