i denne artikel på introduktionsniveau ser vi på mekanikken i en Sprint, og hvordan teammedlemmer forventes at samarbejde for at producere en stigning i frigivelseskvalitet.

den første dag: sprintplanlægning

hele holdet, inklusive produktejeren, mødes den første dag i sprinten og gennemfører en Sprintplanlægningssession. Dette er den allerførste ting, der sker, så snart sprinten begynder.

forberedelse

sprintplanlægning burde være forberedt på. Den vigtigste forberedelse er at sikre, at Produktefterslæb er blevet raffineret til et passende detaljeringsniveau med estimater og acceptkriterier (dette er formålet med Produktefterslæb forfining). Dernæst skulle produktejeren have bestilt arbejdet med Produktefterslæbet og have en generel ide om, hvordan man forhandler et værdifuldt sprintmål med holdet. Mulighederne for at forhandle et mål skulle også have været overvejet under forfining og afspejlet i efterslæbebestilling. Holdet skal også have en ide om deres kapacitet til denne Sprint, det vil sige, hvor meget arbejde de tror, de kan tage på. De kan muligvis bruge deres erfaring med tidligere Sprints til at hjælpe dem med at fastslå størrelsen af dette budget.

Planlæg først den værdi, der skal leveres

hver Sprint skal resultere i en værdifuld forøgelse af afsluttet arbejde, pasform og klar til øjeblikkelig frigivelse. Produktejeren er helt ansvarlig for, hvad “værdi” betyder, og burde have bestilt Produktefterslæbet på en sådan måde, at værdien kan maksimeres af holdet, sprint-by-sprint. Det første, holdet skal gøre, er derfor at planlægge, hvilke varer fra Produktefterslæbet der skal arbejdes med i denne Sprint, så den bedste værdi kan leveres i slutningen af den.

for at gøre dette arbejder teamet sammen med produktejeren for at vælge de mest værdifulde genstande fra Produktefterslæbet, der passer til deres forventede kapacitet til sprinten. Husk, at hvert element på Produktefterslæbet burde have fået et skøn fra teamet, så de vil vide omtrent, hvor meget arbejde der sandsynligvis vil være involveret.

sørg for at blive enige om et sprintmål

dette valg af arbejde skal være sammenhængende og ikke kun en gruppering af ikke-relaterede og forskellige emner. Husk, at en Sprint er en tidsbokset mulighed for at opnå noget væsentligt. For eksempel kan der ved slutningen af sprinten være leveret en sammenhængende funktion, eller en betydelig risiko vil være blevet mindsket. Sprintmålet er et simpelt udtryk for dette formål, for den overordnede betydning af det valgte arbejde og sammenhængen bag udvælgelsen.

et godt sprintmål giver teamet mulighed for at demonstrere fokus og engagement og tillade samarbejde og omplanlægning af arbejdet, så det opfyldes.

næste plan hvordan arbejdet skal udføres

en Sprint Backlog er mere end blot et udvalg af arbejde med et slutmål i tankerne. Det er også en plan for, hvordan dette mål vil blive nået, og hvordan det tilknyttede arbejde vil blive udført. Dette kan gøres ved at identificere og bestille de tekniske opgaver, der sandsynligvis vil blive involveret. Faktisk er Sprint Backlog en plan for at opfylde sprintmålet og en prognose for det arbejde, der skal udføres.

produktejeren behøver ikke at være til stede i denne del af sprintplanlægningen, da det er op til teamet at planlægge denne prognose på et teknisk niveau. Produktejeren skal dog være tilgængelig, selvom det kun er eksternt, for at besvare eventuelle spørgsmål, teamet måtte have, og for at give enhver afklaring, der måtte være nødvendig om omfanget af arbejdet. Hvis der forventes mere end en frigivelse under sprinten, skal dette aftales med PO og redegøres for i Sprint Backlog.

Ved afslutningen af sprintplanlægningen skal et hold være overbevist om, at det har lavet en god prognose for det arbejde, der er nødvendigt for at nå sprintmålet. Det vil have fanget den plan i Sprint Backlog, som holdet helt ejer. Holdet skal være i stand til at begynde at implementere denne plan med det samme og med en klar forståelse – såsom en Sprintnedbrydning – af, hvor meget arbejde der er tilbage på et givet tidspunkt.

