DoD — Check List for Designers.
Throughout the Design at Scale™ mentoring, I have observed very little understanding of “the definition of done” amongst 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), it’s not indispensable to carry this information from release to release and other iterations that might benefit from such knowledge.
“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 in their area of expertise means. 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 being “done”, then all parties accept “a good enough” increment that allows the following Contributor and equally 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.
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.
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
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.
Final Check-List
What are the benefits of a checklist in the user story and the sprint?
Customer Lense
Customer-facing improvements — a statement later used for initial pitch and further project direction.
Process-based improvements — helping us advocate for the financial impact of the product or service.
Service-based improvements — influence, trigger, activate and reward the user for their loyalty.
End2End improvements — simplifying the proposition into one diagram allow the business to visualise what has been forgotten or misused.
(Please visit the resources below for detailed info about this topic)
System Lense
Service level requirements — definition of SLA
Functional requirements — Consider all disability factors.
Interface requirements — Overall accessibility, including the colour, button and UI size animation etc.
Security and Compliance requirements — Legal and Risk
Architectural constraints — This refers to technical architecture.
Operational and Migration requirements — not only if you’re considering moving from one system to another.
(Please visit resources below for detailed info about this topic)
DoD–Checklist for the Prototyping (POC) Phase
What problem does the POC solve?
Innovation vs Invention — understand the difference?
Who is the target audience, and what are the main characteristics?
What is the unique selling proposition?
What is the product or service strategy for the next 1–3–5 years?
(Please visit resources below for detailed info about this topic)
DoD–Checklist for a user story
Is the User Story verified?
Have the build & tests been confirmed?
Are the assumptions met?
Have the project build and unit tests been written and passed?
Is the increment deployed on the production platform?
Can we test on devices/browsers?
QA (Quality Assurance) session performed + resolved?
Is the refactoring completed?
Is the configuration or build changes documented?
(Please visit resources below for detailed info about this topic)
DoD–Sprint
Better team communication — CPO® planning and update
Standardised process and operations — CSM® reviews
Better task estimation — Duration, Prioritisation, Impact
Better R&D flow — Integration of test result
Contextual Experience — Behaviour achieved
Integrated Design Framework — All bugs fixed
Software quality assurance — QA and Refactoring
Less refactoring — Deploy and test on the production platform.
Well-tested features on each release — Product backlog updated
Smoother Integration — Sprint marked as ready for the production
(Please visit resources below for detailed info about this topic)
Resources
Malcolm Gladwell’s review of The-checklist-manifesto
Service Design — Checklist_Service_Design_Package_SDP
Business objectives and technical questions for your PoC — https://medium.com/@rezamehman/
Derek Huether and his perception of Definition of Done — https://www.leadingagile.com/2017/02/definition-of-done/
Sumeet Madan and the relationship with FR and NFR’s — https://www.scrum.org
Create a clear definition of done with IBM — https://www.ibm.com
https://wiki.en.it-processmaps.com/SLR
Stay tuned; thanks for reading!
Thanks to all contributor especially Matt Press, for their insight and comments shaping this very article.
Jiri Mocicka is a London-based designer writing about his passion for the Design at Scale — integration and design operations that builds excellent digital products.
