Done and Undone Work

How fast a software delivery team can release a completed and valuable feature to production is a measure of both customer satisfaction and the maturity of delivery practices for that team.

While some teams can release software multiple times a day to production, other teams require weeks of additional activities to complete before they can release it to production. Understanding the definition of done and undone work for a delivery team can give us a better awareness of the current state of the delivery practices for that team, and help us take the right action toward the next level of improvement.

Definition of done. Let’s start with the definition of done. Most delivery teams have an explicit or implicit list of criteria based on which they mark a work item as done. For example:
– Coding standard is met
– Code is peer-reviewed
– Code is merged
– CI build has passed
– Unit tests have passed
– Acceptance tests have passed
– Integration tests have passed
– Successful deployment to a staging environment

Undone work. In simple terms, these are the additional work required to make a feature shippable or releasable to production. A software delivery team may complete all work items related to a feature based on the above definition of done, however, it may not be able to release that feature to production due to additional work required to be done, which is referred to as undone work. For example:
– Security scan of the code
– Manual regression testing
– Manual penetration testing
– Performance testing
– Third-party software integration testing
– Completion of operational documentation
– Completion of helpdesk documentation
– Obtaining approval from a change advisory board

In most cases, the delivery team may not have the capability to complete the undone work and rely on several external teams. Those teams might have their priorities and constraints.

Once we know the reality in terms of the definition of done and undone work, the next question we need to answer is how can we reduce the undone work by extending the definition of done for a delivery team. In other words, expanding the capability of the delivery team so that they can complete all the required work to make their feature shippable or releasable to production. This concept is also known as shift left by doing various quality assurance activities early during the development phase.

Let’s see some possible examples of how a delivery team might reduce the undone work. Regarding security scans, they might include this as part of their definition of done and automate the process as part of their CI build or a separate nightly build for faster feedback instead of leaving that for later. Regarding regression, there could be a combination of automation and architectural transformation to minimize the need for manual regression. Not easy, however, we need to start somewhere to make improvements.

Apart from technical excellence and automation, another intermediate option is using sensible human judgment to decide whether a particular undone work is required or not for a particular release based on proper risk assessment.

Reducing undone work by extending the definition of done is not easy. It may require investments in technical excellence, automation, and additional resources. However, the visibility of the definition of done and undone work in the context of a delivery team gives a clear picture of the current state.

The ability to ship or release valuable software should be the ultimate goal of a software delivery team. By becoming aware of the current definition of done and undone work, a team can take some deliberate actions and gradually improve their software delivery practices over time. For some actions, a team might require broader organization-level support and changes.