Blog

Tysta backlog refinement-möten: ett mer effektivt Agile-möte

AUG 4, 2022

Backlog refinement är en grundläggande del av ett välfungerande Agile-arbete. Men om du är som många andra team lägger ni inte tillräckligt med tid på det. Silent meetings är en ny och effektiv metod som definitivt är värd att testa.

Arto Kiiskinen

Arto is a Leading Product Owner Coach with 20 years of experience in leading R&D activities both in large and small organizations, in many different roles. He is now committed to training and coaching product owners to become better at their work. He is also CSPO, PSPO, PSM, and ISTQB certified.

Låt mig kort gå igenom hur du kan införa dem i din organisation.

Men först:

Backlog refinement är i sig en utmaning

Att förfina din backlog är en vetenskap i sig. Att göra det väl innebär många utmaningar, till exempel:

  • Hur du involverar alla

  • Hur du förbereder dig på bästa sätt

  • Hur du får till produktiva diskussioner och får hela teamet att dela med sig av sina värdefulla insikter under mötet

  • Hur du gör allt detta effektivt, utan att ta för mycket tid från det ”egentliga” arbetet

Distansmöten ökar utmaningarna

Onlinemöten har gjort situationen ännu mer utmanande. Vid onlinemöten är det svårt att kommunicera effektivt. En person pratar, medan de andra (kanske) lyssnar (eller kanske gör något annat). Ofta pratar vissa personer (du vet vilka de är) på alldeles för länge, eftersom de inte får visuella signaler från andra om att det är dags att gå vidare.

Tysta möten – en enkel metod för att lösa dessa utmaningar

Tysta möten har utvecklats för att lösa problemen med traditionella möten. I ett tyst möte fokuserar du mer på att läsa, tänka och kommentera material som har förberetts före mötet.

När allt kommer omkring är läsning:

  • En mycket snabbare form av kommunikation än att prata och lyssna.

  • Mycket mer demokratisk – introverta personer eller personer som inte har språket som modersmål blir inte lika lätt överkörda av utåtriktade personer som tar mycket plats.

Det gör metoden med tysta möten perfekt för backlog refinement. Ingenjörer är vana vid att läsa och kommentera. Och det finns en hel del introverta ingenjörer där ute.

Läs mer om backlog-hantering

Vad tysta backlog refinement-möten är

Låt oss först titta på grunderna i tysta möten. Sedan går vi igenom hur du kan tillämpa dem specifikt på backlog refinement-möten.

Tysta möten består av:

  1. Agenda (mötesmål, vad mötet inte ska uppnå, process och facilitator)

  2. Bordsläsning

  3. Läsning och kommentarer

  4. Facilitatorns sammanfattning, slutsatser eller summering

Tysta möten behöver inte vara helt tysta – snarare 95 % tysta. Deltagarna kan fortfarande prata när det behövs. Men större delen av kommunikationen under mötet sker genom att läsa, kommentera och bidra till det arbetsobjekt ni tar fram.

Bordsläsningen

Tysta möten fungerar bara om det finns en utgångspunkt. Ett traditionellt möte kan börja med att någon håller en PowerPoint-presentation. Tysta möten bör i stället börja med en bordsläsning. Bordsläsningen är en skriftlig berättelse. Manifestet för tysta möten förespråkar en berättelse på 4–6 sidor.

Tillämpa bordsläsning vid tyst backlog refinement

Bordsläsningen för refinement kan vara en user story som har förberetts av Product Owner eller någon annan teammedlem.

Storyn skulle fortfarande innehålla:

  • Titel

  • Beskrivning av storyn

  • Ytterligare information

  • Acceptanskriterier (dessa är viktiga – läs mer om dem här)

Du kan också lägga till en berättelse, men det är inte obligatoriskt. Du kan till och med använda tyst refinement för att analysera epics eller initiativ. När du gör något av detta är det ännu mer relevant att använda en längre skriftlig berättelse.

Processen för tyst backlog refinement

Använd ett verktyg där varje deltagare direkt kan se andras bidrag. Jira är inte särskilt bra för detta. Bättre alternativ är Confluence (i samredigeringsläge), Miro-tavlor eller liknande onlineverktyg för whiteboards.

Du driver dock inte ett kloster, så i vissa delar av diskussionen kan ni behöva prata. Det kan finnas frågor eller kommentarer som är för komplexa att skriva. Men teamet bör verkligen undvika att prata och i stället prioritera att skriva och läsa.

Innan den tysta sessionen bör teamet komma överens om:

  • Vilket verktyg som ska användas.

  • Ett skrivformat för att lägga till förtydliganden, kommentarer och frågor till storyn.

  • Hur ni ska markera: Hur ni uttrycker att ni håller med eller inte håller med om något som skrivs (tummen upp, stjärnor i slutet av raden eller liknande).

  • Hur ni signalerar att teamet är redo att gå vidare till uppskattning av arbetsinsats. Det kan vara en tidsgräns (fem minuter per objekt) eller att facilitatorn ser att inga fler ändringar görs.

  • Hur ni ska uppskatta arbetsinsatsen för ett objekt (t.ex. med ett särskilt verktyg, ett tillägg till Miro-tavlan eller en samtidig omröstning i chatten).

Här är mitt förslag på notation:

  • Förstår inte – frågetecken: ”?”

  • Gilla, instämmer helt – stjärna: “*”

  • Instämmer inte alls – utropstecken: “!”

Så håller du ett tyst backlog refinement-möte

Före mötet

  1. Product Owner samlar stories som ska förfinas i det verktyg ni använder

  2. Stories förbereds i förväg av någon (table read) (se här varför det är så viktigt)

Under mötet

  1. Under ledning av facilitatorn läser teamet, en story i taget, igenom beskrivningen tyst

  2. Teamet redigerar, kommenterar, ställer frågor, håller med och säger emot i det aktuella ämnet

  3. Facilitatorn märker att redigeringen saktar ner (eller att en överenskommen tidsgräns nås)

  4. Teamet uppskattar arbetsinsatsen, till exempel genom att spela planning poker

  5. Ni går vidare till nästa punkt på agendan

Kort sagt: Därför är metoden med tysta möten perfekt för backlog refinement

Den här typen av backlog refinement går inte bara betydligt snabbare och är mer effektiv:

  • Den tvingar teamet att förbereda backlog items inför refinement (för att kunna genomföra table read).

  • Den dokumenterar automatiskt refinement-diskussionen i ärendet.

  • Det är ett betydligt mer demokratiskt sätt att diskutera, där mindre högljudda och juniora teammedlemmar kan uttrycka sina åsikter friare.

Jag säger inte att den här metoden passar alla och varje team. Men testa den, experimentera med den eller delar av den och se själv.

  • Agil utveckling
  • Produktledning

Subscribe to our newsletter