Ik weet dat gebruikersverhalen in Scrum worden gemeten met een Modified Fibonacci-reeks (0.5, 1, 2, 3, 5, 8, 13, 20, 40...). Waarom gebruikt Scrum alleen Fibonacci-getallen om verhalen te schatten?
Opmerkingen
- Al beantwoord op een andere site: stackoverflow.com/questions/9362286/…
- Mensen, ik denk niet dat ' deze vraag een exact duplicaat is. Hoewel de vragen nauw verwant zijn, denk ik dat het OP voor deze vraag vraagt waarom men ' geen andere metingen kan gebruiken voor het schatten van verhaalpunten, terwijl Waarom zouden teams de Fibonnacci-reeks gebruiken voor verhaalpunten? vraagt naar de voor- en nadelen van Fibonacci-getallen als metriek. Ik ' heb geprobeerd de vraag te verduidelijken en stem voor heropening.
- +1 voor het OP voor het aan de orde stellen van wat naar mijn mening een veelvoorkomende fout is -perceptie.
Antwoord
Geen Fibonacci vereist
Hoewel veel agile beoefenaars hebben omarmd een aangepaste of ongewijzigde Fibonacci-reeks voor het schatten van verhaalpunten, noch verhaallijnen noch gebruikersverhalen zijn eigenlijk vereisten van de Scrum-methodologie.
Zelfs als je de praktijk van schatten met verhaal omarmt -punten en gebruikersverhalen, kunt u elk gewenst hulpmiddel voor relatieve grootte gebruiken. Enkele voorbeelden die ik in het veld heb gezien, zijn:
- T-shirtmaten (bijv. S, M, L, XL)
- Verkeerslichten (groen, geel, rood )
- Starbucks-drankformaten ( demi , kort, groot, groot , venti , trenta )
- Eenvoudige reeksen zoals 1-5 of 1-10.
Als u besluit om verhaalpunten te gebruiken, is de sleutel om de punten los te koppelen van tijdschattingen. Dit helpt om verankering te voorkomen en voorkomt hopelijk dat schattingen onjuist worden gebruikt als productiviteit -managementstatistiek in plaats van een planning- of prognosetool.
Voel je vrij om elke schaal te gebruiken die voor je team werkt. Ik “zou echter zeker aanraden om bij Mike Cohns Planning van de Poker Fibonacci-reeks tenzij je een goede reden hebt om het anders te doen.
Reacties
- Uitstekend antwoord @CodeGnome!
- Ja, we gebruiken het pokersysteem en het werkt goed, aangezien al l de teamleden voegen input toe op basis van hun werkcomplexiteit & size, en komen tot de uiteindelijke conclusie wat de uiteindelijke verhaalgrootte zou moeten zijn.
- Ik wilde altijd gebruik volledig abstracte maten, zoals " S, M, L ". Maar ik doe dat hoe zou ik de gemiddelde snelheid meten? Hoe weet ik wanneer het project mogelijk klaar is? Als ik getallen gebruik die ik gemakkelijk kan berekenen – de gemiddelde snelheid is, laten we zeggen, 15 – in dat geval, als er 60 punten in de projectachterstand over zijn, zou ik weten dat het project in minder dan 4 iteraties zou moeten worden voltooid. Kun je hetzelfde doen met relatieve sizings van abstact?
Answer
Een van de belangrijkste redenen is om geen debatten / schattingen als: 19,20, 21, 23 Story Points.
Bij agile schatten gaat het meestal over het vergelijken van relatieve grootte , het is duidelijk dat 1 Story Point aanzienlijk kleiner dan 10 Story Points, maar 10 SP vs 9 SP verschilt niet veel.
Je wilt zeker weten dat grotere getallen ruw zijn schattingen en u “stuurt niet naar uw belanghebbenden dat u precies weet hoe groot het item is.
Tussen haakjes: daarom heb je 20 in plaats van 21 wat een geldig Fibonnaci-volgnummer is.
De Fibonacci-reeks geeft ook beter weer dat de onzekerheid proportioneel toeneemt met de grootte van het verhaal . De verschillen tussen verhalen met 1, 2 en 3 punten worden waarschijnlijk beter begrepen dan de verschillen tussen een 20 en een 40. Dit wordt weerspiegeld in de afstand tussen de verhaalgroottes.
Opmerkingen
- De Fibonacci-serie geeft ook beter weer dat de onzekerheid proportioneel toeneemt met de grootte van het verhaal. De verschillen tussen 1,2- en 3-puntsverhalen worden waarschijnlijk beter begrepen door de verschillen tussen een 20 en een 40 . Dit wordt weerspiegeld in de afstand tussen de verhaalgroottes.
- @Willl Ja, natuurlijk, voel je vrij om mijn antwoord te bewerken en bedankt voor de input.