Claim Your
Product Coins
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.
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:
This also happens from the Engineering side with examples like:
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.
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.
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? 🤔
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.
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:
Using the DoR as a tool is great as long as you don’t ignore the interaction with individuals. 😊
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:
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.
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:
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.
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 good project 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.
