Gör insatsuppskattningar du faktiskt kan lita på – genom att eliminera förankringsbias

Då kan du uppskatta velocity bättre, vilket innebär att du kan göra bättre prognoser och i slutändan få ett högre förtroende i organisationen.

Om du kan uppskatta arbetsinsats och velocity väl kan teamen också fylla Scrum-sprintar med rätt mängd arbete. Det är viktigt eftersom det minskar stress och sprint spillover (när arbetet inte slutförs i tid inom en sprint).

Om du har mycket sprint spillover kan en orsak vara att teamet har börjat arbeta med stories som är för stora. En vanlig grundorsak till att man påbörjar för stora stories är att teamet låter anchoring bias påverka uppskattningen av arbetsinsatsen.

Vad är anchoring bias?

Anchoring bias uppstår när vi ser eller hör en siffra och sedan ska göra en uppskattning efter att ha hört siffran.

En Product Owner frågar till exempel teamet: ”Den här storyn är ganska liten, jag tror att den bara är tre story points. Vad tycker ni?”

Detta förankrar redan de uppskattningar som teamet är på väg att göra.

På samma sätt kan en expert i teamet säga: ”Jag tror att den här storyn är fem story points.”

Att bara höra eller se denna uppskattning innan du gör din egen bedömning av storyns storlek påverkar din uppskattning.

Det finns många studier om hur anchoring bias påverkar människor. Precis som med de flesta kognitiva bias är medvetenhet om dem det första steget för att minska deras påverkan.

Men eftersom det är viktigt för utvecklingsteamen att uppskatta arbetsinsatsen korrekt ska jag nu ge dig några effektiva verktyg som du kan använda för att minska anchoring bias påverkan på era uppskattningar. Då sätter vi igång!

Gör din uppskattning före sprintplaneringen

Uppskattning av arbetsinsats bör göras i någon av följande situationer:

1. sprintplanering

2. backlog refinement

3. ett separat tillfälle för uppskattning av arbetsinsats

Jag rekommenderar inte att lämna uppskattningen av arbetsinsats till sprintplaneringen, eftersom ni då inte har tid att dela upp stories om det behövs. Det är mycket bättre att uppskatta arbetsinsatsen under backlog refinement. Läs gärna mina tidigare blogginlägg om refinement-tekniker (här och här).

Spela planning poker

I planning poker gör varje teammedlem en uppskattning av arbetsinsatsen, och uppskattningarna avslöjas samtidigt. Det är ett bra sätt att motverka anchoring bias för enskilda stories.

Anchoring kan påverka efterföljande stories

Även om du använder planning poker och visar teammedlemmarnas uppskattningar samtidigt kan problemet kvarstå. Uppskattningen för den föregående storyn börjar förankra de efterföljande stories.

Har du märkt att om du först har en story på 8 story points, följs den ofta av fler stories på 8 story points? Teammedlemmarna förankrar sig vid den föregående uppskattningen.

Risken är att när stories uppskattas i följd döljs den viktiga signalen att ”den här storyn är för stor” bakom denna anchoring-effekt.

Minska anchoring när stories uppskattas i följd

Vad kan du göra för att minska anchoring-effektens påverkan?

Uppmärksamma förankringseffekten

Kom överens inom teamet om att alla siffror som anges eller visas påverkar efterföljande uppskattningar. Det är till exempel därför teammedlemmarnas uppskattningar visas samtidigt i planning poker.

Diskutera också i teamet att uppskattningen av föregående story påverkar nästa. På så sätt minskar ni förankringseffekten genom att ge teamet mod och mental frihet att börja om. I praktiken försöker ni få teamet att glömma varje uppskattning efter att den gjorts.

Förfina stories genom att sortera dem från stora och komplexa till små

Om teamet har svårt att korrekt identifiera de stories som är ”för stora” kan ni försöka ordna de stories som ska förfinas i fallande ordning efter antagen storlek och komplexitet.

Då uppskattas de större stories först. Det gör att efterföljande stories förankras på en högre nivå, i stället för att små stories förankrar de stora och komplexa stories.

Observera dock att någon med detta arbetssätt behöver göra ett antagande om stories storlek och komplexitet i förväg.

Förankra om teamet med en story som var för stor

Ett problem med att använda story points är att ni jämför minsta möjliga story, en eller två poäng, med allt annat. Det innebär en risk att arbetet förankras på en för låg nivå.

Det finns ett bra knep för detta:

Använd en exempel-story från tidigare – en som teamet i efterhand insåg var för stor. Det hjälper teamet att förankra om och lättare identifiera liknande stories. Alla team har sådana stories i sin historik, så påminn teamet före uppskattningssessioner om att hålla utkik efter liknande stories.

Större eller mindre

Här är ytterligare något att prova:

Välj en story under uppskattningssessionen och ge den ett värde i story points. Låt oss säga att den får värdet åtta story points.

För att undvika att förankra er vid ett numeriskt värde kan ni sedan börja jämföra varje efterföljande story.

• mycket större (>>)

• större (>)

• mindre (<)

• mycket mindre (<<)

Om ni använder chatt för planning poker kan ni använda tecknen inom parentes för att snabbt ange er egen uppskattning.

Teamet kan sedan diskutera vad ”mycket större” innebär – är det 20 eller ännu mer? Om teamets gemensamma bedömning bara är ”större” kan ni landa på 13. En variation mellan ”större” och ”mindre” kan innebära att storleken sätts till åtta.

Den största uppskattningen vinner

Det här arbetssättet är särskilt användbart i tysta sessioner för att uppskatta arbetsinsats, där diskussion inte är tillåten. Syftet med dessa sessioner är att snabbt få uppskattningar för många poster. I ”störst vinner” eller ”näst störst vinner” bortser ni från många av de små uppskattningarna. Om ni är osäkra ska ni välja den större uppskattningen.

Bra uppskattningar av arbetsinsats ökar förtroendet

Det är viktigt att uppmärksamma förankringseffekten och diskutera den med teamet. Experimentera med olika sätt att undvika förankring, så blir era uppskattningar bättre. Kom ihåg att den främsta nyttan med bra uppskattningar av arbetsinsats är mindre överhäng mellan sprintar och stress, mer träffsäker velocity och bättre prognoser. Det blir också lättare att upptäcka för stora stories och fokusera på att dela upp arbetet.