Unfinished work

November 21, 2007 by Artem

Agile processes recognize and try to effectively use the fact, that software creation is a difficult and not very predictable process. Therefore quite often teams applying agile processes end up with the not completing all the committed product backlog items by the iteration end. Teams just starting to employ Scrum or XP can sometimes end up with half of the items being not completely done. Naturally in such a situation people are tempted to finish the uncompleted stuff as soon as possible. Some think about extending the iteration length for a week or two, some think about marking the item half-done, adding half of its size to the team velocity and continuing with it during the next iteration.

As in pretty much everything in agile processes there is no universal truth and every team can develop its own style for handling the unfinished work. However, there are the default recommendations that work well for many teams. Changing the iteration length is rarely a good idea. It breaks the timebox, makes everybody think that "couple of days more is nothing serious", while projects are always a year late one day at a time. Eventually it makes the team less predictable and forces the customer to trust your commitments less. Recording some velocity for unfinished item is also not too good idea. With unfinished item it is not always clear how much time is needed to complete it, the unfinished item cannot actually be used. Eventually it forces the customer to consider your velocity containing two parts: completed velocity and half-done velocity.

Back to the backlog

The usual rule that works for many teams is to put the undone work items back to the product backlog. If the item is half-done it is quite probable that it will be chosen as a top priority thing by the product owner (also remember that it is team who selects items to work on). However, sometimes with the latest market information at hand it might be more valuable to do another item first. Agile is not about the efficient "resource utilization", it is about maximizing ROI - working as little as possible to get as good results as possible. Working on what's the most important for the customer, not on what was the most important for him during the previous iteration.

What do you consider is useful to do with the unfinished work? Should there always be an attempt to split the potentially unfinished item into two smaller sub-items, so that one of them could be completed during the current iteration?

Picture courtesy of James Cridland @ Flickr

Permalink