Episode Details

Back to Episodes
Three Ways to Handle Unfinished Work - Mike Cohn

Three Ways to Handle Unfinished Work - Mike Cohn

Season 5 Episode 1309 Published 1 year ago
Description

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 v

Listen Now

Love PodBriefly?

If you like Podbriefly.com, please consider donating to support the ongoing development.

Support Us