Vi vet at langsiktig planlegging (frigjøringsplanlegging) skal være i historien.
Men for sprintplanlegging, bør det være engasjement basert.
Å dele inn produktets etterslagsvare / brukerhistorie i oppgaver og estimere oppgavene, spør teamet seg selv om de kan forplikte seg til å levere produktets etterslagsvare, og deretter gjenta til de er fulle?
I en tre ukers sprint, hvor stor skal hver historie være for en person?
Dessuten har jeg sett at noen lag gjør unna denne oppgavebaserte planleggingen og har historier som bare er 2 dager lange ?
Skal jeg standardisere dette for teamet mitt?
Så før en sprint, bryter jeg historiene mine til slike noveller at de passer til denne standarden.
Vær så snill, gi meg beskjed om synspunktene dine om dette. Og hva er allmennpraksis?
Kommentarer
- Scrum Guide endret fra » forpliktelse » til » prognose «. Du kan lese om årsaken til den endringen her.
- Denne lenken kan være nyttig pm.stackexchange.com/questions/10119/ …
Svar
TL; DR
I utgangspunktet er hele settet med planleggingsforutsetninger ikke smidige. Du må se på hvordan du planlegger iterasjonene dine, og hvordan teamet ditt planlegger å estimere arbeidet de mener kan fullføres for den gjeldende iterasjonen. En mer detaljert analyse følger.
Detaljert analyse
Vi vet at langsiktig planlegging (utgivelsesplanlegging) skal være i historien. [sic]
Nei. Planlegging av smidig frigjøring gjøres i iterasjoner . Derfor vil en Scrum-prosjektplan estimere et tilnærmet utvalg av iterasjoner som er nødvendig for å nå det minste levedyktige produktet eller fullføre den opprinnelige produktbackloggen. Dette er bare et estimat, ettersom innholdet i etterslepet vil endres over tid, og estimatens lengde og nøyaktighet vil også endres sammen med Usikkerhetsskjegg .
Men for sprintplanlegging, bør det være forpliktelsesbasert.
Igjen, nei. Sprint Planning er kapasitetsbasert . Det eneste punktet for sporing (eller skape et innledende anslag for) teamets gjennomsnittlige hastighet er å finne teamets bærekraftige arbeidsevne over tid. Selv om teamet må være sikker på å aldri forplikte seg til å jobbe i en Sprint bare fordi hastighetsområdet eller gjennomsnittet sier at det skal være ledig kapasitet, er det teamets ansvar å planlegge for gjeldende iterasjon ved å ta lagets sammensetning, tilgjengelighet , og andre faktorer som påvirker den nåværende sprinten i betraktning.
Å si at Sprints er «forpliktelsesbasert» vil sannsynligvis bli brukt som en følelsesmessig slør for å få team til å forplikte seg til mer fungerer enn de burde, for selvfølgelig skal teammedlemmer være «forpliktet.» Det er imidlertid et misbruk; i den virkelige verden bør teamkapasiteten generelt sett reduseres, men sjelden oppblåses under planleggingen. Hvis teamet har underforpliktet seg, kan ekstra arbeid skrelles av Produktet Backlog etter behov, men beskjæringsområdet er nesten alltid politisk belastet og setter ofte Sprint-målet i fare. Så ikke gjør det.
Kapasitet kan være en relativt objektiv beregning. På den annen side kan engasjement (omtrent som patriotisme) ikke måles med mindre du » vi ber folk om å «gjøre det ultimate offeret», som er litt av motetikk mot hele premisset om smidig bærekraft. Forplikt deg aldri til en dødsmarsj .
I en tre ukers sprint, hvor stor skal hver historie være for en person?
Dette fortjener en hel bok fylt med «nei.» Historier blir aldri dimensjonert for, eller akseptert av, et individ. Alle historier er estimert basert på de fulle, koordinerte ressursene til et tverrfunksjonelt team som jobber sammen for å fullføre hver historie. Historiene blir akseptert eller avvist basert på om:
- De er avgjørende for det nåværende Sprint-målet.
- De vil passe innenfor den estimerte kapasiteten tilgjengelig for den gjeldende Sprint.
Et enkelt produktforsinkelseselement kan være når som helst re fra 0 historie poeng opp til maksimum tilgjengelig for hele Sprint. Imidlertid er en god historie som oppfyller INVEST-kriteriene vanligvis sammensatt av Sprint Backlog-oppgaver på rundt 0,5 dager til 2,0 dager i lengde. Husk at jo mindre oppgaven eller historien er, desto mer nøyaktig er estimatet vanligvis, så et dusin 5-punkts historier (når de er nøyaktig estimert) er generelt mer pålitelige enn en enkelt 60-punkts historie. Imidlertid kan lagets modenhet og estimeringsnøyaktighet sikkert variere.
Svar
Brukerhistorier er ikke per teammedlem
Flere teammedlemmer skal jobbe med samme bruker historie samtidig. Dette er ikke et krav, men en anbefaling. Essensen av rugbyterminologien, scrum , der laget går mot mållinjen som en enhet. Konseptet heter svermer . Alle fokuserer på en (eller færre) oppgaver i et gitt øyeblikk, fullfører den og takler neste arbeid (gjenta). Fordeler:
- Det holder_ på gang_ færre elementer.
- Det gjør det mulig å fullføre sprintforsinkelser spredt over hele sprinten, i stedet for at alt blir fullført nær sprintenden.
- Holder qa / testing belastning jevnt fordelt over sprintvarighet.
- Hele teamet får kodekunnskapen og kan gi tekniske forslag.
Teamet bør velg en historie og del den opp i tekniske oppgaver. Bare én person skal jobbe med en teknisk oppgave fordi ansvaret er klart i dette tilfellet, noe som hjelper under daglige scrummøter. Ideelt sett bør en teknisk oppgave være liten nok til at den blir fullført i løpet av en dag.
Størrelse på brukerhistorier
Scrum definerer ingen anbefalt størrelse på en brukerhistorie. Imidlertid bør en historie dimensjoneres slik at den kan fullføres i løpet av en sprint. «Fullføring» betyr at den dekker din «Definisjon av ferdig».
En historie skal være tydelig forstått og ha eksplisitte akseptkriterier som blir bekreftet i løpet av samme sprint. Normalt er det vanskeligere å stryke ut en stor historie og stave ut alle akseptkriteriene, så en historie skal være liten der den kan estimeres godt nok og testes.
En historie skal også være stor nok så den leverer en konkret forretningsverdi til interessentene.
Så svaret er verken for lite eller for stort . Med praksis og erfaring blir du bedre i å skrive og dele brukerhistorier. Det er mer en kunst enn vitenskap.
Svar
Sprintplanlegging bør også være i historien. Prosessen er den samme som for langsiktig planlegging. Du sjekker hastighet og kapasitet (hvor mange av teammedlemmene som vil være der på grunn av høytid osv.) og kommer opp med et tall.
Hvis du planlegger sprint 2, sjekker du hastigheten din i sprint 1 – for eksempel 10 poeng – og legger inn 10 poeng verdt av brukerhistorier i din iterasjonsforsinkelse.
Hvis du planlegger sprint 3, sjekker du hastighetstrenden din fra sprint 1 til 2 og finner beløpet du kan forplikte deg til.
Hvis du planlegger sprint 1, legger du til så mye som du ser det.
Prøv å ikke se hvor mange poeng en person kan gjøre , fordi scrum er om lag ikke personer. For eksempel kan en junior gjøre mindre enn en senior, men folk hjelper hverandre, de vil ikke kunne levere så mye som «på papiret». Arbeid og beregne med team , fordi det gir mer mening (og det er lettere).
Kommentarer
- Ja, Jeg er enig med deg, totale lagringspunkter for tidligere sprinter som skal refereres til, og som du / CodeGnome sa, må også kapasiteten tas i betraktning. Egentlig er jeg forvirret over at hvor kort skal være » hver » historie slik at den kan testes parallelt ettersom det ikke er noen egen testfase.
- Dessuten har jeg tidligere referert følgende: mountaingoatsoftware.com/blog/…
- @Roop, som andre sa, » hver » -historie trenger ikke være kort nok. Den vil bli jobbet av flere teammedlemmer, men oppgaver i historien bør være holdt 0,5 dager til 2 dager