Definition of Ready - what we forgot to tell us

Introduction
What is DoR
Why DoR is needed
Where to apply DoR
When to apply DoR
INVEST model
Conclusion
Bibliography

Introduction

Surely you have heard more than once, rather, you even used the Scrum - Definition of Done artifact with the command later in the text - DoD. Perhaps use it without even realizing it. There are many Russian-language articles written about DoD. They talk about him at conferences and trainings. Understanding why this artifact is needed, and finding examples is not difficult. DoD defines the criteria by which each team member understands that the task is closed. The deep purpose is to synchronize the Done concept, between each member of the team. On these criteria, often, the team works during retrospectives. There is a similar artifact, which for some reason is not mentioned in the Russian-language resources of Scrum, and where this artifact is mentioned, no explanation is given what it is, why it is needed, and how to use it.

Most likely, your team heard phrases like: “We overwhelmed the target, because we misjudged the task”, or “Our PO came again with a task without proper description”. In my team, such “signals” appeared more than once, and for a long time I was looking for a way to solve this problem.

At Definition of Ready, hereinafter referred to as DoR, I came across by chance, in a profile chat dedicated to Agile. Having tried to find information, I did not find a single mention in the Internet on this topic. Therefore, I went to read and translate English-language articles. Now I am sharing with you the result, I hope this will help to make your team even cooler and more productive.

What is DoR

So what is the DoR? Google translator will tell you that this is the "definition of readiness." If the DoD includes the criteria for completing the task, then the DoR is the criteria for the readiness of the task to be taken into operation. That is, if the task meets the criteria from the DoR, the team can take it on the planning work. It seems to be simple, you probably already started to come up with how, finally, with the team, make a list of requirements for your PO to write a ton of documentation, and the rest of the team could sit at their computer and silently write code. This is only the beginning, and DoR is not what it seems at first glance.

Why DoR is needed

First, answer the question: why do we need this artifact? What benefits will he bring to the team? DoR will help the team:
')

1. Avoid starting work on features that do not have a clear definition of completion criteria. The team will understand when the User Story is considered complete, and what needs to be done to do this.
2. Do not spend a lot of time wasted on long discussions, poorly thought-out tasks. Pre-processed task - save the time of the whole team. Calculate how much time it takes to discuss a “bad” task, for one person. Now multiply by the number of people in the team. And now on the number of such tasks.
3. Focus time and energy on things that are as “safe” as possible. One of the most powerful demotivators is the functionality that is thrown into the trash can.
4. Involve each participant in the discussion of tasks. Firstly, it motivates the team. Secondly, it helps to reveal each member of the team as a specialist. Third, the developers will offer their vision of the problem. When discussing, other solutions may arise that will be fundamentally different from the original idea.

Let's take a look at the list of problems that indirectly or directly result from the lack of DoR:

1. Regularly there are differences in the understanding of the problem, between team members. By the end of the sprint, the discrepancy increases, which leads to incidents when changes occurred in the development process, which is natural. But in view of the fact that these moments were not fixed, only he who directly encountered this knows about them.
2. Requirements for functionality, change faster than the team has time to understand them. Since the task entered the sprint, with high uncertainty, by the time the unit is ready, and the "foundation" is laid, a new information appears that will require returning to the beginning. The worse the task is worked out, the more often such a situation will occur in the sprint. In the end it will lead to fakapu.
3. Often there are problems with the assessment of the result obtained from the functional, the team does not know how to collect metrics, or even worse, forgot about them. Scrum is primarily about the benefits to the customer, user or buyer. If the team does not assess the benefits of the task, it does not receive feedback and the opportunity to adjust the course of development of the product. This can lead to total failure.
4. Also, the lack of DoR, strongly influences testing, and instead of QA testing expectations on User Story, it will test the expectations of developers. The code can work perfectly, autotests will work like a clock, but on Production the functionality will not work.

In the end, this leads to the release of a product that is not working, useless, does not solve the immediate problem. And this is an empty time spent, which everyone wants to spend on important things. In one of the articles, I met a great saying: “Garbage entered, garbage left.”

Where to apply DoR

DoR is used on the Product Backlog Refinement, hereinafter referred to as PBR or a more familiar artifact name: Grooming. During this activity, the User Story becomes ready - Ready. This means that the result of the event, in the Backlog of the product, will be Ready US. DoR is needed to describe the state in which US can be discussed in planning. This is called Takin in - adopted by the US.

To go further, pay attention, as Jeff Sutherland, one of the founders of the Scrum and Agile manifesto, talks about DoR and DoD in his videos. Sutherland introduces the concepts of Done-Done, and Ready-Ready. When a team member says that the task is ready or completed, it is assumed that it meets the criteria that the team identified in DoD and DoR, respectively. This is an important aspect, each team member must understand it, and not forget. Otherwise, there are funny situations when Peter will tell the Daily that the task has already been completed, and then it turns out that it is necessary to finish the tests there, and it would be nice to refactor the code, and the Code Review has not yet passed.

