All work that needs to be done by cross-functional (Product) Development Team is in the Product Backlog. Each item in the product backlog (product backlog item, PBI for short) is expressed in a way such that the value of PBI is transparent to the Product Owner.  During the Sprint, the Development Team works on the PBIs to build the Increment (ideally the “Increment” should be built incrementally, one or few PBIs at a time). The Scrum  Guide states that

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition …. It must be in useable condition regardless of whether the Product Owner decides to actually release it.

and

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The “Definition of Done”  (DoD for short) is crafted in such a way that it creates a shared understanding of what “Done” means for the Scrum Team. Specifically, when the Increment is a  “Done” increment, it means that there are no technical or non-technical tasks pending which will prevent the Product Owner from shipping the Product Increment.

Incomplete or unfinished work

Imagine a scenario where the Development Team pulls in 5 PBIs into the Sprint. As the Sprint progresses, the team face some impediments, they also discover and learn a few things that they were not aware before. At the end of the Sprint, despite the best efforts of the Scrum Master (to remove the impediments) and the Dev. Team, the team is only able to complete 4 PBIs which make the “Increment” are “Done” as per “Definition of Done” and for the 5th PBI, some work is done (say, programming), and some work is still yet to be done (say, testing).  This PBI is “Incomplete work” or “unfinished work”. This is unintentional (or rather should be !!), nevertheless is a waste and the team should strive to minimize this waste in the future.

The incomplete PBI is not part of the Increment and goes back to the Product Backlog. This does not automatically go to the top of the backlog and cascade into the next Sprint, rather the Product Owner is responsible for ordering it (based on discussions with Development Team, the value of the PBI then, market factors, etc).

Undone work

When large groups adopt Scrum, despite the groups’ best effort to slice the PBIs to thin vertical slices (read small units of work valuable to the customer or to the PO), at the end of the Sprint, there may be some work left do be done to release the Product Increment. But they still need a shared understanding of what this “Done” Increment would mean to the Scrum Team and stakeholders. So they may start with a Definition of Done which is less than ideal. Example – the Development Team may do all the work except performance testing as Testing is outsourced to a vendor in India and only they has all the necessary skills, tools and access to appropriate environment to do performance testing. Note that this is an impediment which the team may not be able to overcome immediately

Undone work = Increment with Perfect DoD  - Increment with Current(less than ideal) DoD

This less than ideal Definition of Done is acceptable and may exist because of various constraints (read impediments)  or lack of skills (impediments) and current practices. The “undone work” here (because of the less than ideal DoD) is intentional and is by design. It is important to note that this “undone work” grows as the team builds their imperfect Product Increment each sprint.

I am not suggesting that teams should start with less than ideal Definition of Done. Undone work is a big risk as it reduces transparency to the Product Owner and creates a false sense of progress. It also causes significant delays, reduces flexibility and may delay the release as defects can be found when finishing the undone work.

Starting with less than ideal DoD should be an exception than being a norm. “Build Quality In” is a lean principle and the team should strive to build a releasable Increment each sprint (with an ideal Definition of Done).  And in exceptional scenarios, when teams start with imperfect DoD, over time, they should gradually expand their current Definition of Done to make it ideal.

So how do you handle “undone” work? I will expand on that in my next blog post.