When the team doesn’t finish the work in a sprint

Don’t pan­ic. It’s not uncom­mon for a team to have some unfin­ished work at the end of the sprint. One of the biggest mis­con­cep­tions about Scrum is that it is per­ceived as a sil­ver bul­let solu­tion to solve any prob­lems in your organ­i­sa­tion. It’s not like that! What Scrum does instead is to help you max­i­mize trans­paren­cy and thus iden­ti­fy prob­lems on a method­olog­i­cal, organ­i­sa­tion­al or com­mu­ni­ca­tion level.

It’s up to you to decide what will you do with this infor­ma­tion. Some might not like it and will try to mis­use Scrum and mod­i­fy the frame­work to an extend that will hin­der it from exhibit­ing poten­tial prob­lems, which in this case will stay hid­den instead of being addressed trans­par­ent­ly. Maybe you are famil­iar with: “This will not work for us!” Oth­ers will use this infor­ma­tion to change the system.

Some Scrum teams can be rid­dled with inter­rup­tions or reg­u­lar­ly fail to deliv­er on their sprint fore­cast. Adopt­ing Scrum does­n’t auto­mat­i­cal­ly mean that inter­rup­tions or com­plete sprints will be avoid­ed. It just makes vis­i­ble when it can’t be pos­si­ble. To change the way we work will always require some cre­ativ­i­ty, team­work, prob­lem solv­ing skills and trust.

Time is up! Pencils down!

Sim­i­lar­ly, this is what hap­pens in Scrum. At the end of the sprint, teams stop, show their work and reflect. As Mike Cohn states “Ide­al­ly, a team would fin­ish every item on it’s sprint back­log every sprint. But for a vari­ety of rea­sons, that isn’t always the case.” Even though each team is unique, here are some com­mon reasons:

• Mul­ti­task­ing

When the sprint starts, after the Plan­ning meet­ing, team mem­bers start mul­ti­task­ing. This hap­pens espe­cial­ly then when they begin by work­ing on too many sto­ries at one time. There is even a worse sit­u­a­tion when man­agers ask team mem­bers to work on sev­er­al projects inside one sprint. Even if the ini­tia­tives are small, work­ing on them at the same time intro­duces huge costs caused by con­text switch­ing and wait­ing time. Set­ting WIP lim­its can help in this sit­u­a­tion. Do not start to work on anoth­er user sto­ry, until the one that is cur­rent­ly in progress, is Done.

• Large sto­ries

Even if accord­ing to the esti­mate these would fit into a sprint, there is often the case when teams don’t man­age to get large user sto­ries to Done in one sprint. A com­mon cause for large sto­ries is when the Prod­uct Own­er does­n’t look for the first pos­si­ble val­ue in the fea­ture set. When refin­ing big user sto­ries, the prod­uct devel­op­ment team should iden­ti­fy for whom they are imple­ment­ing the spe­cif­ic user sto­ry. That way, they will know also why they are imple­ment­ing it. The small­er the sto­ry is, the faster will the team see progress and learn, the faster will the Prod­uct Own­er pro­vide feed­back and see the through­put. Con­sid­er writ­ing sto­ries that are 1–2 days in dura­tion- it’s not easy but worth trying.

• Team does not deliv­er through the architecture

Team mem­bers do not focus on deliv­er­ing thin slices of func­tion­al­i­ty. This hap­pens fre­quent­ly when the team mem­bers work as experts across the archi­tec­ture — even in a cross-func­tion­al team. While the team may start with back-end, mid­dle­ware or front-end peo­ple, encour­age the team mem­bers to become gen­er­al­is­ing spe­cial­ists, to have more areas of exper­tise. Of course they will have their own pref­er­ences which is per­fect­ly fine, but they will be also open to sup­port their team to deliv­er fast a fea­ture or a fea­ture set. Pair and mob pro­gram­ming help in this kind of sit­u­a­tion and pre­vent also rein­forc­ing exper­tise. When teams deliv­er through the archi­tec­ture, one ver­ti­cal slice at a time, they can release some­thing when they want to and get feed­back ear­ly. These teams learn ear­ly what their Prod­uct Own­ers or cus­tomers want.

Always look for a root cause

Whether it hap­pens because of one of the rea­sons above or it’s sim­ply bad luck, don’t auto­mat­i­cal­ly car­ry over the remain­ing work to the next sprint. Visu­alise where the work is, select the high­est ranked work and start work­ing on it, as a team.

Use the ret­ro­spec­tive meet­ings to reflect on whether the team could have some­how pre­vent this. Tools like cumu­la­tive flow dia­gram or burn down chart can help to diag­nose and exper­i­ment with the team.

What good ways that min­imise how often you have work left unfin­ished at the end of the sprint have you experimented?

Ref­er­ences:

Cre­ate Your Suc­cess­ful Agile Project — Johan­na Rothmann

*Image by 377053 from Pix­abay