Vi vet att långsiktig planering (släppplanering) borde vara i historien.
Men för sprintplanering borde det vara engagemang baserat.
Bryta upp produktbackloggen / användarberättelsen i uppgifter och uppskatta uppgifterna, teamet frågar sig om de kan åta sig att leverera produktbackloggen och sedan upprepa tills de är fulla?
Under en tre veckors sprint, hur stor ska varje historia vara för en person?
Jag har också sett att vissa lag gör sig av med den här uppgiftsbaserade planeringen och har berättelser som bara är två dagar långa ?
Ska jag standardisera detta för mitt team?
Så innan en sprint bryter jag mina berättelser till sådana noveller att de passar denna standard.
Snälla, låt mig veta dina synpunkter om detta. Och vad är allmän praxis?
Kommentarer
- Scrumguiden har ändrats från ” engagemang ” till ” prognos ”. Du kan läsa om orsaken till den här ändringen här.
- Den här länken kan vara till hjälp pm.stackexchange.com/questions/10119/ …
Svar
TL; DR
I grund och botten är hela din uppsättning planeringsantaganden icke-smidig. Du måste se över hur du planerar dina iterationer och hur ditt team planerar att uppskatta det arbete som det tror kan slutföras för den aktuella iterationen. En mer detaljerad analys följer.
Detaljerad analys
Vi vet att långsiktig planering (Release planering) borde vara i berättelsepunkter. [sic]
Nej Agile release-planering görs i iterationer . Därför kommer en Scrum-projektplan att uppskatta ett ungefärligt antal iterationer som behövs för att nå den minsta livskraftiga produkten eller slutföra den ursprungliga produktbackloggen. Detta är endast en uppskattning eftersom eftersläpningsinnehållet kommer att förändras över tiden, och uppskattningernas längd och noggrannhet också kommer att ändras tillsammans med Osäkerhetskon .
Men för sprintplanering bör det vara åtagandebaserat.
Återigen, nej. Sprintplanering är kapacitetsbaserad . Den enda punkten för spårning (eller skapa en inledande guesstimate av) lagets genomsnittliga hastighet är att hitta lagets hållbara förmåga att arbeta över tid. Teamet måste vara säker på att aldrig förbinda sig för att arbeta i en Sprint bara för att hastighetsintervallet eller genomsnittet säger att det ska finnas ledig kapacitet, men det är lagets ansvar att planera för den aktuella iterationen genom att ta lagsammansättning, tillgänglighet , och andra faktorer som påverkar nuvarande Sprint i beaktande.
Att säga att Sprints är ”åtagandebaserade” kommer sannolikt att användas som en känslomässig slam för att få team att förbinda sig till mer fungerar än de borde, för naturligtvis bör teammedlemmar vara ”engagerade.” Det är emellertid ett missbruk; i den verkliga världen bör lagkapaciteten i allmänhet minskas men sällan blåses upp under planeringen. Om teamet har underförpliktat sig kan ytterligare arbete avlägsnas från produktbackloggen efter behov, men trimningsomfånget är nästan alltid politiskt fylligt och riskerar ofta Sprint-målet. Så gör inte det.
Kapacitet kan vara ett relativt objektivt mått. Å andra sidan kan engagemang (ungefär som patriotism) inte mätas om du inte ” vi ber människor att ”göra det ultimata offret”, vilket är ett slags motsats till hela förutsättningen för smidig hållbarhet. Förplikt dig aldrig till en dödsmarsch .
I en tre veckors sprint, hur stor ska varje historia vara för en person?
Detta förtjänar en hel bok fylld med ”nej.” Berättelser är aldrig dimensionerade för eller accepterade av en individ. Alla berättelser uppskattas baserat på de fullständiga, samordnade resurserna för ett tvärfunktionellt team som arbetar tillsammans för att slutföra varje berättelse. Berättelserna accepteras eller avvisas baserat på om:
- De är väsentliga för det aktuella sprintmålet.
- De passar inom den beräknade kapaciteten tillgängligt för den aktuella sprinten.
En enda produktbacklogg kan vara vilken som helst re från 0 berättelse poäng upp till maximalt tillgängligt för hela Sprint. En bra historia som uppfyller INVEST-kriterierna består dock i allmänhet av Sprint Backlog-uppgifter på cirka 0,5 dagar till 2,0 dagar. Kom ihåg att ju mindre uppgiften eller berättelsen är, desto mer exakt är uppskattningen vanligtvis, så ett dussin 5-punkts berättelser (när de är exakt uppskattade) är i allmänhet mer tillförlitliga än en enda 60-punkts berättelse. Dock kan lagets mognad och uppskattningsnoggrannhet verkligen variera.
Svar
Användarberättelser är inte per teammedlem
Flera teammedlemmar ska arbeta på samma användare berättelse samtidigt. Detta är inte ett krav utan en rekommendation. Kärnan i rugbyterminologin, scrum , där laget går mot mållinjen som en enhet. Konceptet heter svärmning . Alla fokuserar på en (eller färre) uppgifter vid ett visst ögonblick, slutför det och tar itu med nästa arbete (upprepa). Fördelar:
- Det håller_ på gång_objekt färre.
- Det gör det möjligt att komplettera sprintbackloggsposter spridda över sprinten, istället för att allt avslutas nära sprintänden.
- Håller qa / testbelastningen jämnt fördelad över sprintlängden.
- Hela teamet får kodkunskapen och kan ge tekniska förslag.
Teamet bör välj en historia och dela upp den i tekniska uppgifter. Endast en person bör arbeta med en teknisk uppgift eftersom ansvaret är klart i det här fallet vilket hjälper under dagliga scrummöten. Helst bör en teknisk uppgift vara tillräckligt liten så att den slutförs under en dag.
Storleken på användarberättelser
Scrum definierar ingen rekommenderad storlek på en användarberättelse. En berättelse bör dock vara dimensionerad så att den kan slutföras under en sprint. ”Slutförande” betyder att det täcker din ”Definition av klar”.
En berättelse ska vara tydligt förstått och ha uttryckliga godkännandekriterier som verifieras under samma sprint. Normalt är det svårare att stryka ut en stor historia och stava ut alla acceptanskriterier, så en berättelse ska vara liten där den kan uppskattas tillräckligt bra och testas.
En berättelse ska också vara tillräckligt stor så att den levererar ett konkret affärsvärde till intressenterna.
Så svaret är varken för litet eller för stort . Med övning och erfarenhet blir du bättre att skriva och dela användarberättelser. Det är mer en konst än vetenskap.
Svar
Sprintplanering borde också vara i historien. Processen är densamma som för långsiktig planering. Du kontrollerar din hastighet och kapacitet (hur många av teammedlemmarna kommer att vara där på grund av helgdagar etc.) och kommer upp med ett nummer.
Om du planerar för sprint 2, kontrollerar du din hastighet i sprint 1 – till exempel 10 poäng – och lägger till 10 poäng till användarberättelser i din iterationsbacklog.
Om du planerar för sprint 3, kontrollerar du din hastighetstrend från sprint 1 till 2 och hittar det belopp du kan förbinda dig till.
Om du planerar för sprint 1 lägger du till så mycket som du tycker passar.
Försök att inte se hur många poäng en person kan göra , eftersom scrum är om lag inte personer. Till exempel kan en junior göra mindre än en senior, men människor som hjälper varandra kommer inte att kunna leverera lika mycket som ”på papper”. Arbeta och beräkna med team , eftersom det är mer vettigt (och det är lättare).
Kommentarer
- Ja, Jag samtycker till dig, totala poäng för tidigare sprints som ska refereras till och som du / CodeGnome sa, kapacitet ska också tas med i beräkningen. Egentligen är jag förvirrad att hur kort ska vara ” varje ” berättelse så att den kan testas parallellt eftersom det inte finns någon separat testfas.
- Dessutom har jag tidigare hänvisat följande: mountaingoatsoftware.com/blog/…
- @Roop, som andra sa, ” varje ” berättelse behöver inte vara tillräckligt kort. Den kommer att arbetas av flera teammedlemmar men uppgifter inom berättelsen bör vara hålls 0,5 dagar till två dagar