It is likely the majority of Agile supporters already use the concept of the Definition of Done (DoD), which informs when the task can, de facto, be considered completed. There are many benefits of implementing DoD. I believe that its most important aspect is that it provides a sense of security in delivering the product in line with our expectations, and the set standards.
However, this sense of security should not be built solely upon receipt of the product. It can also be provided before work begins, by agreeing upon a contract which informs when a given task is allowed to be undertaken.
Work Commencement Readiness
The Definition of Ready (DoR) is a much less frequently used concept than the Definition of Done. Personally, this surprises me considering that a properly prepared and implemented DoR is a powerful tool. On the one hand, it protects the Development Team from performing work while exposed to the risk of changes (e.g. due to the fact that the vision has not yet been presented to/confirmed with Stakeholders); on the other hand, it supports the creation of high-quality tasks by commissioners, leading to a win-win situation.
A well-prepared Definition of Ready Contract should include all the conditions that the task will fulfill before it is implemented or even earlier, planned. There is no clear rule on what such a Contract should look like each team will have its own DoR, as everything depends on its composition, the context of the product/project and the environment in which it operates. It is certain, however, that the Definition of Ready will go through a cycle, in which it may (in fact should!) change incrementally during its lifetime. On the first attempt, one will likely find that they have forgotten about many elements, or that the level of detail is too low. In the next iteration of the work, one can add DoR elements or subtract excess elements. It is a living artifact, so changes should be expected from the moment the product or project comes to exist. This is mainly due to two reasons: along with the life cycle of a product/project, the requirements for it may also change, and as the team matures and experiences new situations, the need may arise to change or adjust the decisions that have been made earlier. It is only natural.
Process completed with Contract
The Definition of Ready Artifact should be a contract between its stakeholders. Currently, working as a Product Owner, I am a firm opponent of imposing my beliefs upon the team. I would prefer to work out solutions together, rather than imposing them in a dictatorial manner. Therefore, I am a strong supporter of joint DoR determination, thanks to which a high level of commitment will be maintained by every party involved.
The meeting initiating the creation of the Definition of Ready should be attended by all interested parties: people who will use the DoR artifact and who will also agree on a Contract amongst themselves. These will be both development roles including the development team (for example, Programmers, Analysts, Testers) – and „management” roles, such as Project Managers, Product Owners or Servant Leaders. To sum up, all the people who create tasks or influence their creation, as well as everyone else who will work on these tasks.
During the meeting, each party should feel comfortable to speak up, and all of the participants should come out from it confident that the right decisions have been made. The facilitator of the the event is obliged to conduct it in a way that all elements of the discussion are maintained. The brainstorming technique will work particularly well in this context.
It is best to start the discussion with a reflection in the area of false starts on tasks. It is also worth asking oneself the following questions:
What does a poor-quality task mean for us as an organisation; or on the contrary what constitutes a high-quality task? What does one usually miss, and what information do we most often forget or omit? Consider under which circumstances the team works most effectively on a task, and when it wastes time, e.g. guessing or making assumptions which result in a high risk of returning to the task in the future.
The list of ideas should be grouped and redundant. All written down in one document, and voilà we have created a living artifact Definition of Ready! Each participant should feel comfortable with it and accept the Contract.
Below is an example of what a potential DoR for an IT product task could look like.
Example of Definition of Ready for an IT product task
The DoR life cycle should include an element of verification of its correctness. A retrospective is a good ceremonial for that. During a retrospective, one can discuss the optimization of the Definition of Ready, which will then become the opener for the discussion on introducing improvements.
One last but not the least Important element: the Definition of Ready should be transparent and available to anyone interested! It can be displayed on a board inside the room where the team works, attached as a checklist for tasks in Jira or added to the Wiki in Confluence. The place does not matter much, as long as its accessibility is ensured.
Danger of DoR
There are many DoR superlatives – I am a strong supporter of this concept myself. It allows me to prepare high-quality tasks for the team. I can noticeably see a reduction in the number of repeated approaches to implemented functionalities.
There is, however, a risk associated with having a DoR: that the Team does not interpret its elements clearly. A zero-one approach to classification will begin to define whether the task can or cannot be started. When the Definition of Ready includes the rule that something MUST be done before the next thing begins, it leads us to a waterfall way of working. For example, if the team insists on having UX completed before starting work, the entire design phase will need to be completed before actual programming. In this case, agility is „lost”. Refusal to undertake a task that does not meet the DoR may result not only in frustration, but could also be detrimental to the project itself, e.g. exposing it to the risk of not being completed on time. Therefore, common sense, flexibility and agility education are very important.
Summary
The Definition of Ready is certainly a concept that can help you achieving success. For the roles who provide the tasks, it is a kind of guide on how a given task should be prepared. For developers, it is a checklist to ensure success in delivering the task at hand. The contract concluded between its stakeholders gives each party a sense of security in the context of implementation of the workload. In the right „hands”, and with the right mindset, it becomes a very powerful tool!
Holistyczna liderka product managementu z technicznym zapleczem i ponad dekadą doświadczenia w budowaniu produktów IT odnoszących sukces rynkowy i wyznaczających kierunek w swoich segmentach. W swojej pracy łączy strategiczną dyscyplinę z głębokim zrozumieniem psychologii, co pozwala jej trafnie odczytywać potrzeby użytkowników, wspierać zespoły i podejmować precyzyjne decyzje produktowe. Poza pracą inspirują ją odkrywanie świata, natura oraz twórcze projekty z obszaru rękodzieła i videomakingu.
Monika Potiopa is a holistic product leadership professional with a technical background and over a decade of experience building IT products that achieve market success and set direction within their segments. She combines strategic discipline with a deep understanding of psychology, enabling her to interpret user needs, support teams effectively, and make precise product decisions in complex technological environments. Outside of work, she draws inspiration from exploring the world, nature, and creative projects in crafts and videomaking.