The task is ready! Or not? Definition of Done and why it is needed

The task is ready! Or not? Definition of Done and why it is needed

A typical dialogue between a manager and a developer. Somewhere in a distant galaxy.

Developer: So
Manager: Let’s roll on users?
Developer: Let’s go
Manager: Something I don’t see in the production?
Developer: Well, we need a couple more days to do a code review, wait for QA to test, build and roll out the release to prod, do some data migrations, and then we’ll open the feature to users
Manager: But you said that the task is ready?
Developer: So

I think many of us have witnessed or participated in such a dialogue. Each side believes that the task is ready, but the understanding of the state of readiness is strikingly different. As a result, the expectations of each of the parties differ greatly from reality, which negatively affects the communication between them and, in general, the development of the product. So how to avoid this?

Hello everyone, my name is Mykhailo Mazein, I have been working as an Engineering Manager for the past 4 years. In addition to managing the team and setting up development processes, my area of ​​responsibility is also to establish interaction between engineers and the business. In my article, I will tell you how to solve the problems described in the example.

Definition of Done (DoD or readiness criteria)

This term came from Scrum, and perhaps many of those who work or have worked with this methodology are familiar with it. However, let’s try to talk about it in more detail.

In order for the development process to be effective, it is very important that all participants in this process communicate in the same language and operate with the same concepts. Definition of Done is an agreement that clearly describes the criteria for task readiness, and what we mean by a “done task”.

Let’s understand each other! Consider the full life cycle of feature development*:

*Here I introduce a new term – “feature”. In this context, the tasks included in the development are part of the implementation of the feature. A feature is some functionality that (potentially) brings value to the end user.

Feature lifecycle

In this diagram, we have displayed the states through which the feature passes, as well as the processes that allow changing these states. In reality, your life cycle may be more decomposed and consist of more steps, but logically it will most likely be very similar to the one presented.

Let’s take a closer look at each stage:

  1. Idea (Idea) – Work on any feature begins with a raw idea. We need to prepare our raw idea so that engineers can begin the development phase by bringing our feature to a Ready state through the Refinement process. This process can be known as PBR, grooming, backlog preparation. In this article, I will not dwell on this topic in more detail.

  2. Ready (The feature is ready to be put into operation) – At this stage, we already understand in what form we want to see the implemented feature and have a set of tasks for its implementation. What is a ready-to-work task is also a very good question that should be synchronized between all participants in the development process. And that is why there is such an agreement as the Definition of Ready. The conversation about him goes beyond the scope of this article, but there is already an article on habr that reveals this topic (https://habr.com/ru/articles/417101/). A ready-to-work task can already be implemented by the development team to move it to the Done state through the Development process.

  3. Done – the task is ready (completed, not to be confused with Ready). And here we return to the question – what is a “ready-made task”? The communication problem shown in the opening example is that developers and managers refer to different states of the feature in their conversation. The status of developers is “Done”, and the status of managers is “Potentially shippable”. In an ideal world, these states should coincide, but in reality this often does not happen. Most often, this is due to the fact that the technology cannot cover all criteria related to Potentially Shippable. For example, to roll out the feature to users, we need to prepare marketing materials or an advertising campaign. Or our testing team works separately from the development team and has its own separate pipeline. Or the devops team, which is responsible for deploying to production, is outsourced to us and works separately from the development team. In order to make the development process clear and transparent for all participants of this process, we need to develop a Definition of Done agreement, which will describe what exactly the development team undertakes to do as part of the Development process. All work that for some reason cannot be done at this stage will be done in the Undone Work process. The more work we need to do in Undone Work, then we move the “Potentially shippable” state away from the “Done” state.

  4. Potentially shippable – The task/feature is potentially ready for release to users. In this state, we have a fully functional feature. At this stage, the manager makes a decision about whether we will roll out the feature to users (Delivery process) or not (this also happens sometimes). The rollout can happen both to all users at once or in stages, it already depends on the chosen release strategy.

  5. Shipped – The feature is available to all users for whom it was intended.

Based on the above, we can derive the following formula:

Potentially shippable = Definition of Done + Undone Work

The more Undone Work, the more we have differences of opinion on feature/task readiness between managers and developers. It follows that the stronger our Definition of Done, the closer we are to Potentially shippable. Let’s consider examples of weak and strong Agreement Definition of Done.

Weak DoD:

This agreement describes a single basic readiness criterion. Is it enough to consider the feature in the “Potentially shippable” state? Most likely – no. We still have a huge layer of Undone Work, which, moreover, is unstructured and opaque to most participants in the development process.

Strong DoD:

  • The code is written

  • Autotests are written

  • Passed the code review

  • The design review has been completed

  • Functionality tested by team/stakeholders/QA

  • The documentation is written

  • Code in production

This agreement allows us to minimize our Undone Work and get as close to Potentially shippable as possible. It also helps to structure the work that engineers perform in the Development process. With such a DoD as part of Undone Work, we may have activities outside the framework of the engineering part, for example, the preparation of marketing materials.

It is important not to forget the part of the work that remains in Undone and to try to make this part as transparent as possible for all participants in the development process. It is also important to ensure that Undone Work has responsible people. If we see regular patterns within Undone Work, it’s worth considering how we can strengthen our DoD to reduce the Undone portion by closing the gap between Done and Potentially shippable states.

Share your experience in the comments!

Related posts