Hoe groot moet elk verhaal zijn voor een persoon in een sprint van 3 weken?

TL; DR

Kortom, uw hele set aannames voor planning is niet flexibel. U moet opnieuw bekijken hoe u uw iteraties plant en hoe uw team van plan is het werk te schatten waarvan het denkt dat het kan worden voltooid voor de huidige iteratie. Een meer gedetailleerde analyse volgt.

Gedetailleerde analyse

We weten dat langetermijnplanning (releaseplanning) in verhaalpunten moet zijn. [sic]

Nee. Agile releaseplanning wordt gedaan in iteraties . Daarom zal een Scrum-projectplan een geschatte reeks iteraties schatten die nodig zijn om het minimaal haalbare product te bereiken of de initiële Product Backlog te voltooien. Dit is alleen een schatting, aangezien de inhoud van de achterstand in de loop van de tijd zal veranderen, en de lengte en nauwkeurigheid van schattingen ook samen met de Kegel van onzekerheid .

Maar voor sprintplanning moet het gebaseerd zijn op commitment.

Nogmaals, nee. Sprintplanning is op capaciteit gebaseerd . Het enige punt van tracking (of het maken van een eerste schatting van) de gemiddelde snelheid van het team is het vinden van de duurzame capaciteit van het team om in de loop van de tijd te werken. Hoewel het team er zeker van moet zijn dat het zich nooit te veel inzet om in een Sprint te werken alleen omdat het snelheidsbereik of het gemiddelde zegt dat er beschikbare capaciteit moet zijn, is het de verantwoordelijkheid van het team om de huidige iteratie te plannen door de teamsamenstelling en beschikbaarheid te nemen. , en andere factoren die van invloed zijn op de huidige Sprint .

Zeggen dat Sprints “commitment-based” zijn, wordt waarschijnlijk gebruikt als een emotionele knuppel om teams ertoe te brengen zich te committeren aan meer werk dan zou moeten, want natuurlijk zouden teamleden “toegewijd” moeten zijn. Maar dat “is een misbruik; in de echte wereld zou de teamcapaciteit over het algemeen moeten worden verminderd, maar zelden opgeblazen tijdens de planning. Als het team zich onvoldoende heeft gecommitteerd, kan indien nodig extra werk van de Product Backlog worden afgepeld, maar het trimmen is bijna altijd politiek beladen en brengt vaak het Sprintdoel in gevaar. Dus doe dat niet.

Capaciteit kan een relatief objectieve maatstaf zijn. Aan de andere kant kan toewijding (net als patriottisme) niet worden gemeten, tenzij je opnieuw mensen vragen “het ultieme offer te brengen”, wat min of meer in tegenspraak is met het hele uitgangspunt van flexibele duurzaamheid. Leg nooit vast aan een dodenmars .

Voor een sprint van drie weken, hoe groot moet elk verhaal voor een persoon zijn?

Dit verdient een heel boek gevuld met nee. Verhalen worden nooit op maat gemaakt voor, of geaccepteerd door, een individu. Alle verhalen worden geschat op basis van de volledige, gecoördineerde bronnen van een multifunctioneel team dat samenwerkt om elk verhaal te voltooien. De verhalen worden geaccepteerd of afgewezen op basis van:

1. Ze zijn essentieel voor het huidige Sprintdoel.
2. Ze passen binnen de geschatte capaciteit beschikbaar voor de huidige Sprint.

Een enkel Product Backlog-item kan overal zijn re van 0 verhaalpunten tot het maximum dat beschikbaar is voor de hele Sprint. Een goed verhaal dat echter voldoet aan de INVEST-criteria , bestaat over het algemeen uit Sprint Backlog-taken van ongeveer 0,5 dagen tot 2,0 dagen lang. Onthoud dat hoe kleiner de taak of het verhaal, hoe nauwkeuriger de schatting meestal is, dus een tiental 5-puntsverhalen (indien nauwkeurig geschat) zijn over het algemeen betrouwbaarder dan een enkel 60-puntenverhaal. De volwassenheid en schattingsnauwkeurigheid van uw team kunnen echter zeker variëren.

