Three Ways to Handle Unfinished Work - Mike Cohn

Three Ways to Handle Unfinished Work - Mike Cohn

Over the past three weeks, I’ve been sending you tips about spillover on agile teams. We’ve talked in depth about the problem of habitual spillover—when a team routinely rolls unfinished work forward from sprint to sprint.
This week, I want to share 3 ways to handle the unfinished work that will occasionally be left over by even a great agile team.
 

1. If You Want a Guarantee, Buy a Toaster

My first bit of advice for how to handle unfinished work is to remember that even the best agile teams sometimes miss their goals. That’s OK and even desirable to a certain extent.
Sprint goals are not guarantees. (As Clint Eastwood’s character Nick Pulovski says in The Rookie, “If you want a guarantee, buy a toaster!”) Leaders, stakeholders, and even the team themselves might need an occasional reminder about this.
A team’s commitment to a sprint goal is a promise to do its best to achieve that goal. If team members are perpetually forced instead to make a guarantee, they will guarantee less in order to be safe.
Sometimes a team needs to make a guarantee. There might be times when a client or customer needs a capability by a certain date. The finance group may need to run year-end reports in early January, for example.
In general, though, we don’t want to force a team into a guarantee. We ask a team to commit to something reasonable and then we’re understanding if they miss it. Falling short on the occasional commitment is not a failure-–it’s usually a sign of bad luck or a team that’s striving to do too much.
 

2. Don’t Roll Work Forward Automatically

My second bit of advice is to resist the urge to automatically roll over the unfinished work into the next sprint. Put it in the product backlog instead.
The item may be back on the product backlog for a millisecond, but there should be a conscious decision by the product to continue work on it.
(Logistically, I don’t care if it’s easier in your tool of choice to move the item to the next sprint rather than to the product backlog first. The key is that there is a decision to continue the work.)
If the product owner decides the team should work on the partly finished item immediately in the next sprint, bring in the product backlog item as is. Don’t re-estimate it. Don’t rename it. Don’t take partial velocity credit. Just bring the item into the next sprint and take the full velocity credit when it’s complete.
But if the item is deferred for later, go ahead and split the story into what makes sense. Take partial velocity credit for the work you completed last sprint, then write a new story that describes only the missing functionality and estimate that story.
 

3. Document the Cause

My final bit of advice for dealing with unfinished work is this: Whenever work is unfinished at the end of a sprint, the team should take time in the retrospective to consider whether it was preventable.
Sometimes unfinished work is just bad luck or bad timing, such as a team member being ill or a problem being found late in the sprint that could not have been found earlier. Sometimes it’s just the result of aiming too high for one sprint.
But you might uncover something that is becoming a bad habit.
Whatever the cause, it’s always worth considering whether something can be done to prevent it from affecting future sprints so that your team can succeed with agile.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/