The “Agile” Definition of Ready & Done for Product Managers
Getting things done is crucial, especially in today's ever-increasing fast-paced offices. That doesn’t only apply to building the right things, it also applies to building “wrong” things and learning from them. That being said, what does it take to get things done fast while learning from them?
As a Product Manager, I’ve learned that execution isn’t the only thing to consider. Having a good plan and clear working agreements within a team between Product and Engineering is fundamental for alignment and acceleration purposes.
In this article, I’d like to focus on the importance of getting things ready in order to be able to get them done by having a look at the definition of “ready & done.
Mistakes We Make When We Are Not Ready
In order to be able to start developing new features, tickets, bugs, etc. Product Managers and their teams must decide on priorities, scope/size, design, and many more things. On multiple occasions, I made the mistake of skipping parts of the planning process to “be faster” by:
thinking big technical open questions will be answered during a sprint
assuming the design for tickets will be finished in XYZ days
promising to get unblocked by other teams without having their commitment
This also happens from the Engineering side with examples like:
creating and pulling tech stories without a clear explanation and acceptance criteria
pulling un-estimating tickets because “everyone knows what to do”
not breaking down bigger chunks of work because “it takes no longer than 1-2 days…”
The past has shown me that these kinds of ad-hoc actions are very risky and dangerous. When things aren’t clear, people can be tempted to make “faster” decisions because of pressure and deadlines rather than spending the time needed to gain clarity on the topic or situation. If someone gets sick, who can answer a question or deliver a design, you won’t be able to finish the work.
The definition of “ready” can be a good and effective tool to reduce this kind of risk. It helps hold each other accountable for our own responsibilities.
What is the Definition of Ready?
The definition of “ready” (short: DoR) is a working agreement within a development team/squad. It defines clear actions and criteria that need to be fulfilled to call a story ready or immediately actionable. The DoR can be applied to a Scrum or Kanban team. Some Scrum Teams define separate DoR for sprints. I believe, that if all tickets are regularly groomed and set to “ready,” the sprint should be ready by itself. However, there is no wrong or right. What’s most important, is what you agree on internally.
This leads me to our next topic; Who defines the DoR? This is something that you should do together as a team. Back then I worked with teams that didn’t have a DoR or a Scrum Master who educated us on defining one. Nowadays, I initiate/drive the definition of a DoR if no one else does. The DoR will be defined and owned by the whole team/squad and should be regularly refined, for example, during or after a retrospective. It can be a simple Google Doc, Confluence page, or even a flip chart entry.
How often you adjust this depends on multiple factors like how well you work as a team, your velocity, how clear the roadmap/big picture is, and even more. In my current squad, we look especially at the DoR when we’re not able to finish tickets over a longer period/sprints.
What a Definition of Ready Isn’t
A definition of ready is not a loose commitment written in a document that nobody cares about. It's not a top-down decision made by an engineering or product manager either. The idea of a DoR isn't to slow down processes with bureaucracy. The aim of a DoR is to define a standard for product requirements to ensure efficient and seamless development.
What should you actually write in a DoR and what does a real DoR look like? 🤔
Creating Your Agile Definition of Ready
Here is a real-world example:
The goal of our DoR is to make sure that features/stories/tasks are defined enough in order to start and finish the development within the sprint commitment.
User stories/tasks/enablers and spikes do have an understandable title (at least half-sentences / full sentences)
The title should be a short description of the goal, that’s understandable to people with knowledge of the domain (e.g. "Create idx_product_usr" is a bad title. A good one could be "Create indexes for user/product queries" ).
Product backlog items (PBIs) do have an understandable introduction & acceptance criteria following the INVEST scheme
UI involvements or design tasks require the design to be linked to the ticket/story or to the epic
The ticket lists all new image assets that must be added
If the assets aren’t final yet, the dimensions and constraints must be agreed upon beforehand
PBIs have been groomed with the team and estimated as well as prioritized afterward by the product owner/manager
Based on your agile processes and workflows, you can add more or less information to your DoR. What’s most important, is to get started and create a document.
When does the DoR fall into place and what are the ups and downsides of it? 🤔
If you’re a new team or recently introduced the DoR, I’d recommend checking it during/after you’ve groomed a ticket. You’ll do this more frequently at the beginning, later on, it will become second nature. By doing so you’ll learn to make sure all relevant parts of it are covered in tickets.
Attention⚠️: It’s important to not overcomplicate the application of the DoR. I’ve seen that teams use it as a gatekeeper/blocker to not let anything in the sprint that doesn’t cover 100% of the DoR. Sometimes though, it’s not possible to get all the information upfront, or it’s clear that you’ll get an answer right after the sprint has started. What’s most important for teams, is to understand that the DoR is a tool that should help to prepare work better. It’s not just a bureaucratic process!
The first point of the Agile Manifesto says:
Individuals and interactions over processes and tools.
Using the DoR as a tool is great as long as you don’t ignore the interaction with individuals. 😊
What is the Definition of Done?
While the DoR focuses on getting things ready, the definition of “done” (short: DoD) focuses on the final stage of the work, getting it done.
The DoD is important for all team members. Not only for Product Managers but also for Engineers, Product Designer, Quality Assurer, etc. Like the DoR, it can be applied to every framework you work with. The whole team defines and owns it and regularly iterates on it. You can apply the same rules as per the DoR when it comes to the creation and maintenance process.
“Done” can be defined on multiple levels:
Story level (when is a story or ticket done)
Release level (when is a release done)
Feature level (when is a feature done)
Sprint level ( achieving the sprint goal)
Etc…
What a Definition of Done Isn’t
The Definition of Done isn't an agreement that any team member can ignore. The DoD isn’t vaguely formulated, leaving room for interpretation. Instead, the DoD defines clear criteria that must be met to consider a feature or product as "done." Common requirements include review by another engineer, testing by QA, and approval by the Product Manager.
Creating Your Agile Definition of Done
In order to make a start with defining a DoD, I recommend, as per the DoR, to start on a story/ticket level. In my current team, we started with simple things like:
The code has been reviewed (4 eyes)
All acceptance criteria have been fulfilled
All automated tests are passing (like integration/unit tests etc.)
The story has been deployed to [Stage] (can be either “production” or another environment depending on your release cycle)
The web application has to be tested on: [Browser], [Version], and more…
The story has been reviewed by the Product Manager (and Product Designer if needed)
Does the Product Manager need to review every single ticket?
I, for example, review mainly end-to-end stories that are customer-facing or tickets that have a bigger impact on the live system. Technical improvements won’t always be reviewed by me. Although, this depends on your role as Product Manager, your domain, and the agreement within your team. Technical Product Managers, for example, should review technical stories as well.
Are multiple DoDs helpful for teams?
In my experience, teams tend to do well with one clear DoD. If you and your team have clarity on what “done” means on a ticket level, you can easily apply it to a sprint, release, or feature. If you don’t, you can either review and enhance the existing DoD or create another one.
Benefits of Working Agreements for Product Managers
Working agreements can help you to better prepare your projects. Especially at the beginning of a career, the DoR can help to make sure all the relevant information for a ticket and sprint is covered. Well-prepared stories/backlogs are a good foundation for smoother sprints, which can lead to better sprint achievements. This will help to get planning certainty and be able to communicate clear project updates to your stakeholders.
At the end of the day, it’s just another important step for project good planning...
...and with good planning and a clear definition of when things are done, you’re way better set than I was a couple of years ago.
How are you making use of working agreements with your team? I’d love to hear your insights on Linkedin.
