The concept of “undone” work does not exist in Scrum today, but nevertheless, it makes sense to understand this concept when Scaling Scrum . Most people confuse incomplete work and “undone” work. To understand the difference, please see here.
Ideally, you should be able to get to a perfect definition of Done before your first Sprint. This definitely has a lot of advantages. Learn how to do it here . And remember that all the work that needs to be done on the product increment(including any kind of documentation) should be done by the Development Team.
Now, about handling “undone” work. Sometime back I was with the client helping them understand their “product”. The product included hardware, firmware AND software (at least that is what the customer was paying for. The customer will not pay only for hardware or software or firmware alone). Additionally, they need to produce a user manual in English. This also had to be translated in other languages. The Development Team could generate those manuals in English (they automated it with tools, so every time they did a build, a version of the user manual was generated in English). For the “product” to be “shippable” to customers, they needed manuals in other languages as well. But it was almost impossible for the Development Team to learn a foreign language (which was also not Neo-Latin language), create a manual given the learning curve. Prior to their Scrum transformation, they hired an outside translation agency which could do the work. So what did we do?
Our “current” Definition of Done only included generating English version of the user manuals and the “undone” work became generating user manuals in the foreign languages. The external translation agency was still retained to do this work. The Product Owner could ship to English speaking customers at the end of the Sprint (upgrade software or firmware or a new version of the hardware) but if it had to be shipped to customers speaking a foreign language, a two week lead time was required for the translation agency to prepare the manual in the foreign language. It did create some delays, but nevertheless, the stakeholders had a shared understanding of what “Done” was and why a two week lead time was needed for producing a user manual in a foreign language.
The story is not over yet. The Dev Team was not too happy about the “undone” work. As they thought about reducing the lead time for non-English speaking customers, and the return on investment on learning a new foreign language, the improvised. They used Google translation services to automatically generate the manuals in foreign languages (technically two versions, one with Google, another with another translation service, just in case) and so a “rough user manual” was available to customers who were willing to live with an imperfect user manuals at the end of each Sprint (in case the PO decided to ship the product to foreign language speaking users). The external agency were then tasked with proofreading and correcting errors for the final version of the user manual.
Helping Teams and Organizations be Agile 