Vi ved, at langsigtet planlægning (frigivelsesplanlægning) skal være i historien.

Men for sprintplanlægning skal det være engagement baseret.

At opdele produktets backlog-emne / brugerhistorie i opgaver og estimere opgaverne, hvor team spørger sig selv, om de kan forpligte sig til at levere produkt-backlog-elementet, og derefter gentage, indtil de er fulde?

I en tre ugers sprint, hvor stor skal hver historie være for en person?

Jeg har også set, at nogle hold afskaffer denne opgavebaserede planlægning og har historier, der kun er 2 dage lange ?

Skal jeg standardisere dette for mit team?

Så inden en sprint bryder jeg mine historier til sådanne noveller, at de passer til denne standard.

Please, lad mig vide dine synspunkter om dette. Og hvad er den almindelige praksis?

Kommentarer

Svar

TL; DR

Dybest set er hele dit sæt planlægningsantagelser ikke-adræt. Du er nødt til at gennemgå, hvordan du planlægger dine iterationer, og hvordan dit team planlægger at estimere det arbejde, som det mener kan være afsluttet for den aktuelle iteration. En mere detaljeret analyse følger.

Detaljeret analyse

Vi ved, at langsigtet planlægning (frigivelsesplanlægning) skal være i historien. [sic]

Nej. Planlægning af agil frigivelse udføres i iterationer . En Scrum-projektplan estimerer derfor et omtrentligt interval af iterationer, der er nødvendige for at nå det mindst mulige levedygtige produkt eller udfylde den indledende produktbacklog. Dette er kun et estimat, da efterslæbets indhold vil ændre sig over tid, og estimaternes længde og nøjagtighed vil også ændre sig sammen med Usikkerhedskegle .

Men for sprintplanlægning skal det være forpligtelsesbaseret.

Igen er nej. Sprint Planning er kapacitetsbaseret . Det eneste sporingspunkt (eller skabe et indledende skøn for) holdets gennemsnitlige hastighed er at finde holdets bæredygtige kapacitet til at arbejde over tid. Mens holdet skal være sikker på aldrig at overforpligte sig til at arbejde i en Sprint, bare fordi hastighedsområdet eller gennemsnittet siger, at der skal være ledig kapacitet, er det holdets ansvar at planlægge den aktuelle iteration ved at tage teamets sammensætning, tilgængelighed , og andre faktorer der påvirker den nuværende Sprint i betragtning.

At sige, at Sprints er “forpligtelsesbaseret”, vil sandsynligvis blive brugt som en følelsesmæssig bludgeon for at få hold til at forpligte sig til mere arbejde, end de burde, fordi teammedlemmer naturligvis burde være “engagerede.” Dette er imidlertid et misbrug; i den virkelige verden bør holdkapaciteten generelt reduceres, men sjældent oppustes under planlægningen. Hvis holdet har underforpligtet sig, kan yderligere arbejde skrælles ud af Product Backlog efter behov, men beskæringsområdet er næsten altid politisk fyldt og sætter ofte Sprint-målet i fare. Så gør det ikke.

Kapacitet kan være en relativt objektiv måling. På den anden side kan engagement (ligesom patriotisme) ikke måles medmindre du ” beder folk om at “bringe det ultimative offer”, hvilket er en slags antitetisk over for hele forudsætningen om agil bæredygtighed. Forpligt dig aldrig til en dødsmarsch .

I en tre ugers sprint, hvor stor skal hver historie være for en person?

Dette fortjener en hel bog fyldt med “nej.” Historier bliver aldrig dimensioneret til eller accepteret af en person. Alle historier estimeres ud fra de fulde, koordinerede ressourcer fra et tværfunktionelt team, der arbejder sammen for at fuldføre hver historie. Historierne accepteres eller afvises baseret på, om:

  1. De er essentielle for det nuværende Sprint-mål.
  2. De passer inden for den estimerede kapacitet tilgængelig for den aktuelle Sprint.

