Most companies I’ve worked for incorporate agile or the intention of agile into the processes. I say intention because it’s often not followed in its entirety. Instead, PMs cherry-pick sections of the Scrum framework to fit into the project path. Let’s be honest, it’s usually development-focused. And at worst companies, design & development teams work in isolation.
What’s worse is that UX is often left in the corner. Our research, design, and revision processes slow things down. Developers need points asap, POs approve stories for features in detail without seeing wireframes or designs, we ship half-baked screens, and thus the product develops experience rot. It’s a hot mess.
In the next few months, I’m going to spend my free time learning about product management so that I am better equipped to address these evident pain points in the process. I want to be able to speak about implementing UX into the currently dev-heavy process.
What is DoD?
Definition of Done – a checklist of the work types that the team is supposed to finish successfully before declaring the work to be potentially shippable.
According to Scrum Alliance, there are three different types of DoD:
- Definition of Done for a feature (user story or product backlog item)
- Definition of Done for a sprint
- Definition of Done for a release
At the end of the day (or sprint?) Scrum and UX share the same goal: produce and deliver great products and services that create value for people.
Josh Seiden identified 3 different concepts to describe “when-work-is-done:”
- For traditional UX work, “done” = designed and tested with users and revised as needed
- For Lean UX, “done” = validated
- For Scrum, “done” = working software
Design is not linear; it doesn’t end once final high-fidelity designs are handed off to the dev team. Work continues beyond deliverables with the continuous checking that designs meet the requirements and needs. Then there are endless revisions. Like art, design is never done, just abandoned.
Agile provides a response methodology to handle change, but often teams don’t know how to deal with iterations. I digress, that is a longer discussion than this post allows.
Team members use DoD as a reporting tool to specify when a feature is ‘done.’ It’s an easy communication method to update other team members and the Product Owner. Below can be used for a Definition of Done checklist:
- Wireframes created based on insight and feedback
- High-fidelity designs approved/seen by users
- Content and copy finalized
”Design is never done. The context of use into which you’re delivering your product is always change — in no small part because if your product is successful it is creating changes to the user’s environment! So get used to the idea that your design is going to evolve forever.Josh Seiden
DoD v acceptance criteria
Product Owner sets acceptance criteria for each backlog item going through a sprint. These are a set of conditions that must be verified. During a sprint, the Product Owner sets acceptance criteria for each backlog item. These sets of conditions are verified during an acceptance test.
Acceptance criteria – what needs to be done
Acceptance tests – how things should be done
In grooming, different members of the team with different skills and knowledge sit together to consider and come up with different scenarios to fulfill each criteria. It’s initiated by POs or BAs, but everyone can participate. These are written down (sometimes as simple as a bullet list) and agreed upon before work begins.
It is by means of conversations with stakeholders, developers, and QA that the details of each acceptance criteria are fleshed out, e.g. in story workshops or story grooming sessions where different members of the team with different skills and knowledge, and experience sit together and think about the scenarios to fulfill each criteria.
New criteria can be added at any time.
A product backlog item can be qualified as done if and only if the item-specific acceptance criteria and sprint level DoD have been met. In some agile teams, this can be referred to as “done-done.” That certainly can add more confusion than clarity.
Here are Josh Seiden‘s recommendations for resolving the conflict between Done and Validated.
- Scope down and deliver every. single. day.
- Commit to evolving and refactoring user experience.
- Give up the traditional UX notion of “finished design.”
- Recognize the difference between “done” and validated.
For a deep dive on the topic, the Scrum.org organization offers full-day UX + Scrum sessions. Is that enough time to understand how to best implement UX into Scrum processes? Only one way to find out.