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.