Counting Chickens: Undone Work in Scrum

As an agile coach I often find Scrum Teams to be rather confused about Sprint Backlogs. Sure, they know that they represent the planned work for a Sprint...and some may even understand that they represent a forecast and not the commitment certain stakeholders might prefer to extract*. Their grasp becomes shakier, however, when it comes to the relationship between a Product Backlog and the Sprint Backlog, and what this relationship means in terms of the Definition of Done.

I often seen this confusion manifest itself in the following way. During Sprint Planning, teams will move Product Backlog Items out of the Product Backlog and into the Sprint Backlog. They will then commence breaking the selected PBI's down into tasks. Following planning, the Product Owner will be reassured that the work is in hand and that the corresponding increment will be delivered, and will be delighted to observe that the Product Backlog has shrunk accordingly.

That's the mistake. The Product Backlog should enumerate all of the work that remains to be completed. Just because a Development Team has inducted certain items into its Sprint Backlog does not mean that they are "as good as done", and can be removed from the enumeration. That won't happen until the Definition of Done (DoD) has been met for the items in the current Sprint...and on that note, let's bear in mind that a Sprint backlog is a forecast, not a commitment.

By definition, any work that has not been completed to the satisfaction of the DoD remains undone. It must therefore be accounted for, by the Product Owner, on the Product Backlog. A Sprint Backlog is not a region of limbo where work is removed from the Product Backlog and somehow floats around until it attains the status of "Done". Work is either Done (as per the Definition of Done), or it remains undone and is therefore yet to be Done.

Remember that if a Product Owner cannot account for all undone work on the Product Backlog he or she owns and is responsible for, then that PO is not doing their job properly, and the Product Backlog is not being well managed. Product Owners should therefore be careful not to fall into the trap of thinking work is "moved" from the Product Backlog into a Sprint Backlog during planning. Only once the Sprint Review demonstrates that work has been Done can the associated PBI's be retired as complete. Apart from that, the only way for PBI's to leave the Product Backlog is for the PO to decide that they are no longer relevant to the Product.

Look at it this way. If work is removed from the Product Backlog so as to include it in a Sprint Backlog, that amounts to removing it from the Product Owner's account of undone work in exchange for a promissary note. Neither Scrum, nor indeed any other credible agile method, operates on such a basis. The proof of success lies in delivery.

* In 2011 the Scrum Guide removed the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. A team should more properly commit to the Sprint Goal.