En grundläggande princip för scrumgrupper är att bestämma sig för en prioriterade uppgift vid början av en sprint och att därefter göra den helt klar vid dess slut. Starka agila arbetsgrupper fullgör eller överträffar sina sprintuppgifter och levererar fungerande mjukvara vid slutet av sprinten. De mäter också sin snabbhet och diskuterar processförbättringar vid tillbakablickande möten för att kunna förbättra kvalitet, produktivitet och annat mätbart.

Men att klara sprintåtaganden är ingen enkel sak, och det kan uppkomma många hinder. Till exempel:

Nybildade arbetsgrupper eller grupper med nya medlemmar måste arbeta fram arbetssätt, samarbetsmetoder och färdigheter. Sådana grupper har ofta oförutsägbar snabbhet innan de fått in en rytm i arbetet.

Team som jobbar med ny teknik vet kanske inte hur de ska dela upp användarberättelser och uppskatta dem rätt. Likaså kan team som saknar ingående kunskaper om äldre teknik, om kodbasen eller om bygg- och utplaceringsprocesser också ha problem med sådana bedömningar. Team som jobbar med krävande produktägare och företagskulturer kan känna sig pressade att åta sig mer än de klarar.

Ibland kanske ett lag inte känner sina egna begränsningar. Sådant som helger, sammanträden och personliga angelägenheter kan dra folk bort från arbetet.

Om produktionssystemen är relativt stabila kan agila team vanligtvis bedöma hur stor del av tiden som faller bort från utvecklingsarbetet för att klara incidenter i produktionen. Men bedömningar är bara bedömningar, och i vissa lägen måste agila team sätta av rätt mycket tid för att reda ut produktionsproblem eller undersöka bakomliggande orsaker.

Min erfarenhet av agila team är att de vid varje tidpunkt ofta måste ta itu med några av dessa problem. Även om gruppen har fastställt sina åtaganden och ökat tempot tillkommer nya krav. Men det finns verktyg och principer som gör det enklare att hantera det oförutsedda, risker och yttre händelser som kan stå i vägen för att klara åtagandena.

Detta är fem principer som scrum-team använder för att klara sina sprinter.

1. Förbättra samarbetet i teamet under scrum-möten

Scrum har några standardmöten som är utformade för att hjälpa teamen att se över prioriteringar, göra åtaganden, följa upp pågående arbete, granska resultat och diskutera processförbättringar. Vid varje möte bör teamen ha diskussioner om sina åtaganden.

Vid ett sprintplaneringsmöte går agila arbetsgrupper igenom avsikterna med användarberättelserna och fastställer poäng för användarberättelserna. Agila team bör undvika att binda sig för användarberättelser som de inte förstår och dela upp sammansatta användarberättelser i mindre.

Under stående scrummöten är det en av scrummästarnas huvuduppgifter att ta bort hinder och blockeringar som fördröjer slutförandet av berättelser.

Slutligen bör teamen diskutera framgångar, missar och farthinder under de retrospektiva sprintmötena. Om teamet har missat sitt åtagande och inte slutförde en eller flera berättelser bör de utvärdera det som fick dem att göra åtaganden och de olika besluten under sprinten och fundera på förbättringar för kommande sprintar.

2. Använd spikes för att förutse tekniska risker

Spikes är användarberättelser som utformats för att validera tekniska okända händelser och risker. Om en spike är lyckad ligger dess värde för verksamheten i kunskapen om hur man utformar och levererar användarberättelser som produktägaren föredrar. Eftersom spikes är till för undersökningar och ofta hårt tidsbegränsade kan det hända att de inte får önskat utfall.

Avancerade agila team använder spikes för att undersöka ny teknik, testa nya tekniska implementationer eller för att validera tekniska antaganden som gäller gamla delar av koden. Om de utvecklar kod som har hårda, icke-funktionella acceptanskriterier för prestanda och tillförlitlighet kan ett team ta fram spikes för att realisera och testa design. Agila team kan definiera ett helt koncepttest som en serie spikes, utformade för att öka deras förtrogenhet med teknik och designmönster.

