Skip to content

Hur man Sprintplanerar mha Jira

by Max Wenzin on February 21st, 2012

Jag har använt Jira i många år och jag har arbetat som Produktägare (enl Scrum) i ett antal år. Jag har chefat över flera team, baserade i olika delar av världen. Detta är min guide till hur du kan använda Jira som ett verktyg för Sprintplanering.

När man ska använda ett webbaserat verktyg istället för en whiteboard

  • När du har distribuerade team
  • När du vill kunna arbeta på saker från flera ställen (exempelvis från kontoret och hemifrån)
  • När du behöver dela information med utomstående stekhållare (exempelvis kunder)

Om du lever i en enklare värld, försökt istället använda det enklast möjliga verktyget för din ärendehantering, exempelvis en whiteboard.

Skärmdump av Jira

Före Sprintplaneringen

Det är Produktägarens jobb att hålla önskelistan (backloggen) städad och sorterad. Sakerna längst upp på listan ska vara tillräckligt välspecificerade så att de kan flyttas till en Sprintbacklogg. Detta är ett ständigt pågående arbete och innebär vanligtvis att man måste prata mycket med olika stekhållare.

Före Sprintplaneringen förbereder jag en “hink” i Jira per team. Vanligen använder jag en Jira “version” för varje Sprint och lägger till ett custom-fält (“Sprint Team”) för att hålla reda på vilket team ett specifikt önskemål hör till.

Jag fyller hinken med önskemål som jag finner lämpliga (en svår uppgift som kräver ett eget blogg-inlägg) för varje team tills det finns mer än tillräckligt med önskemål för varje team. Hur vet jag hur mycket som är tillräckligt? Tidigare sprintar. Har jag estimat på alla önskemål? Nej, vanligtvis inte. Kanske på en del.

Detta resulterar i en preliminär Sprintbacklogg. Detta är inte den slutgiltiga Sprintbackloggen, utan bara ett förslag.

Jag jonglerar vanligtvis en del med sorteringen (prioriteringen) för att se till att de viktigaste sakerna ligger i toppen av listan. Om det finns några större eller mer riskabla önskemål så flyttar jag upp dem i listan så att de hanteras tidigt i Sprinten.

Ett par dagar före Sprintplaneringsmötet skickar jag ut länkar till varje teams preliminära backlogg. Vid det här laget är förslaget ganska stabilt, men ändringar kan fortfarande förekomma.

Detta gör att teamet kan:

  1. Läsa igenom önskemålen i förväg (vilket ger snabbare och mindre smärtsamma Sprintplaneringsmöten)
  2. Ge mig återkoppling på “felaktig” prioritering eller olämpligt team-val etc.

Hantering av rester

Några timmar innan Sprintplaneringsmötet sparkar jag ut eventuella ofärdiga önskemål från innevarande sprint och lägger den i den preliminära backloggen för den kommande Sprinten. Om det finns önskemål som inte är aktuella längre så stänger jag dem med “Won’t fix” eller liknande. Önskemål där arbetet redan påbörjats ger jag ofta en högre prioritet för att kostnaden för att slutföra dem har blivit lägre och effekten är därmed större. (“Sluta börja, börja slutföra”) Hela återstoden från den innevarande Sprinten kommer inte nödvändigtvis att hamna högst upp på listan i den kommande Sprinten. Prioriteringar ändras och nya önskemål dyker upp.

Under Sprintplaneringsmötet

Det är Scrum Masterns jobb att bjuda in folk till Sprintplaneringsmötet. Produktägaren är bara där för att klargöra listan av önskemål och svara på frågor. Som produktägare brukar jag försöka ta en bakgrundsposition i dessa möten och låta teamet utföra planeringen så mycket som möjligt.

Eftersom teamen ofta är utspridda över olika delar av världen använder vi vanligtvis Skype för audio och något skärmdelningsprogram för att visa Jira.

Snabb överblick av Sprintsplaneringsprocessen mha Jira:

  • Visa listan av önskemål (den preliminära Sprintbackloggen) i Jira och prata om Sprintens övergripande mål
  • För varje önskemål i listan:
    • Teamet läser önskemålet
    • Teamet diskuterar önskemålet och frågar Produktägaren när saker behöver förklaras ytterligare
    • Teamet estimerar önskemålet mha Planeringspoker eller liknande metod. Estimatet skrivs in i Jira i “Time remaining”-fältet. (eller om estimatet görs i “Story Points” så skrivs det in i något anpassat fält för detta)
  • När teamet känner att de har tillräckligt med önskemål för att fylla Sprinten så avslutas processen. Detta görs vanligen genom att summera ihop “Time Remaining” på alla önskemål i Jira-”hinken” och när summan når det som teamet normalt sätt klarar av (deras velocitet), då vet de att de har tillräckligt. Vänligen notera att det är inte någon bra idé att summera upp “Original Estimate” ifall ni har halvfärdiga önskemål från förra Sprinten.

Efter Sprintplaneringen

Omedelbart efter Sprintplaneringen sparkar jag ut alla önskemål som inte teamet tog på sig. Dessa lägger jag normalt sett i nästa version. Sedan skickar jag en Jira länk till stekhållarna så att de kan se exakt vad den nya Sprintbackloggen innehåller. Eventuellt skickar jag också en lista på önskemål som inte kom med ifall jag vet att de förväntade sig att vissa specifika önskemål skulle komma med.

Vanligen har jag ett antal Jira-filter som jag uppdaterar varje Sprint. Dessa filter syftar till att göra det enkelt för teamet att veta vilka önskemål de ska jobba på.

Här är några exempel på filternamn jag brukar ha:

  • Current Sprint – TODO – Team A
  • Current Sprint – TODO – Team B
  • Current Sprint – TODO – Team C
  • Current Sprint – TO TEST – Team A
  • Current Sprint – TO TEST – Team B
  • Current Sprint – TO TEST – Team C

Du kan förmodligen lista ut vad dessa filter visar…

Avslutande tankar och vidare läsning

Svart-bältad Jira Admin Ninja, bild från Atlassian

Jag hoppas att denna guide har inspirerat dig till hur det skulle kunna fungera med Jira och Sprintplanering. Om du vill läsa mer om Jira generellt, besök Atlassians sida om Jira. Om du är osäker på Scrum-terminologin som används i denna artikel, eller bara vill veta mer om Scrum, kolla in Scrum Alliance. Om du vill ha hjälp med att implementera Jira på din arbetsplats, så håll mig i åtanke. Jag är ju trots allt Svart-bältad Jira Admin Ninja. ;-)

From → Agile, Jira, Scrum

Comments are closed.