hver dag, hver dag

når holdet har planlagt deres Sprint Backlog, kan de begynde at arbejde. Hvis de har planlagt tingene ud som opgaver, de vil samarbejde med hinanden, som et team, for at sikre, at disse opgaver er afsluttet. De vil være i stand til at spore deres fremskridt ved hjælp af deres task board og deres Sprint nedbrydning af resterende arbejde.

hvert teammedlem vil være sikker på at holde Scrum Task Board og Sprint burn up opdateret, så oplysningerne kan påberåbes af andre. En informationsradiator skal altid fortælle sandheden.

Hold en daglig Scrum

hver arbejdsdag, samtidig med at udviklingsholdet mødes og planlægger, hvad de vil gøre for at bringe dem tættere på sprintmålet. Dette møde kaldes Daily Scrum, og det bør aldrig tage mere end 15 minutter.

kun Udviklingsteammedlemmer skal deltage, da arbejdsplanen helt tilhører dem. Det er en tidsbokset mulighed for at omplanlægge Sprint Backlog som et resultat af nye opdagelser og erfaringer under sprinten. Hele holdet skal deltage. Hvert teammedlem skal kunne redegøre for:

• hvad de gjorde i går for at hjælpe holdet med at nå sprintmålet
• hvad de agter at gøre i dag for at hjælpe holdet med at nå sprintmålet
• eventuelle hindringer, der kommer i vejen

Ved udgangen af Daily Scrum, holdet skal have en klar plan for de næste 24 timer og en forståelse af, hvordan de bliver nødt til at samarbejde for at nå det. De bør også have en liste over eventuelle hindringer, der kræver Scrum Master opmærksomhed.

forfine Product Backlog

i Scrum er Product Backlog Refinement ikke en formel begivenhed, men en løbende aktivitet – processen med at tilføje detaljer, rækkefølge og estimater til Product Backlog-emner som brugerhistorier. Det er op til Scrum Teams selv at beslutte, hvor ofte de skal gøre dette, selvom det bestemt er en god ide for dem at opbygge forfining i deres daglige rutine. Forfining bør ikke tage mere end 10% af et holds samlede tid under en Sprint. For de fleste hold kan en halv time om dagen være tilstrækkelig, selvom nogle måske foretrækker at tilbringe en time eller to et par gange om ugen. Det vigtige er at sikre, at Produktefterslæbet raffineres rettidigt, så sprintplanlægning kan ske uden hindring. Hele holdet, inklusive produktejeren, skal deltage.

en raffineringssession begynder typisk med, at produktejeren præsenterer den aktuelle Produktefterslæb for teamet. Efterslæbet kan holdes i en række former, såsom et elektronisk Scrum-kort eller andet samarbejdsværktøj, eller det kan simpelthen være et regneark. En projektor eller delt skærm kan være meget nyttig.

holdet starter øverst i produkt Backlog og arbejder sig nedad og raffinerer hvert element igen. De vil undersøge hver enkelt og diskutere dens omfang og de acceptkriterier, der er nødvendige for dens gennemførelse. Hvert element vil derefter blive estimeret ved hjælp af en teknik som Planlægning Poker. En stor genstand kan opdeles i mindre, der fanger større detaljer. Epics kan nedbrydes til brugerhistorier, for eksempel.

holdet stopper, når sessionens tidsboks løber ud. De genoptager, hvor de slap næste gang, til sidst starter øverst igen, så efterslæbet holdes opdateret.

Samarbejd altid

i agil praksis arbejder teammedlemmer aldrig isoleret – hvis de gjorde det, ville de ikke være et team. Faktisk er teamarbejde så vigtigt, at rollen er udviklingsteam snarere end udvikler.

det betyder, at hvert Udviklingsteammedlem skal samarbejde med sine jævnaldrende hele dagen, da de er fælles ansvarlige for arbejdets fremskridt. Eventuelle problemer eller fejl ejes i fællesskab af holdet såvel som deres succeser. Samarbejde er ikke noget, der er begrænset til begivenheder som Daily Scrum, men gælder for alt, hvad holdet gør gennem hver hele Sprint.