3. Dela upp användarberättelser i mindre och enklare bitar

När de skriver användarberättelser är det enklare för produktägare eller affärsanalytiker att låta dem innehålla allt som behövs för att de ska leverera värde till kunden eller slutanvändarna. Men när agila team granskar dessa berättelser och analyserar hur de ska genomföras inser de ofta att de olika egenskaperna måste behandlas separat för att klara berättelsens kriterier för acceptans.

En del team kommer, när de inser komplexiteten i en användarberättelse, att sätta ett stort antal berättelsepoäng. Men andra scrumteam gör på ett annat sätt. De tar längre berättelser och delar upp dem i mindre delar så snart de mindre berättelserna fortfarande klarar den agila principen att tillföra värde till verksamheten. Detta bidrar till sannolikheten för att de mindre berättelserna slutförs och ger gruppen möjlighet att dela upp jobbet på flera sprintar.

Om teamet inte kan dela upp användarberättelsen bör den lägga ner tid på att fastställa en uppdelning av arbetsuppgifterna. Uppdelningen gör att scrumteamet kan utveckla en samlad förståelse för vad som krävs, hjälper dem att fördela uppgifter och skapar möjlighet att göra delar av jobbet parallellt.

4. Ha sekundära åtaganden hellre än att lova för mycket

Jag har träffat många agila arbetsgrupper som känner sig pressade av produktägarna att åta sig fler och fler användarberättelser för varje sprint. En del team upplever att de måste förhandla om sina sprintåtaganden, medan andra tvingar sig att åta sig fler berättelser på jakt efter ökad snabbhet, att hålla leveransdatum eller ta itu med teknisk skuld.

Det finns ett alternativ. En del agila team åtar sig så många berättelser och berättelsepoäng som de är starkt övertygade om att de klarar. Sedan lämnar de en del berättelser i bakvagnen: de kommer att ta itu med dem bara om de slutför sina åtaganden tidigare än planerat.

Jag har märkt att detta är en lyckad taktik när man jobbar med krävande produktägare. De kan gå ifrån en förhandling med åtminstone en delseger. Och team som strävar efter att höja sin hastighet kan göra sekundära åtaganden utan att riskera att försumma sina mer prioriterade åtaganden.

5. Svärma för att slutföra det mest prioriterade

Vid början av en spring brukar scrumteam gå igenom de berättelser de har åtagit sig, fördela ägandet och delegera uppgifter till gruppmedlemmar. Agila självorganiserande team har effektiva sätt att fördela arbetet. En del formaliserar fördelningen med verktyg som Jira och Azure Devops, andra använder stående scrummöten för att gå igenom dem.

En naturlig och rimlig metod är att söndra och härska. Det innebär att flera berättelser fördelas och påbörjas när sprinten börjar. Det fungerar bra när användarberättelserna har ungefär samma prioritet, är relativt små och inte är särskilt inbördes beroende.

Ett annat arbetssätt för team som jobbar med högt prioriterade och mer komplexa berättelser är ”swarming”. I stället för att dela upp teamet på flera berättelser ”svärmar” teamet för att klara av den högst prioriterade berättelsen först, innan de tar itu med de andra. Svärmning kan höja scrumteams produktivitet och minskar risken för att man inte ska klara de högst prioriterade uppgifterna i sprinten.

Scrumteam bör fundera på en blandning av principer när de planerar, gör åtaganden och fullgör sprinter. Agila team som tillämpar dessa principer kommer först att höja sin förtrogenhet med åtaganden och därefter att bli allt mer framgångsrika i att klara dem. Först efter det kan de satsa på att jobba snabbare i sprinter.

Läs mer: ”Agilt arbetssätt räcker inte för att din organisation ska bli innovativ”

Läs mer: 4 lärdomar att dra från Accentures katastrofprojekt på Hertz