Closing an agile project: ending work that could always run one more sprint

Predictive work gets an ending for free: the thing is finished, it is handed over, everyone knows. Iterative work has no such moment. There is always one more cycle available, so closure stops being an arrival and becomes a decision somebody has to make.

Iterative work has no natural ending

A predictive plan contains its own last day. The final deliverable is defined at the start, and when it exists the work is over, which means the closing activities are forced to happen because there is nothing else left to do.

Take that away and the ending has to be manufactured. A team delivering every two weeks can deliver for another two weeks, indefinitely, and each individual decision to continue is entirely reasonable: there is always something on the backlog, and it is always worth more than nothing. That is the trap. Comparing the next increment against nothing is the wrong comparison, and it will justify continuing forever.

The right test is a comparison against the alternative. If the most valuable thing this team could build next sits outside this piece of work, the work is finished, however much remains on the list. An empty backlog is not the signal and almost never arrives, because a product in use generates ideas faster than any team completes them.

Four things close, and not at the same time

What closes	Done when	Usually owned by
Delivery	Someone else can run it without you	Product owner
Team	People have their next assignment	Line management
Administration	Contracts, budgets and access are shut	Nobody, in practice
Learning	Something outside the team changed	Nobody, in practice

The first two are usually done well, because both have somebody with an obvious interest in completing them. Operations will not accept a handover they cannot support, and people do not stay unassigned for long.

The bottom two rows carry the failures, and the common cause is visible in the third column. Administrative closure and organisational learning are the two jobs with no natural owner, and in iterative work they are also the two that arrive last, after the team that could have done them has gone. A PMI congress paper on closing calls it the often overlooked importance of the closing process group, arguing that failing to close thoroughly exposes an organisation to real risk and loss rather than merely to untidiness.

The practical consequence is a sequencing rule rather than a checklist. Anything that needs the team must be finished while the team still exists, which means it belongs before the last iteration rather than after it. Anything that can genuinely be done later needs a named owner outside the team, because “the project” will not be there to do it.

Where the leftover backlog goes

If you close on value rather than on emptiness, then by construction there is a backlog left over on the last day. It is worth deciding what happens to it, because the default is that nothing does.

There are only three honest destinations. It transfers to whoever now runs the product, as their backlog to prioritise against their own demands, which is the usual answer where the output has an ongoing owner. It becomes the evidence for a proposal, a costed argument for the next piece of work, which is the right answer when what remains is coherent enough to be worth funding as a unit. Or it is deleted.

Deleting it is the option nobody chooses and it is frequently correct. A backlog that transfers to nobody in particular does not sit neutrally; it sits in a tool, ages, and becomes actively misleading. Two years on it will contain items written against a version of the product that no longer exists, estimates from a team that no longer exists, and priorities set against business conditions that have changed. Somebody will eventually find it and treat it as a plan. The kindest thing to do with work you have decided is not worth doing is to say so and remove it.

What makes this decision hard is that it feels like a judgement on the work rather than on the list. It is not. A large leftover backlog is normal and often a sign the team was generating ideas faster than it could build them, which is healthy. The failure is not having items left, it is leaving them somewhere ambiguous.

The handover is a period, not a date

The other reason closure goes wrong is that handover gets treated as an event on a plan.

APM research on the subject concludes that understanding handover as a transition period rather than a date is what smooths the change and closes the gap between delivery and business as usual. That reframing does a lot of work. A date invites a single meeting, a document and a signature. A period invites the thing that actually transfers capability: the receiving team running it with the delivery team available, then running it alone with the delivery team reachable, then simply running it.

Iterative delivery makes this both easier and easier to skip. Easier, because the output has been in use for months and operations has probably been touching it all along, so the cliff edge is smaller. Easier to skip for exactly the same reason: when a system has been live for a year, the moment of transfer feels administrative, and nobody schedules the shadowing period that a big-bang handover would have forced.

The final retrospective nobody owns

A team running fortnightly retrospectives will have held perhaps thirty of them by the end, and will often skip the last one on the reasonable grounds that they have been doing this all along.

The final one is a different exercise, though, and the difference is the audience. A sprint retrospective asks how this team can work better next sprint, and the team acts on the answer itself. A closing retrospective asks what the organisation should do differently on the next piece of work like this one, and this team cannot act on that answer at all. It has no next sprint. The output has to travel somewhere else to be worth anything.

Which is why it usually evaporates. The findings go into a document, the document goes into a folder, and the team disperses the same week. If the learning is to survive, somebody outside the team has to receive it before the team goes, in person, with the authority to change something. Naming that person before the last iteration is the whole of the trick.

When closure is really defunding

The last thing worth naming is the most common ending in practice, and it is not in any framework.

The APM defines closure as the formal end point of work, either because the planned work completed or because it was terminated early, and both are legitimate. What is not closure is the third thing that actually happens: funding stops, the team is reassigned, and nothing formally ends at all. No decision is recorded, so there is no trigger for any of the four closing jobs, and the work simply stops being staffed.

The consequences arrive quietly over the following year. Cloud accounts keep billing against a cost centre nobody reviews. Third party licences renew automatically. Access rights stay granted to people who have changed roles twice since. A support request arrives and there is no route for it, because the team that would have answered was dissolved without anyone appointing a successor. And the learning is gone entirely, because nobody asked for it while the people were still there.

The remedy is unglamorous: treat the funding decision as the closure trigger it actually is. The moment continuation is in doubt, run closure as though the answer is no, because a closed piece of work can be restarted easily and an abandoned one cannot be closed retrospectively. The team that could have done it has gone.