I dagens artikel tar vi upp ämnet uppskattning och story points i Scrum. Att skapa uppskattningar i Scrum hjälper till att förutsäga komplexiteten och den tid som krävs för att slutföra uppgifter. Genom att analysera det förflutna förutspår hela Scrum-teamet tillsammans vad framtiden har att erbjuda.
Därför, ju mer erfaren Scrum-teamet är, desto mer exakta blir deras uppskattningar. Teamet samarbetar också för att fastställa den uppskattade tiden för att slutföra uppgifterna under Sprintplaneringen, med tanke på att det inte är ett slutgiltigt åtagande utan en förutsägelse. Dess noggrannhet beror på många variabler som ständigt genomgår oförutsägbara förändringar och oväntade omständigheter. Lyckligtvis inkluderar Scrum-metodologin tekniker och verktyg för att underlätta en viss grad av säkerhet, och idag kommer vi att diskutera dem i detalj så att du kan förstå och tillämpa dem direkt!
Story Points och uppskattning i Scrum – innehållsförteckning:
Introduktion
Vid varje Sprintplanering presenterar Product Owner nya användarberättelser för teamet. Product Owner väljer dem från produktbackloggen för implementering i nästa Sprint. Sedan uppskattar Scrum-teamets medlemmar gemensamt arbetsbelastningen som krävs för att slutföra denna nya uppsättning uppgifter. Denna typ av uppgift är en uppskattning, kravuppskattning.
Det skulle verka som den enklaste vägen är att definiera den tid som behövs för att slutföra uppgiften i timmar eller dagar. Men praktik och forskning som genomförts sedan 1940-talet visar på annat. Människor är oförmögna att exakt uppskatta den tid som krävs för att slutföra även mycket väl definierade uppgifter. Dessutom beror antalet timmar som behövs för att slutföra en uppgift på vem som utför uppgiften och vad som har – eller inte har – gjorts tidigare. Det är därför Scrum vanligtvis använder enheter som kallas Story Points.
Vikten av Story Points i Scrum
Varje utvecklingsteam tillämpar värdet av en Story Point genom att dra från erfarenhet och storleken på individuella uppgifter, det vill säga, följer principen om empirism. Oftast, under Sprintplaneringen, väljer Scrum Master ett eller flera exempel på slutförda användarberättelser, som fungerar som en referenspunkt för att bestämma värdet av de användarberättelser som ska utvecklas.
Det är därför du inte kan tilldela värden i Story Points utan kontext. Till exempel, om den första uppgiften tilldelas ett värde av 10, kommer efterföljande uppgifter att utvärderas mot den som antingen större eller mindre. På detta sätt, inom ett Scrum-teamprojekt, är alla uppgifter i produktbackloggen relaterade till varandra. Detta innebär att liknande uppgifter som utförs av ett utvecklingsteam kommer att få ett liknande antal poäng.
Story Points är relativa enheter. Detta innebär att:
- Värdet av Story Points relaterar endast till de uppgifter som utförs av ett särskilt Scrum-team. Story Points beskriver hastigheten för slutförandet av uppgifterna för ett team. Med andra ord, en användarberättelse som uppskattas till 10 Story Points av Team A, kan få 50 av Team B. Detta beror på att, som vi nämnde, deras värde relativt beräknas i förhållande till andra uppgifter som utförs av det teamet och deras erfarenhet av liknande uppgifter.
- Värdet av Story Points som slutförts i en Sprint kan inte vara grunden för att jämföra prestationen hos två Scrum-team. För att undvika misstag i hanteringen av Scrum-projekt är det viktigt att komma ihåg att hastigheten för ett utvecklingsteam uttryckt i Story Points som gjorts i en Sprint inte kan användas för att jämföra prestationen hos två team. Detta beror på att de kan utföra samma arbete i parallella Sprints, som ett team uppskattade till 10 och det andra till 50 Story Points.
Det bör också inte glömmas att uppskattningen innehåller många okända element och görs på grundval av ofullständiga data. Av denna anledning kan förutsägelserna från även ett mycket erfaret Scrum-team ibland vara mycket olika från den verkliga insatsen som krävs för att slutföra en användarberättelse.
Relativa uppskattningstekniker
Vilka är de mest effektiva uppskattningsteknikerna i Scrum? Det finns ingen universell metod som fungerar för varje team.
Bland uppskattningsteknikerna inom agila metoder är de vanligaste:
- Planning Poker. Denna mest populära relativa metod tar ett kortspel för att beräkna mängden arbete som krävs för att slutföra en uppgift. Dess detaljerade regler och process kommer vi att ta upp i en separat artikel.
- Team Estimation Game. Denna involverar att tilldela genomförandet av användarberättelser i en given Sprint med lämpliga numeriska värden valda från Fibonacci-sekvensen. Vi har också ägnat en separat artikel åt det.
Scrum, å sin sida, avvisar den klassiska absoluta uppskattningsmetoden från den traditionella projektledningsmetodologin. Sättet att uppskatta uppgifter är genom att på förhand definiera person-månader, varaktighet och kostnad för hela projektet. Detta är en lång process, svår att genomföra, och kräver deltagande av experter som tenderar att fastställa rationalen och uppförandekoden, men vidtar inga åtgärder för dem som inte nödvändigtvis kommer att utföra de uppgifter vars värde de uppskattade. Med andra ord, det är inte bara tråkigt utan också mycket ineffektivt.
Story Points och uppskattning – Sammanfattning
Uppskattning är en mycket viktig färdighet som kännetecknar alla mogna Scrum-team. Att uppskatta den tid och insats som krävs för att slutföra individuella uppgifter har blivit huvudfokus för många relativa uppskattningstekniker som Planning Poker eller Team Estimation Game.
Användarberättelser med Story Points är ännu en effektiv mätmetod som vi har beskrivit, förhoppningsvis ger vi våra läsare några användbara verktyg. Det är dock viktigt att komma ihåg att deras siffror endast relaterar till de specifika uppgifter som utförs av Scrum-teamet. Därför kan antalet Story Points inte bli grunden för att jämföra hastigheten hos olika utvecklingsteam.
Om du gillar vårt innehåll, gå med i vår aktiva community av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektledare är Caroline en expert på att hitta nya metoder för att utforma de bästa arbetsflödena och optimera processer. Hennes organisatoriska färdigheter och förmåga att arbeta under tidspress gör henne till den bästa personen att förvandla komplicerade projekt till verklighet.
Scrum Guide:
- Ordlista över grundläggande termer, roller och begrepp
- Vad är Scrum?
- Scrum-värden
- Hur implementerar man Scrum i ditt företag?
- Scrum-team - vad är det och hur fungerar det?
- Vem är en produktägare?
- De vanligaste misstagen hos en produktägare
- Vem är Scrum Master?
- De vanligaste misstagen av Scrum Master
- Vilka statistik och mätvärden bör Scrum Mastern följa?
- Utvecklingsteam i Scrum
- De vanligaste misstagen hos utvecklare
- Scrumartefakter
- Skalning av Scrum
- Sprint Backlog
- Vad är produktbackloggen?
- Vad är användarberättelser?
- Skapa den bästa användarberättelsen med INVEST
- De vanligaste misstagen i User Stories
- Användarberättelse Acceptanskriterier
- Uppskattning och Story Points i Scrum
- Planeringspoker
- Team Estimation Game
- Definiera inkrement
- Scrum-evenemang
- Vad är en Burndown-diagram?
- Fördelar och nackdelar med burndown-diagrammet
- Kanban-tavlor i Scrum och Scrumban
- Hastighet i Scrum - Utvecklingsteamets hastighet
- Daglig Scrum
- Sprintplanering
- Sprintgranskning
- Vad är en Sprint Retrospektiv?
- Vanliga misstag under en Sprint Retrospektiv
- Produktbacklogg vård
- Hur man skapar och tolkar ett burndown-diagram?