Definition of Ready. How We Saved a Lot of Time by Solving the Problem of Poorly Described Tickets

Unfortunately, as I’ve experienced too many times before, such a scenario is not that far from the reality of project management. It all boils down to finding the right form of task description. In most cases, we balance between poorly described tasks, which results in extra clarification meetings or calls during a sprint, and exhaustive, detailed lists of requirements which tend to kill developers’ creativity.

So, how to make sure that a task is ready to enter a sprint and the information provided in its description is just enough for developers to understand the scope of a task, but at the same time not impose an implementation? We came up with the Definition of Ready, taken from the Scrum playbook. In this article, I’ll guide you through the whole change process based on a real-life example.

Ready for what?

First, let’s start with DoR (Definition of Ready) which is nothing but a set of requirements which need to be fulfilled for each task for it to become a sprint candidate. If a task is described according to DoR, the team can see what needs to be done and how much effort it will take to complete the assignment. Moreover, it increases the predictability of sprints.

The problem we faced explained in an example

To be more transparent and to illustrate the idea of DoR, I will show it on an example taken from one of our projects where the lack of information flow caused a drop in team effectiveness. In this particular case the team consisted of:

• A client, who acted as a Product Owner. He was setting priorities, making sure the business goal is clear and understandable for the whole team,
• Project Manager, who was acting as a Scrum Master and helping our client to shape sprints and making sure development work goes smoothly,
• There was also a Designer who was preparing views to be implemented by frontend developers,
• Frontend developers responsible for adding new fronts to an existing application,
• A backend developer working on the app’s logic,
• Quality assurance to check if the delivered product components are fully functional.

What drove the team to redefine or, actually, define a Definition of Ready? The previously mentioned lack of a consistent information flow led to a situation in which the team needed additional calls to clarify what should be done within the tickets, which impeded their velocity. Additionally, despite constant discussion, there were still gaps in the delivered features, which were usually rejected by the Product Owner.

What was missing in these tickets? Type of validation, app behavior after a certain action, animation and relation to other stories, tips on connection with backend etc. What was the final effect which triggered the change? The tickets were DONE, but the feature itself was not working. Luckily, the Project Manager (Jędrzej) was working with other PMs in our internal estimations group and got help from his colleagues.

How Netguru tackled the challenge

As the mentioned situation was not a single case, we decided to investigate the incidents a bit further. We took a closer look at our delivery teams and compared what info is placed in a ticket. After analyzing the examples we came up with an initial Definition of Ready template and implemented it in 31 projects, which is around 30% of all active projects in Netguru, including the one described above. You can see that template in the DoR in a nutshell section .

Results

After a few weeks of using the new DoR, we started seeing changes in the projects. There was less confusion around the scope of tickets, which also meant developers were not losing so much time on additional calls. To make it more tangible, let me add a small calculation: If we assume that each developer was sacrificing an additional 30 minutes every day for an extra call, and multiply it by 4 people, 5 days, and 4 weeks, it adds up to over 40 hours per month. Nice, right?

By providing key business requirements we also decreased the possibility of developing a feature with misaligned business value, costing us extra time and money. If we do not include information about the business need, a developer might make certain assumptions (which is a human thing) and implement a feature in a way that is the most logical for him/her. An individual’s way of thinking is not always in line with the end-user’s needs and product concept. On the other hand, flooding a developer with a long list of must-haves will not only undermine his/hers motivation and ambition, but also move the focus away from the main purpose.

But moving on. The most important aspect is that the delivered tickets were reflecting the reality: once a ticket was DONE, there was no coming back, the feature was up and running. Naturally, the velocity increased due to time saved and a constant information flow. Of course, it took about 4 weeks before the whole team adopted the new ticket description template, but it got smoother with time. The two last benefits were reflected in increased trust within the team and a common understanding of the current scope.

DoR in a nutshell

Once you are familiar with the case, you can take a look at the list of tips we gathered during defining the process that may come in handy. Please note that these ideas can be modified and adjusted to your project’s needs.

1. Catching the user perspective: It is always good to start with a user story just to feel like an end user for a moment. While writing, remember about outlining the type of user (if there is an admin and front user for example), the specific needs of this user, and how can this need be fulfilled by the product you are building. For example:

As an admin, I want to see detailed user info, so that I can answer all the questions asked via the customer service desk.

2. Reference a user flow. It is always appreciated when user flow is presented in the ticket. If you are not able to present the whole user path, at least make sure to state the screen before and after. Giving a broader context to a ticket will help the developer implement the right feature simply because there will be no need to investigate. If you can present user flow in the form of a graphical diagram (eg. using BPMN or UML), it will be appreciated by the development team and will definitely speed up the whole development process.

3. Why a certain task needs to be developed. Write down why this feature needs to be implemented and what are the implications for the whole product. It helps to get a business perspective and helps understand the product better. Sometimes it also allows us to spot contradictions or bugs. If possible, remember to add screenshots, designs or videos - anything that may help a team member understand a task.

4. Acceptance criteria. Specific requirements which need to be met for a task to be marked as completed. It can include values, color, shapes, actions or any other defined attribute. In design projects, this will be a section for designs or wireframes delivered by a PO.

5. Technical requirements or recommendations. It states whether there are extra technical aspects which need to be solved or implemented. Examples include an additional security layer, an external API integration, a format of data sent, custom gems etc.

6. How can it be tested? Testing scenarios are quite time-consuming, but definitely worth the sacrifice. In order to prepare this section, follow these four steps:

• Scenario - action performed or condition met
• Given - The user logs in as a USER type A
• When - User account is verified
• Then - User should be able to submit a request

To keep in mind - why does having a DoR help?

Setting and applying a DoR boils down to the essence of establishing standards within a project. By clarifying what user stories should look like we reduce the amount of time which would be spent on clearing up details during the sprint. As a result, a developer needs to stop his work in order to contact the rest of the team and figure out the missing part. Long story short, stories which are ready should be clear, concise, and most importantly, actionable. Only then tickets should enter the sprint.

What may impede the process of introducing a DoR?

The difficulty of creating DoR stems from a few aspects.

1. It takes time. A DoR, once set, needs to be developed and mastered as a project progresses. It can take up to a few weeks before you see the benefits from introducing it. Also, the lack of immediate effects can be discouraging for agile teams used to quick, tangible results.
2. It is strongly dependant on the Product Owner’s technical knowledge, as well as the team’s experience and engagement. One person is not able to provide the right description. Business background and user perspective can be provided by a PO, but the technical part needs to be filled in by a developer or a QA. Please note that the PO is responsible for setting priorities and creating tickets, but it is the whole team who is responsible for ticket descriptions.
3. Lack of consistency among team members. The challenge occurs when a PO has already deducted and follows a set rules and guidelines, but a few team members feel much more comfortable with talking a case over on a quick call. The summary of such call is not reflected in the ticket itself.

If you are not sure your team understands the DoR, run a simple test. Create a survey using Google Forms with a simple question: Give the definition of ready established in the project you work in.

Check the answers and grab a beer if the responses are the same. If not, set a meeting and write down your Definition of Ready. The sooner you have it, the less time will be wasted during development. Also, please note that not all tips mentioned above may be suitable for your project. Take what you need and adjust the DoR together with the team. Good luck!