Gebruikersverhalen zijn niet per teamlid

Meerdere teamleden zouden aan dezelfde gebruiker moeten werken verhaal tegelijkertijd. Dit is geen vereiste maar een aanbeveling. De essentie van de rugbyterminologie, scrum , waarbij het team als een eenheid naar de doellijn gaat. Het concept heet zwermen . Iedereen concentreert zich op een bepaald moment op één (of minder) taken, maakt deze af en pakt het volgende werkstuk aan (herhalen). Voordelen:

• Het houdt_in voortgang_ items minder.
• Het maakt het mogelijk om sprint backlog-items te voltooien die verspreid zijn over de sprint, in plaats van dat alles vlak voor het einde van de sprint wordt voltooid.
• Houdt de belasting van qa / testen gelijkmatig verdeeld over de sprintduur.
• Het hele team krijgt de codekennis en kan technische suggesties geven.

Het team moet kies een verhaal en verdeel het in technische taken. Er mag maar één persoon aan één technische taak werken, omdat de verantwoordelijkheid in dit geval duidelijk is, wat helpt tijdens dagelijkse scrum-vergaderingen. Idealiter zou één technische taak klein genoeg moeten zijn om gedurende een dag te worden voltooid.

Omvang van gebruikersverhalen

Scrum definieert er geen aanbevolen grootte van een gebruikersverhaal. Een verhaal moet echter zo groot zijn dat het tijdens één sprint kan worden voltooid. “Voltooiing” betekent dat het uw “Definition of Done” omvat.

Een verhaal moet duidelijk worden begrepen en expliciete acceptatiecriteria hebben, die tijdens dezelfde sprint worden geverifieerd. Normaal gesproken is het moeilijker om een groot verhaal glad te strijken en alle acceptatiecriteria te omschrijven, dus een verhaal moet klein zijn waar het goed genoeg kan worden ingeschat en getest.

Een verhaal moet ook groot genoeg zijn, zodat het levert een concrete zakelijke waarde aan de stakeholders.

Het antwoord is dus niet te klein en niet te groot . Met oefening en ervaring word je beter in het schrijven en splitsen van user stories. Het is meer een kunst dan wetenschap.

Sprintplanning zou ook in verhaalpunten moeten zijn. Het proces is hetzelfde als voor de langetermijnplanning. Je controleert je snelheid en capaciteit (hoeveel van de teamleden zullen er zijn, vanwege vakantie enz.) en komen naar boven met een getal.

Als je van plan bent voor sprint 2, controleer je je snelheid in sprint 1 – bijvoorbeeld 10 punten – en zet je 10 punten aan gebruikersverhalen in je iteratie-backlog.

Als je van plan bent voor sprint 3, controleer je je snelheidstrend van sprint 1 naar 2 en zoek je het bedrag waaraan je je kunt committeren.

Als je van plan bent voor sprint 1, voeg je zoveel als jij vindt het goed.

Probeer niet te zien hoeveel punten iemand kan halen , want scrum is over teams, niet over personen. Een junior kan bijvoorbeeld minder doen dan een senior, maar als mensen elkaar helpen, kunnen ze niet zoveel leveren als op papier . Werk en reken met teams , omdat het logischer is (en gemakkelijker).

Reacties

• Ja, Ik ga akkoord, het totale aantal storypunten van eerdere sprints waarnaar moet worden verwezen en zoals jij / CodeGnome zei, moet ook rekening worden gehouden met de capaciteit. Eigenlijk ben ik in de war dat hoe kort moet zijn ” elk ” verhaal zodat het parallel kan worden getest omdat er geen afzonderlijke testfase is.
• Ik heb ook eerder verwezen naar: mountaingoatsoftware.com/blog/…
• @Roop, zoals anderen al zeiden, ” elk ” verhaal hoeft niet kort genoeg te zijn. Het zal door meerdere teamleden worden uitgewerkt, maar taken binnen het verhaal zouden 0,5 dagen tot 2 dagen bewaard