Fortsätt till huvudinnehåll

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fullo och att dokumentet den ligger i inte är åtkomligt eller redigerbart.

Jag känner inte till något billigare, enklare och effektivare sätt att hantera sprintbackloggen än att sätta upp den på väggen. En whiteboard är bra, men inte alls nödvändigt. Jag har själv kört med en radda upptejpade stora blädderblocksark, och det fungerar nästan lika bra. Rekommenderas för övrigt även om man har en whiteboard - då kan man ju använda whiteboarden till att modellera och problemlösa.

När sprintbackloggen, komplett med utvalda saker från produktbackloggen, aktiviteter, status på aktiviteter och timmar kvar, sprintmål och klarkurva (burndown) sitter på väggen händer flera saker. Först och främst är planen nu synlig för alla som vill se den. Helst sitter den förstås i teamets eget arbetsrum.

Med planen ständigt synlig, och givet att teamet accepterat ansvaret för den, blir det enkelt och naturligt att hålla den uppdaterad. Allt som behövs är en snabb justering av återstående tid på en aktivitet, kanske en lappflytt och en uppdatering av klarkurvan. Några minuter per dag och person. Kostnadseffektivt med andra ord.

Att lagra sprintbackloggen elektroniskt ser jag inte som särskilt intressant. Det som är intressant är vilka saker från produktbackloggen som valts ut för sprinten, och vilka som blivit klara enligt vårt klarkriterium. Den exakta aktivitetsföljden inuti sprinten är teamets jobb. Om vi vill granska om teamet jobbar så effektivt som möjligt kan vi titta på hur mycket faktiska resultat som åstadkoms, kvalitetsnivån och på dokumentationen från sprintåterblickarna.

Produktbackloggen ser jag som mer naturlig att ha i elektroniskt format. Den är ett officiellt dokument som ska vara brett tillgängligt i organisationen, för att sprida förståelse för vad som händer med produkten. Man kan vilja versionshantera den, och definitivt skicka ut den, eller en länk till den, till personer som behöver titta på den.

Det finns en uppsjö av verktyg för hantering av både sprint- och produktbackloggen idag. Mitt tips är att skippa sprintbacklogghanteringen i dem om du inte måste köra även sprintbackloggen elektroniskt (t.ex. om ditt team inte går att samlokalisera, vilket ju är vanligt), och fokusera på hantering av produktbackloggen. Även där är det emellertid värt att komma ihåg en vanlig fallgrop: att man blir kidnappad av verktyget.

Jag har jobbat med flera organisationer som beskrivit sitt verktyg ungefär så här: "Det är bra och så, men det funkar ju inte riktigt som vi vill. T.ex. kan vi inte [fyll i med bra förbättring de skulle vilja göra], men eftersom det inte går gör vi som verktyget föreskriver". Inte så kostnadseffektivt, men lätt hänt. De mer avancerade verktygen stödjer förstås långtgående anpassningar, men kostnaden för den typen av produktanpassning är inte riktigt samma sak som att stuva om i ett Excelark - ett verktyg som ofta bespottas men som är märkligt kraftfullt och dynamiskt.

Mitt tips när det gäller verktyg är därför: börja så enkelt som möjligt (Excel, t.ex.) och jobba så tills antingen a) du inser att det faktiskt räcker, eller b) du har förstått typ av stöd ni behöver så att ni kan fatta kloka beslut om verktygsval och anpassning.

Kommentarer

Utmärkt artikel. Håller med till 100%. När jag ledde min första scrumintroduktion 2007 började vi med att använda ett elektroniskt verktyg, och hamnade i exakt den situationen du beskriver; vi blev kidnappade av verktyget. Efter ett par månaders tröghet insåg vi att verktyg hindrade oss från att förstå Scrum, så vi slängde ut det och gick över till whiteboards och lappar. Jag kör fortfarande stenhårt på det.

Jag har ett Excel-verktyg för backloggen som fixar sortering och de viktigaste fälten, samt låter användaren skriva ut indexkort med ett macro. Det är ett vidarebygge på Knibergs index card generator. Min backlog-excel finns att ladda ner på min blog om någon är intresserad :-) http://scrumftw.blogspot.com

Tack för en grymt bra blog som jag självklart följer noga.
Tobias Fors sa…
Hej Richard! Tack för tipsen och det snälla omdömet! /Tobbe
Unknown sa…
Vi skulle vilja ha magnetiska lappar som går att skriva på med whiteboard-penna, och sen sudda och återanvända. Känner du till om det finns sådana att köpa?
Tobias Fors sa…
Hej, låter som en kool produkt. Inget som jag kan nämna en leverantör på direkt, dock har jag ett vagt minne av att ha sett något likande någonstans. Ska fråga på Twitter och se om någon vet.
Anonym sa…
Menar du såna här:

http://www.rahmqvist.se/avico/white_board_fix_film.aspx

Jag har inte provat dom själv, men pratat med andra som har använt liknande produkter. Fördelen är att man kan i princip "tapetsera" sitt team-rum med dessa ark. Ett team satte till och med dessa ark i taket!

Man kan aldrig ha för mycket whiteboards.
Tobias Fors sa…
Tjena Henrik,

tack för tipset. Hittade såna nyligen på Svanströms här i Uppsala, och de är grymt bra. Dock tror jag inte de är suddningsbara, och de är rätt stora. Jag tror "twootwee" är ute efter någon sorts skrivkortsstora magnetlappar.

/Tobbe
Unknown sa…
Precis vad jag (twootwee) menade.. Gillar egentligen post-it i olika storlekar och färger på whiteboarden, men dom lossnar hela tiden, och så går det ju åt en hel del...

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

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.

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 k