Att skapa mer struktur i processen för backlog refinement kräver viss planering och ansträngning, men kan ge starka resultat. I den här bloggen presenterar jag en enkel men effektiv process för betydligt bättre förberedelser.
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.
Som jag beskrev i mitt tidigare blogginlägg ägnar de flesta team inte tillräckligt med tid åt backlog refinement. I många fall beror det på internt motstånd i teamet: teamet kan uppleva att backlog refinement är slöseri med tid. De tycker att det är så ineffektivt att definiera arbetsuppgifter innan de påbörjas att det känns enklare att acceptera slöseriet och bara börja arbeta – och på den hårda vägen ta reda på vad som behöver göras.
Vad du kan göra om teamet är ovilligt att förfina backloggen
Du kan hantera motstånd i teamet på några olika sätt:
Fokusera förfiningsarbetet på uppgifter som inte är rutinmässiga
Fundera på om hela teamet behöver delta eller om förfiningen kan göras i en mindre grupp
Organisera förberedelserna för ärendena bättre
Rutinuppgifter har vanligtvis ingen nytta av förfining. För dessa uppgifter finns redan oskrivna ”acceptanskriterier” som teamet känner väl till. Hoppa över dessa ärenden – om inte någon upptäcker att en uppgift som verkar vara rutinmässig i själva verket inte är det.
Jag förespråkar att hela teamet deltar i backlog refinement-sessioner, men det kanske inte är rimligt om teamet är stort. Om ni är fem personer i teamet bör alla delta. Om teamet har tio eller fler medlemmar kan ni överväga att låta endast utvalda deltagare förfina backloggen. Informationsdelning är en viktig fördel med förfining, men den kan också uppnås på andra och mer effektiva sätt.
I det här blogginlägget tittar vi närmare på den tredje punkten i listan – bättre förberedelser.
Ta fram en strukturerad metod för att förbereda backlog refinement
Nedan följer en process för att lägga till mer strukturerade förberedelser i er backlog refinement. Se mitt tidigare blogginlägg om du vill få en bild av hela förfiningsprocessen.
Förberedelser inför sessionen:
Product Owner väljer ut de ärenden som behöver förfinas.
Product Owner hittar en lämplig person i utvecklingsteamet som kan förbereda ärendena ytterligare, ELLER så självorganiserar teamet sig för att hitta den person som är bäst lämpad att ansvara för förberedelserna.
De utvalda teammedlemmarna förbereder ärendena.
Product Owner skickar ett e-postmeddelande till deltagarna i förfiningssessionen och påminner dem om att sätta sig in i de förberedda ärendena före sessionen.
Deltagarna i förfiningen går igenom de förberedda ärendena, antecknar möjliga frågor eller kommentarer och gör en preliminär bedömning av arbetsinsatsen.
Under sessionen:
Utse en sekreterare för förfiningssessionen som för anteckningar.
Product Owner anger vilket ärende som ska hanteras först.
Teamet får möjlighet att kommentera eller ställa frågor om ärendet. Om det inte kommer några kommentarer eller frågor kan ni gå direkt vidare till nästa steg utan ytterligare diskussion.
Teammedlemmarna uppskattar arbetsinsatsen för ärendet med Planning Poker.
Om resultaten från Planning Poker ligger inom en rimlig variation dokumenteras arbetsinsatsen och teamet går vidare till nästa ärende i listan.
Om resultaten från Planning Poker visar stora skillnader i uppskattningarna av arbetsinsatsen diskuterar teamet vilka faktorer som ledde till de olika bedömningarna. Resultatet av diskussionen dokumenteras i ärendet.
Teamet uppskattar uppgiften på nytt tills de kan gå vidare till nästa ärende i listan.
Saker som teamet måste komma överens om
Som du kan se är den här processen mer komplex och utmanande än det enkla tillvägagångssätt som beskrevs i föregående blogg. Men oroa dig inte: processen är inte så svår i praktiken som den kanske låter. Däremot kräver flera steg att man kommer överens, och processen som helhet kräver en viss disciplin.
Saker som teamet behöver komma överens om är bland annat:
Hur kan Product Owner be en teammedlem att förbereda ett ärende?
Hur mycket tid bör läggas på förberedande uppgifter inför refinement?
Hur förhåller sig de förberedande uppgifterna inför refinement till övriga ärenden i det vanliga arbetsflödet (det vill säga överenskommet och åtaget sprintinnehåll)?
Här finns en komplikation: medlemmar i ett Agilt team bör inte tilldelas arbete. De bör själva ta på sig arbetet. Kan teamet alltså tillåta att Product Owner direkt ber en teammedlem att lägga tid på förberedelser inför refinement?
Ett annat alternativ till att PO tilldelar förberedelseuppgiften är att PO ber teamet att fördela den. I så fall måste teamet ha en process för att själv avgöra vilken teammedlem som har den expertis och kapacitet som krävs för förberedelserna. Det är något svårare än att PO direkt ber någon att göra förberedelserna, men ligger bättre i linje med Agile-principerna. Teamet bör testa vilket av de två tillvägagångssätten som fungerar bäst för dem.
Vad gör ni om planerat och tilldelat förberedelsearbete inte blir gjort?
Om förberedelser utan en arbetsuppgift upprepade gånger inte blir gjorda på grund av andra arbetsåtaganden, kan ni skapa "refinement-ärenden" i sprint backlog. Jag gillar egentligen inte det här tillvägagångssättet eftersom det liknar ett "specifikationsvattenfall". Men det är ändå ett giltigt tillvägagångssätt att testa.
Hur mycket tid räcker?
Teamet bör också diskutera och komma överens om förberedelsernas omfattning. Hur mycket tid bör läggas på dem?
Som utgångspunkt räcker ofta omkring 20–30 minuter för att förbereda de flesta ärenden. Det går säkert att hitta 20–30 minuter per ärende även när ni arbetar med de resultat ni har åtagit er i den aktuella sprinten.
Vad innebär förberedelser egentligen?
Personen som gör förberedelserna bör överväga och dokumentera följande:
Vad är backlog-ärendets "varför" – varför bör teamet göra det?
Vilken nytta ärendet ger slutanvändaren, om möjligt.
Beskrivning av backlog-ärendet.
Acceptanskriterier (lista 3–8 acceptanskriterier).
Om backlog-ärendet behöver delas upp i mindre ärenden, en rekommendation för hur det kan göras.
Vad teamet inte bör implementera i det här backlog-ärendet.
Allt handlar om disciplin
Det här sättet att förbereda backlog refinement innehåller ett par extra steg med deadlines, vilket kräver en hel del disciplin från teamet.
Teamet måste genomföra förberedelsearbetet inom några dagar.
De teammedlemmar som deltar i refinement måste läsa igenom och överväga ärendena före refinement-sessionen.
Ett bra förberedelseschema bidrar till den disciplin som behövs
Jag rekommenderar att teamen etablerar en strikt tidsplan som hjälper dem att utveckla och upprätthålla den disciplin som krävs. Till exempel:
Backlog refinement genomförs vid samma tid varje tisdag morgon klockan 10.
De förberedda punkterna ska vara klara för granskning på måndag klockan 12.
Teammedlemmar som deltar i refinement bokar en timme på måndag eftermiddag för att sätta sig in i punkterna.
Product Owner går igenom förberedelsearbetet föregående onsdag.
Product Owner utser rätt teammedlem att förbereda punkten senast vid arbetsdagens slut på onsdagen.
En teammedlem har torsdag, fredag och måndag förmiddag på sig att genomföra förberedelsearbetet, som tar 20–30 minuter.
Enligt min mening är det enda sättet att få en förberedelseprocess att fungera att komma överens om och hålla sådana här deadlines. Att försöka komma överens om något annat ad hoc kommer sannolikt att misslyckas.
Fördelar med ett disciplinerat förberedelsearbete
Utvecklingsteam kan dra nytta av ett disciplinerat förberedelsearbete på många sätt:
Hela teamet kan förlita sig på expertisen hos teammedlemmen som förberedde punkten.
Teammedlemmarna behöver inte komma på allt i punktbeskrivningen eller alla acceptanskriterier.
Teamet kan fokusera sin uppmärksamhet och sina insatser på att granska förberedelsearbetet kritiskt och ställa frågor för att avgöra om något har missats.
När arbetssättet har blivit rutin kan teamet gå igenom punkterna betydligt snabbare och stanna upp när delar av beskrivningen är otydliga. Diskussionen kan hoppa över det vardagliga och fokusera betydligt mer på de delar av arbetet som skapar mest värde.
- Agile
- Product management
Subscribe to our newsletter
Related blogs