eksempler på samarbejde inkluderer:

• hjælpe jævnaldrende med at fuldføre det igangværende arbejde, før de bringer nyt arbejde fra en efterslæb
• parprogrammering, såsom at tage det på skift for at bruge tastaturet og hjælpe og kontrollere hinandens arbejde
• Peer anmeldelse
• beder om hjælp, og være ivrig efter at give det
• gå til, hvor arbejdet er, og hjælpe, i stedet for at vente på, at arbejdet overføres til dem
• sørg for, at alt arbejde faktisk opfylder definitionen af udført
• kalder en Scrum for at løse problemer, der har brug for holdets øjeblikkelige opmærksomhed
• hæve hindringer for Scrum Master, så de kan håndteres rettidigt
• opdatering af et Scrum Task board og nedgraderingsdiagram, så oplysningerne er opdaterede og kan stole på
• skill and vidensdeling

den sidste dag: gennemgang og retrospektiv

Hold en Sprintanmeldelse

hvis et team har en har samarbejdet effektivt, har de arbejdet sammen for at nå sprint-målet, styre eventuelle risici og justere deres planer efter behov. De vil have vist kontrol gennem hele sprinten gennem en jævn nedbrydning af det resterende arbejde, hvor hvert medlem så det som deres personlige ansvar at hjælpe med at fuldføre det igangværende arbejde. De vil have en værdifuld stigning til at demonstrere for produktejeren og eventuelle inviterede interessenter. En anmeldelse er noget, et hold skal se frem til.

det er også noget, et hold skal forberede sig på. Der skal være tilstrækkelig tid til en demonstration af det udførte arbejde. Opgaver kan planlægges på en Sprint Backlog til dette formål for at sikre, at gennemgangen gør Retfærdighed for det udførte arbejde og den værdi, der nu er tilgængelig. Hvis produktejeren mener, at det ville være en god ide at invitere interessenter, burde disse invitationer være sendt. Gennemgangen er en mulighed for at fejre det arbejde, der er udført, og for at fremvise deres præstationer, så tillid er inspireret, og en fortsat investering i teamet kan være berettiget.

en Sprint gennemgang er også en inspicere-og-tilpasse mulighed. Det er et godt tidspunkt for produktejeren at forklare, hvor godt produktet klarer sig, at få feedback fra første hånd fra alle inviterede parter og at trække lektioner, der kan bruges til at forbedre Produktefterslæbet yderligere. Hvis noget arbejde ikke er afsluttet, af en eller anden grund, vil dette også blive gennemgået og estimeret på Produktefterslæbet for mulig planlægning af fremtidige sprints.

udfør derefter en Sprint retrospektiv

Sprintanmeldelsen kiggede på produktet og den leverede værdi på det arbejde, der er udført, og ærligt og ærligt på ethvert arbejde, der ikke blev udført, uanset årsagen.
Den næste ting at gøre er at gennemføre en Sprint retrospektiv. En retrospektiv overvejer den proces, som holdet følger. Arbejder de så effektivt, som de kan? Det er generelt bedst at holde retrospektivet umiddelbart efter gennemgangen, fordi førstnævnte kan introducere ideer til overvejelse i sidstnævnte.

hele udviklingsholdet, produktejeren og Scrum Master skal alle deltage i retrospektivet, fordi alle er fælles ansvarlige for succesen med holdets arbejde. Det er virkelig vigtigt at have en gratis og åben session, der kommer til hjertet af eventuelle problemer og identificerer handlinger, der hjælper med at løse dem. Et retrospektiv kan begynde med følgende erklæring:

“uanset hvad vi opdager, forstår vi og tror virkelig, at alle gjorde det bedste job, de kunne, i betragtning af hvad de vidste på det tidspunkt, deres færdigheder og evner, de tilgængelige ressourcer og den aktuelle situation.”

i en” Retro ” har alle en lige stemme. En tilgang, som Scrum Master kan lette, er at identificere:

• ting, der gik godt
• ting, der ikke gik så godt
• ideer til forbedring
• Shout-outs for teammedlemmer, der gjorde noget ekstraordinært

etablering af en tidslinje kan hjælpe med at jogge deltagernes minder om vigtige begivenheder under sprinten.