Thus, until the US reaches the Ready-Ready state, it does not exist, and is not discussed in planning. The back part of the backlog should consist only of the US, with the Ready-Ready state. The best way to achieve this is to work the US with the team. This will allow you to look at the task from different angles, to involve each team member in the process, and subsequently to develop collective responsibility for the functionality released. Developers will be responsible for the result and quality, if they realize that this is the fruit of “their” teamwork.

When to apply DoR

When a team understands during PBR that the task does not comply with the DoR, and carries with it too much uncertainty, make a list of questions, select a researcher, and postpone the task until the next PBR. In my team, it was called Research, but later we switched to Spike from XP, because we thought it would bring more results and clarity on the outcome of the study. Be sure to limit the study by time, and mark the result you want to get on the total. During a Spike, a researcher can involve any help from outsiders, such as participants from other teams, methodologists, POs, architects ... well, anyone who he sees fit. Result - answers to questions, new data, prototype. If there are a lot of such User Story, in each sprint you can take 1-2 Spike, for the next iterations, thus ensure a constant flow of Ready tasks.

As mentioned above, the DoR is a set of criteria. The team can try to make these criteria. Work through those “signals” that are traced in iterations. Discuss these points in retrospectives, find the underlying cause. If you do not want to spend the next retrospective on this, use the ready-made solutions.

Many articles describe the INVEST model, which is similar to SMART, but more suitable for User Story. In addition to the articles, this model is also recommended in the Agile literature. For example, Roman Pichler in the book “Product Management in Scrum” or Mike Cohn - “User Stories. Agile software development. ”

INVEST model

• Independent independence - Try to avoid creating US that are dependent on each other. Such dependencies cause problems when setting priorities and planning. The customer can select a high priority US that depends on a lower priority task. Dependent US need to merge, break or otherwise perform a spike.
• Negotiable negotiability - US is not a formal contractual obligation or requirement. US is not a technical task. During the sprint process, they can and should be discussed and modified. A card with a story, in whatever form it may exist, is a brief description of the functionality, the details of which should be clarified during the work. Leave notes on the cards to create a discussion about when the task will be performed. Here it is important to find a middle ground, because the excess of notes, the team will take as exhaustive information, and there will be no discussion at all. My team encountered this very quickly. The details discussed become tests that can be written on the back of a paper one, or in a comment on an electronic card. Acceptance tests, simple and clear to all.
• Valuable value to the user or buyer - “Every story must have a certain value to the user” - a statement that is false. Most constantly forgets about the buyer. Focus on your company: B2C, B2B, B2G. The main thing to avoid stories that have value only for developers. Such stories should be reformulated so that the benefits are obvious, and the customer can prioritize. You do not need to throw out architectural tasks in the trash, explain to the customer what benefits such a task will bring, and reformulate it.
• Estimable estimates - developers should be able to estimate the size of the US, that is, the approximate time it takes to be implemented. There are three main reasons why laboriousness may not be assessed:
  
  
  1. Team lacks domain knowledge
  2. Team lacks technical expertise
  3. The story is too big
  
  In the first and second case spike will help you. In the third US, you need to decompose into smaller ones.
• Small compactness - very much depends on the size of the US, too large and too small US is difficult to estimate. It is difficult to work with epics, as they consist of several US. Epic can be divided into two types:
  
  
  1. Compound. Everything is simple - we decompose. Consider the remaining points, the first thing that the command will most likely offer: divide the US according to the type of architectural layers: by US into a database, backend, frontend, and so on.
  2. Complex The large size of the US is due to their very essence, they either do not decompose, or it is very difficult. In this case we use spike.
  
  
• Testable testability - confirmation that the US was developed successfully, is the successful passing of tests. If the US cannot be tested, the team will not know when the creation is complete, or come up with the criteria themselves. And each team member will be different.

Conclusion

In conclusion: using DoR, you will not get rid of the gaps that will leak into the sprint. It also does not mean that during the sprint there is no need for constant contact of the PO with the developers. Constantly record the results of discussions in the form of acceptance tests, so none of the team will not lose understanding of the status of the task. Analyze and discuss current problems with the team, perhaps they are related to the lack of DoR.
DoR is an artifact that will allow the team to better think over the US, which ultimately reduces the risks and will encourage each team member to constantly discuss tasks. A lot of detailed information about INVEST, and User Story, you will find in the book "User stories". I recommend giving this book to each team member, or at least read it yourself and share information with them.
Write in the comments what DoD and DoR are used in your team.

Bibliography

1) Roman Pichler “Product Management in Scrum”
2) Mike Cohn “User stories. Agile software development
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com