DoD — Check List for Designers.

Throughout the Design at Scale™ mentoring, I have observed little understanding of “the definition of done” among designers. It’s no wonder — in 2019 while working with 27 different teams, I asked what their Definition of Done (DoD) is and how the design represents itself alongside other disciplines; the answers were shocking.

Before we dive into details, fun facts and the bitter truth, let’s cover the basics of what the DoD in Agile development stands for.

Definition of Done is an agreement on which basis the Scrum team defines the optimal software development deliverables to be good enough.

I ask all the Certified Scrum Masters in my circles what the DOD checklist is. (specifically including insights, research, testing, customer experience and User Interface design).

To my surprise, there was no appreciation for the continuation of sharing knowledge beyond delivery. And as the design is not considered part of working software (for many companies), carrying this information from release to release and other iterations that might benefit from such knowledge is not indispensable.

***Figure 02:*** *Checklist illustration showing three columns.*

“Most fear is just bad management of our own mental faculties.” — Brendon Buchard

Why do we need the DoD Checklist at all?

Definition of Done

Simply put, every team member should understand what “done” really means in their area of expertise. The work in Agile teams is based mainly on mutual trust between team members nowadays distributed in different continents, time zones and systems. Therefore, having the exact definition will be (without additional verification) a precondition of a successful contribution. When a specific thing is marked as “done”, all parties accept “a good enough” increment that allows the following Contributor and Product Owner to proceed.

Checklists for User Stories and Sprints help us stay productive. Each member needs to have great tools to boost team productivity. Of course, even the best document is not a substitute for good communication within the team. However, we should use every possibility to make our process easier and more transparent, and the DoD Checklist is one of the best ways to do that.

“Doing things is not the same as getting things done.” — Jared Silver

An example of Design at Scale — DoD

When we decided to create the DoD in our company, we put together “a shortlist of areas that we should own and control to deliver the highest possible quality software”. We created two checklists that help us verify our work on two stages of the software development process.

***Figure 03:*** *Example of the user story checklist*

1. DoD checklist for a user story

Product Focus: Let’s begin with the elementary increment of any product delivery. The single User Story contains user (customer) requirements and initial assumptions combined in a single backlog item. Thus, we do not control only the quality of written code but also the quality of the elements that define our process from end to end.

Business:

Does the story describe the user’s desired behaviour?
Does the behaviour represent the customer value proposition?
Can we monetise the behaviour and improve the customer experience?
Have we produced the desired experience?
Are we helping the customer to achieve their objectives?

Experience

Do we communicate the right message CTA (Call to Action)?
Do we have the right tone of voice?
Does the user understand what is expected from them?
Are we using consistent Design Language across the proposition?
Do we have a Design System or equivalent?
Does the Design System reflect the equivalent in the FE code?

Development

Have we produced the code for presumed functionalities?
Does the QA pass without errors?
Were the unit tests written and passed?
Was the project deployed in a test environment?
Was the project tested on devices/browsers listed in the project compatibility requirements?
Was the QA (Quality Assurance) session performed and passed?
Was the documentation updated with the latest status link to Figma, XD, etc (if it exists)?
Was the PCR (Peer Code Review) performed?

This creates a balance between all parties and reduces the tension especially between remote parts of the team.

***Figure 04:*** *Example of Sprint Checklist*

2. DoD checklist for Sprint

Process Focus: In the following stage, we decided to control Sprint outcomes. The checklist can easily represent the team workflow. Now the entire team can see if all the implemented features fulfil their original requirements and pass the acceptance criteria.

DoD for the Customer
DoD for the Business
DoD for the Experience
DoD for the Design
DoD for the Development
DoD for the Release
DoD for the Integration

“… under conditions of complexity, not only are checklists a help, they are required for success.” — Atul Gawande

***Figure 05:*** *final.final.suer_final.cluent_fina.pdf*

Fundamentals

At first glance, it might come across as overwhelming. However, in software development, a well-orchestrated Definition of Done can make a significant impact. Not only on the daily interactions and communication but also on the product being delivered on time and accepting all industry criteria.

DoD’s decreases miscommunication within the team or team of teams mainly when all members have been equally spread across different time zones. This avoids verifying the work several times and reduces the conflicts arising from missing information or clarifying the proposition. As a result, team members can now finally build trust in the form of tribes.

Business

Well-defined DoD allows the business to reduce time to market and prevent unnecessary spending on something that will never see in the hands of real customers. Well-implemented DoD in your Product team can make up to a 30% impact on reducing code refactoring and the time to market, including the cost of the project in one go. Inevitably DoD improves the overall team communication whether you sit next together or in a different continent or country. Precisely defined criteria prevent the team from conflicts arising from misunderstanding and the inevitable creation of silos. All the above makes the average team a better team.

Creative

Well-structured DoD allows creative teams to share a vision in a safe environment and invite everyone to review never-ending interactions of prototypes without ever facing adverse reactions. Inevitably it will enable the discussion about design in progress or done, which is a more significant challenge for every Product team. And last but not least, it allows the design teams to work in a more exploratory way where the increments are done in a more centralised manner.

For example, while delivering a set of buttons, iconography, colours or responsive image definitions in one go, the development team works without changing their own ways — more on this topic in Dual-Track Agile article.

Development

And finally, the DoD represents the safety of the development team. To mention just a few, Reza Mehman wrote a Checklist, “Proof of Concept”, that looks into the definition of done for proof of concepts. The ProductPlan startup has written a very good article about their “Definition of Done” from the development perspective that’s definitely worth reading.

To Avoid

However, we must be careful. Too detailed DoD Checklist could lead to wasting huge amounts of time on unnecessary formalities. We must also remember that this document is not a cure for all the problems, tensions and challenges.

It can’t replace good team communication nor precise function requirements. But, if it is a part of a well-functioning process, it could resolve many problems and help save a significant amount of time for something more pleasant than overtime work.