En av de vanligaste frågorna jag får på mina Scrumkurser har att göra med planeringsverktyg. Många undrar vilka mjukvaruverktyg som finns att tillgå för den som vill ha hjälp med att hantera sina produkt- och sprintbackloggar.
Mitt grundsvar delar jag med många andra: det är smart att först fråga sig varför det inte räcker med whiteboard och post-its, plus kanske Excel för produktbackloggen. Fler och fler inser att den uppsättningen inte bara räcker långt, utan på många vis är överlägsen alla mjukvaruverktyg. Att sätta upp planen på väggen stöttar synlighet, delaktighet och uppdateringsfrekvens.
Produktbacklogen är kanske ett lite mer “officiellt dokument” än sprintbackloggen, och har längre livstid, så den kan vara bra att ha som ett Exceldokument. Dokumentet kan lätt distribueras, och ska självklart läggas upp så att inte bara produktägaren utan även alla andra som behöver läsa det, till exempel utvecklingsteamen, enkelt kan komma åt det.
Sprintbackloggen är i större utsträckning teamets egna verktyg. Insyn i denna är naturligtvis också önskvärt, men det brukar räcka bra att ha den på väggen så att både teamet och andra lätt kan ta en titt på den. Behöver man distribuera information digitalt kan man börja med att fråga sig om det inte räcker att publicera vilka rader från produktbackloggen som lyfts in i sprinten. Exakt vilka uppgifter teamet genomför för att komma imål är sekundärt. Multi-teamsituationer kan ställa andra krav förstås.
Att börja med ett mjukvaruverktyg för tidigt leder ibland till att man anpassar sitt arbetssätt efter verktyget, istället för att anpassa verktyget efter det arbetssätt man vill ha. Om man först kör några sprintar med whiteboard och lappar lär man sig först processen, och står då på en bättre grund vid eventuellt verktygsinköp. Det finns ju trots allt legitima orsaker till att ha ett digitalt stöd för planeringen även i lättrörliga projekt. Distribuerade team är en vanlig anledning.
Här är de verktyg som jag spontant kan räkna upp ur huvudet, i den ordning jag kom att tänka på dem.
Uppdatering 2011-12-16: Pivotal Tracker
När jag för något år sedan arbetade fram en ny design för Citerus.se tillsammans med Mårten från Upperdog jobbade vi i Pivotal Tracker för att styra arbetet. Det funkade lysande för ändamålet. Vi arbetade med ett kontinuerligt flöde att förändringar, vilket Pivotal passade utmärkt för, även om verktyget gärna ville göra saker som att räkna ut velocity åt en trots att vi inte riktigt brydde oss. Vissa funktioner struntade vi alltså helt enkelt i, och verktyget blev inte surt på oss för det.
Glöm inte det svenska alternativet:
EDP Scrum
http://edpconsult.se/?id=scrum_index
Då har vi två: Hansoft är ett Uppsalaföretag.