Jeg vet at brukerhistorier i Scrum måles med en modifisert Fibonacci-sekvens (0.5, 1, 2, 3, 5, 8, 13, 20, 40...). Hvorfor bruker Scrum bare Fibonacci-tall for å estimere historier?
Kommentarer
- Har allerede svart på et annet nettsted: stackoverflow.com/questions/9362286/…
- Folk, jeg tror ikke ' t dette spørsmålet er et nøyaktig duplikat. Mens spørsmålene er nært beslektede, tror jeg OP for dette spørsmålet er å spørre hvorfor man kan ' t bruke andre tiltak for å estimere historiepoeng, mens Hvorfor skulle lag bruke Fibonnacci-sekvensen for historiepoeng? spør om fordeler og ulemper ved Fibonacci-tall som en beregning. Jeg ' har prøvd å avklare spørsmålet og stemmer for å gjenåpne.
- +1 for OP for å heve det jeg mener er en vanlig mis -oppfatning.
Svar
Ingen Fibonacci påkrevd
Mens mange smidige utøvere har omfavnet en modifisert eller umodifisert Fibonacci-sekvens for estimering av historiepunkter, verken historiepunkter eller brukerhistorier er faktisk krav til Scrum-metoden.
Selv om du omfavner praksisen med å estimere med historien -poeng og brukerhistorier, kan du bruke hvilket som helst verktøy for relativ størrelse. Noen eksempler jeg har sett i felten inkluderer:
- T-skjortestørrelser (f.eks. S, M, L, XL)
- Trafikklys (grønt, gult, rødt )
- Starbucks drikkestørrelser ( demi , kort, høy, grande , venti , trenta )
- Enkle sekvenser som 1-5 eller 1-10.
Hvis du bestemmer deg for å bruke historiepoeng, nøkkelen er å fortøye poengene fra tidsestimater. Dette bidrar til å unngå forankring , og forhindrer forhåpentligvis estimater fra å bli brukt feil som produktivitet -administrasjonsberegning snarere enn et planleggings- eller prognoseverktøy.
Bruk gjerne hvilken skala som helst som fungerer for teamet ditt. Imidlertid vil jeg absolutt anbefale å holde deg til Mike Cohn «s Planlegger Poker Fibonacci-sekvens med mindre du har en sterk grunn til å gjøre noe annet.
Kommentarer
- Utmerket svar @CodeGnome!
- Ja, vi bruker pokersystemet og det fungerer bra. siden al l medlemmene av teamet legger til innspill i henhold til deres arbeidskompleksitet & størrelse, og når til endelig konklusjon hva som skal være den endelige historiestørrelsen.
- Jeg har alltid ønsket å bruk totalt abstrakte tiltak, som " S, M, L ". Men jeg gjør det, hvordan skal jeg måle gjennomsnittshastigheten? Hvordan vet jeg når prosjektet muligens vil være ferdig? Hvis jeg bruker tall kan jeg enkelt beregne – gjennomsnittshastigheten er, kan vi si, 15 – i så fall hvis det er 60 poeng i prosjektforsinkelsen igjen, ville jeg vite at prosjektet skulle være ferdig i morløse 4 iterasjoner. Kan du gjøre det samme ved å bruke relative relative størrelser?
Svar
En hovedårsak er at du ikke har debatter / estimater som: 19,20, 21, 23 Story Points.
I smidig estimering handler det vanligvis om å sammenligne relativ størrelse , det er klart at 1 Story Point er betydelig mindre enn 10 Story Points, men 10 SP vs 9 SP er ikke mye annerledes.
Du vil forsikre deg om at større tall er grove anslår, og du sender ikke meldingen til interessentene dine om at du vet nøyaktig hvor stort element er.
BTW: Det er grunnen til at du har 20 i stedet for 21 som er gyldig Fibonnaci-sekvensnummer.
Fibonacci-serien representerer også bedre det faktum at usikkerheten vokser proporsjonalt med størrelsen på historien Forskjellene mellom 1, 2 og 3-punktshistorier er sannsynligvis bedre forstått enn forskjellene mellom 20 og 40. Dette gjenspeiles i avstanden mellom historiestørrelser.
Kommentarer
- Fibonacci-serien representerer også bedre det faktum at usikkerhet vokser proporsjonalt med størrelsen på historien. Forskjellene mellom 1,2 og 3-punkts historier er sannsynligvis bedre forstått forskjellene mellom en 20 og en 40 . Dette gjenspeiles i avstanden mellom historiestørrelser.
- @Willl Ja, selvfølgelig, rediger gjerne svaret mitt og takk fra innspill.