Et enkelt produktbacklog-element kan være enhver re fra 0 historie peger op til det maksimale tilgængelige for hele Sprint. En god historie, der opfylder INVEST-kriterierne er dog generelt sammensat af Sprint Backlog-opgaver, der er ca. 0,5 dage til 2,0 dage lange. Husk, at jo mindre opgaven eller historien er, jo mere præcist er estimatet normalt, så et dusin 5-punkts historier (når de er nøjagtigt estimeret) er generelt mere pålidelige end en enkelt 60-punkts historie. Dit holdets modenhed og estimationsnøjagtighed kan dog helt sikkert variere.

Svar

Brugerhistorier er ikke pr. teammedlem

Flere teammedlemmer skal arbejde på den samme bruger historien på samme tid. Dette er ikke et krav, men en anbefaling. Essensen af rugbyterminologien, scrum , hvor holdet går mod mållinjen som en enhed. Konceptet kaldes sværmer . Alle fokuserer på en (eller færre) opgaver på et givet øjeblik, fuldfører den og tackler det næste stykke arbejde (gentag). Fordele:

  • Det holder_ på status_ færre poster.
  • Det muliggør færdiggørelse af sprint-backlog-poster spredt over sprinten, i stedet for at alt afsluttes tæt på sprintenden.
  • Holder qa / testbelastning jævnt fordelt over sprintvarighed.
  • Hele teamet får kodeviden og kan give tekniske forslag.

Teamet skal vælg en historie og opdel den i tekniske opgaver. Kun én person skal arbejde på en teknisk opgave, fordi ansvaret er klart i dette tilfælde, hvilket hjælper under daglige scrummøder. Ideelt set skal en teknisk opgave være lille nok, så den bliver afsluttet i løbet af en dag.

Størrelse på brugerhistorier

Scrum definerer ikke nogen anbefalet størrelse på en brugerhistorie. En historie skal dog være dimensioneret således, at den kan afsluttes i løbet af en sprint. “Afslutning” betyder, at den dækker din “Definition af udført”.

En historie skal forstås tydeligt og have eksplicitte acceptskriterier , som bekræftes i samme sprint. Normalt er det sværere at stryge en stor historie ud og stave alle acceptkriterier, så en historie skal være lille, hvor den kan estimeres godt nok og testes.

En historie skal også være stor nok, så den leverer en konkret forretningsværdi til interessenterne.

Så svaret er hverken for lille eller for stort . Med praksis og erfaring bliver du bedre til at skrive og opdele brugerhistorier. Det er mere en kunst end videnskab.

Svar

Sprintplanlægning skal også være i historien. Processen er den samme som for den langsigtede planlægning. Du kontrollerer din hastighed og kapacitet (hvor mange af teammedlemmerne der vil være der på grund af helligdage osv.) og kommer op med et tal.

Hvis du planlægger sprint 2, skal du kontrollere din hastighed i sprint 1 – for eksempel 10 point – og sætte 10 point værd af brugerhistorier i din iterationsforsinkelse.

Hvis du planlægger sprint 3, skal du kontrollere din hastighedstrend fra sprint 1 til 2 og finde det beløb, du kan forpligte dig til.

Hvis du planlægger sprint 1, tilføjer du så meget som du finder det passende.

Prøv ikke at se, hvor mange point en person kan gøre , fordi scrum er om hold ikke personer. For eksempel kan en junior gøre mindre end en senior, men folk hjælper hinanden, de vil ikke kunne levere så meget som “på papiret”. Arbejd og bereg med team , fordi det giver mere mening (og det er lettere).

Kommentarer

  • Ja, Jeg er enig med dig, der skal henvises til samlede lagerpoint for tidligere sprints, og som du / CodeGnome sagde, skal der også tages højde for kapacitet. Faktisk er jeg forvirret over, at hvor kort skal være ” hver ” historie, så den kan testes parallelt, da der ikke er nogen separat testfase.
  • Jeg har også tidligere omtalt følgende: mountaingoatsoftware.com/blog/…
  • @Roop, som andre sagde, ” hver ” historie behøver ikke være kort nok. Den vil blive arbejdet af flere teammedlemmer, men opgaver i historien skal være holdes 0,5 dage til 2 dage

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *