Fortsätt till huvudinnehåll

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd:
"Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?"
En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville så kunde vi skeppa ut produkten med ganska lite efterarbete.

Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant.

Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre.

Jag vill hellre börja med att undersöka om arbetsmötena kan göras mer effektiva, snarare än att hålla dem mer sällan. Många organisationer lider av dåliga arbetsmöten som bara blir slöseri med alla närvarandes tid. Så, börja med att se till att mötena är ett under av effektivitet.

Hur kort ska en sprint vara då? En sprint kan inte vara så kort att utvecklingsteamet inte hinner bygga ett värdefullt eller intressant produktinkrement. Många organisationer klarar helt enkelt inte att få ihop något vettigt på två veckor, eftersom man inte har en utvecklingsprocess som är tillräckligt bra. Om detta är ett problem behöver vi börja redan idag med att lära oss hur man egentligen gör för att utveckla mjukvara i korta iterationer.

Ofta handlar det om att komma upp på banan med saker som vettiga bygg- och testmiljöer, och såklart automatisering av byggen och vissa tester. Inte sällan finns det även tuffare saker att ta itu med, som när våra utvecklare helt enkelt inte är särskilt duktiga på att skriva begriplig och väldesignad kod.

Sammanfattningsvis: en sprint ska vara så kort att man inte hinner känna behovet att ändra riktning under sprintens gång, men så lång att teamet faktiskt hinner göra klart något som är värdefullt.

Jobbar ni i sprintar? Hur långa sprintar har ni just nu? Hur fungerar det för er?

Kommentarer

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…