PMI Sites
Register
Disciplined Agile
Search

    Practice: Unfinished Work

    Why to Do This Practice

    What should you do with unfinished work items at the end of an iteration?

    The answer is simple, but it has some nuances to it: Unfinished work is just that – “unfinished” – and needs to be finished in the next (or more distant) iteration in order to bring value to the stakeholders.

    Being unfinished in nature (the work is incomplete by the team’s definition of done) such work items do not contribute to the delivered value and hence the team is not recognized for their expended effort (yet).

    Who Does This Practice

    Here are the roles involved in this practice:

    • Product owner
    • Team lead
    • Team members 

    What to Do

    Inputs

    • All work items not finished in the last iteration
    • Product backlog

    Approach

    When planning the next iteration, reassign unfinished work items form the previous iteration back to the product backlog, in their entirety.

    Discussions

    What About the Effort that We Put in Already?

    It can be tempting to credit the team for the effort expended so far, but this outdated mindset of ‘completed effort’ as a measure of progress works against the agile thinking of delivered value being the only thing that counts.

    Case in point: imagine that a team starts all work items in an iteration on day 1, in parallel, and doesn’t finish any of them in the iteration despite spending their full time on it. Their delivered value at the end of the iteration will amount to zero.

    Why Is Unfinished Work Considered Waste?

    While a work item was considered high enough priority when the iteration was planned, it may be seen in a different light at the end of the iteration and may not make it into the next iteration. For example, higher-priority items may have been added to the product backlog in the meantime, pushing the unfinished work item out of the next iteration. Any already expended effort on the work item is considered waste because it was spent prematurely (or in vain, if the work item is ultimately dropped) with no value to show for it.

    How to Avoid Ending Up With Unfinished Work?

    If your team regularly ends up with unfinished work items at the end of iterations, you should analyze the underlying root causes and try to find a way to avoid it. There are many reasons why this can happen, especially when the team is new or they are working with new technologies or in a new domain.

    Using the team’s velocity and past iterations as guide, make sure to leave enough “slack” in the iteration plan to allow for all work items to be completed. It is better to take on additional work towards the end of an iteration, for example work off some technical debt or pair up with other team members, than to overload an iteration plan at the outset.

    There should also be a strong bias for completing existing open work items before starting anything new. For example, nearing the end of the iteration, team members with no more tasks to finish can help to finish off stories that are still open, thereby minimizing the amount of unfinished work.

    What If We Just Split Off the Completed Part and Call It ‘Done’?

    Story splitting is an effective method to break down work items into smaller, still well-formed, fragments such that each resulting work item represents and delivers stakeholder value. However, this method should only be applied to work items on the product backlog, typically by the product owner, not to work items that are already in progress.

    Things To Look Out For

    Is unfinished work at the end of iterations an anomaly, or does it happen frequently? If it happens frequently, the team should review the way they plan their iterations and try to identify ways to finish all work within an iteration.

    Is velocity “forced” upon the team, thereby forcing the team to plan for too much work? I.e. is there a management expectation that velocity can only go up, not down? If this is the case, management needs to be coached in the underlying ideas and values of agile iteration planning. Also, the team needs to be transparent about their work.

    Outcomes

    Unfinished work items from an iteration can end up in one of two places:

    • They can be planned to be completed within the upcoming iteration
    • They can be reverted back to the product backlog (where they can also be dropped from the current scope) 

    May 2023

    Developer Overview

    Related Resources