Krav - hvordan og hvem gør hvad...
Vi har brugt en del tid på at optimere kravsprocessen her i huset, og vi blev i den forbindelse klar over, at vi med Scrum og fokus på roller og deres funktion måske var endt i en grøft, hvor forventninger til Product Owneren var for store. Vores PO skrev krav og overleverede disse til teamet under Estimeringsmødet op til en sprint. Dette er problematisk, da kravene ofte ikke var modne nok. Det er som citatet nedenfor også pointerer svært for en person alene at stå for dette arbejde.
"It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why."
Alle på teamet deltager i dette arbejde. Det er en kollaborativ proces. Man kunne spørge sig selv: hvorfor? Er det ikke spild og skal vi ikke lige netop fokusere på at eliminere spild i processen??
Jo lige netop! Ved at gøre det til en kollaborativ proces så sikrer man også den bedste vidensdeling og at udviklerne har et "godt" forhold til de krav, som står i backloggen, og som skal estimeres på et tidspunkt. Vi anvender user stories, som jo pr. natur er tænkt som værende et kommunikationsredskab, og derfor giver det endnu mere mening at samarbejde om modningen af disse, så hver user story fungerer som en effektiv placeholder for kommunikation. Ved at gøre kravsmodning til en kollaborativ proces tidligt i projektforløbet kan man opnå følgende gode fordele:
- Øget kommunikation imellem PO og team
- Bedre forståelse af user stories og deres boundaries
- Hurtigere og mere præcise estimeringssessioner (sprint planning 1)
- Bedre og mere præcise velocity-forudsigelser
- Bedre krav
- En velfungerende backlog, som teamet stoler på
- En PO som teamet stoler på
- etc.
Hvilke erfaringer har i gjort jer på området? Hvordan faciliterer i kravsmodning?
Etiketter: estimering, krav
indsendt af Rune Mai kl.
09:41
4 kommentarer:
Ja jeg er helt enig. Kom som lidt af en surprise da underviseren på scrummaster-kurset fortalte at det ikke er uhørt at et team afsætter 10% af tiden til at modne backloggen inden egentlig sprintplanlægning.
Man skal heller ikke undervurdere værdien i at udviklerne ved hvad der skal ske i fremtiden - det giver os trykhed. (Men også en lille risiko for at vi designer for fremtiden).
Hej Poul :) I forhold til din pointe omkring, at udviklere gerne må kende til fremtiden: Det er jo ret sjovt egentligt, at man overhovedet behøver at diskutere den slags. Det burde være en selvfølge. Den gamle historie med de tre munke, der bygger en kirke. Den første bliver spurgt "hvad laver du" og svarer "jeg lægger sten". Den anden spørges og svarer "jeg bygger en stor væg". Den trejde spørges og svarer "Jeg bygger en fantastisk kirke". Hvem mon har det bedste kvalitetsfokus? Og hvem kunne måske ende med at sende ideer tilbage i omløb?`
Det kan (jeg siger ikke 'er') være et problem med Scrum, at man glemmer det som ligger forude og får udviklere til at koncentrere sig udelukkende om forestående sprint(s).
meget interessant, tak
god start
Send en kommentar
<< Startside