Ponekad se, naravno, user story, ili bilo koji zadatak, ne dovrši tokom sprinta. Niste ni prvi ni zadnji tim kojemu se to dogodilo, niti je to nekakva posebna drama. Bitno je što se događa nakon tog “incidenta”.

Odmah da razjasnimo na početku, ne postoji pravilnik ponašanja u ovakvim slučajevima, niti će vam na vrata doći Scrum policija ako nešto napravite mimo regula. Ipak, mogu se dati neki iskustveni savjeti kako pristupiti problemu.

User Story nije niti započet

Najlakši slučaj, vratite US u backlog i ponašajte se kao da se ništa nije dogodilo (osim što trebate o ovome popričati na retrospektivi). Ako je bitan, uzet ćete ga u sljedeći sprint tokom planiranja i to je to. Ako nije bitan (možda je to razlog zašto nije niti započet?) onda se ne bi trebao pojaviti u sljedećem sprintu. Ne može jednostavnije.

User Story je započet, ali nije dovršen

Najčešći slučaj. Bitno je shvatiti zašto se ovo dogodilo:

  • US je prevelik pa niste stigli?
  • US je bio nejasan pa ste potrošili vrijeme na razjašnjavanje?
  • US je ovisio o nekom vanjskom događaju (ili pojedincu, timu, entitetu)?

U svakom slučaju, problem nije u nedovršenom user storyju već u nedovoljno dobroj analizi tokom planiranja sprinta. Probajte napraviti bolju analizu tokom sljedećeg planiranja kad ćete već unaprijed odgovoriti na gornja pitanja.

Što se tiče samog US-a, vratite ga u backlog, vjerojatno cijelog pa onda tokom sljedećeg planiranja analizirajte što je još ostalo od posla i dopunite ovaj ili napišite novi US, a ovaj bacite u smeće.

User Story je dovršen, ali je otkriven bug

Kad je otkriven bug, tokom testiranja u okviru sprinta? Pa popravite ga, i dopunite svoj Definition of Done tako da uključuje i testiranje. US nije gotov dok testiranje ne potvrdi da ne može naći bug. Bez obzira je li bug trivijalan ili ozbiljan, potrudite se riješiti ga tokom sprinta jer tako ne ostavljate repove za sobom već dovršavate stvari a to se cijeni.

Otkrili ste bug tokom reviewa? Odlično! Bolje nego u produkciji. Zapišite ga i stavite u backlog. Ako je drama (npr. našla ga je direktorica financija pred svima 🙂 ili je bloker) vjerojatno će biti na vrhu liste za popravak, inače ide u redovnu proceduru.

Bug je otkriven nakon što je sprint dovršen? Ide u backlog i u redovnu proceduru prema nekom SLA (service level agreement) kojeg već imate.

Važnije je što radimo nakon “incidenta”

Svi repovi nakon sprinta su ustvari poziv na razgovor i analizu problema, vjerojatno već tokom sljedeće retrospektive. Pitajte se zašto se dogodilo pa da sprint nije dovršen i ideje za rješenje ugradite već u sljedeće planiranje. Kao tim želite biti predvidljivi (ma kako to dosadno zvučalo) tako da i vi sami, ali i okruženje oko vas može računati na termine isporuka.

Dobro i precizno planiranje je i pokazatelj zrelosti tima.

Što nije pametno raditi

Nepametna ideja #1: US (ili razlika) automatski ide u sljedeći sprint

Iako će US vjerojatno na kraju i dospijeti u sljedeći sprint, podrazumijevati da će tako biti je greška.

S druge strane, ako je ostalo “još samo malo”, možda vrijedi dovršiti US i skinuti ga s vrata jednom i zauvijek. Neka PO odluči 🙂

Nepametna ideja #2: Produživanje sprinta

Ovo je ustvari glupa ideja. Produživanjem sprinta poništavate metrike o kapacitetu tima, brzini rada ili broju US-a koje tim može isporučiti tokom sprinta, a time kvarite i svoju predvidljivost isporuka.