Sprint-backlog
For næste projekt som starter op om en uge har vi valgt at anvende excel fremfor (tunge) tfs til taskstyring og kravdelen. Det betyder, at både produkt-backlog og sprint-backlog laves i excel. I den forbindelse kunne jeg godt tænke mig at høre om jeres erfaringer i den henseende. Hvilke problemer kan vi forvente at støde på, og findes der smarte løsninger på disse problemer? Hvilke felter har I med i jeres backlogs og hvorfor?
Jeg har lavet et udkast til en sprint-backlog, hvor der for hver dag er mulighed for at indtaste både timeforbrug og resterende timer. Det synes jeg ikke jeg har set i nogle af de andre sheets jeg har kunnet finde på nettet. Er der en grund til det? Umiddelbart tænker jeg selvfølgelig på, at nogle vil mene at det er rent tidspilde at forsøge at tracke performance af estimater, men hvis man nu gerne vil kunne kigge på, hvor lang tid en opgave tog i forhold til opgavens estimat, så er man vel nødt til at have den information med?
indsendt af Rune Mai kl.
21:05
3 kommentarer:
Som jeg ser det, er der ikke værdi i at kigge på en individuel task. For jeg kommer aldrig til at lave den specifikke task igen. Det er jo altid nye opgaver man løser.
Og hvis man vil gå ind lidt mere generelt og se på hvor lang tid det tager, så kan man jo beregne sin burn-rate på story/feature niveau når det kommer til sprints. Eller mere overordnet igen på sit produkt i forhold til product backlog og en burnrate der.
Lang smører, gav det mening?
Hej Rune, jeg kan ikke se detaljerne i arket; men Restestimater er jo en gammel velkendt metode til opgørelse af færdiggørelsesprocenter til brug i EVA, EarnedValueAnalysis m.fl. Restestimater burde du finde alle steder i tidsforbrug registrering - også i Projects finder du dem. De er sjældent populære, fordi mange siger, at de da ikke har tid til at estimere hele tiden - der skal jo også laves noget :-) Men sagen er vel, at hvis man ikke hele tiden kender sit restestimat, hvordan skal man så disponere sine dage?
Når jeg nu tænker over det, så har Daniel egentlig ret i forhold til at lære af estimaterne, meen alligevel i Scrum er det jo meningen at udviklerne selv compiler listen af opgaver (sprint backloggen) og estimerer de enkelte opgaver, og det er egentlig på det niveau jeg også gerne vil tracke, hvordan det går. Eksempelvis underestimerer vi altid implementering af UI-controls etc?
En anden gavnlig biting er også at det bliver synliggjort, hvad arbejdstiden bruges på. Altså forstå mig ret: ikke fordi jeg vil micro-manage folk, men fordi udviklere derved kan indikere at de laver for mange off-project opgaver eller lign. "jeg arbejder kun på konkrete opgaver 2 timer om dagen.."
Til Finn: jeg bruger reestimater til at kunne lave en daglig burn-chart opdatering, som er teamets fælles pejlingsinstrument og også kommunikation til projektets omgivelser. Jeg synes ikke det er for meget forlangt, at udviklere lige tager stilling til, hvor lang tid der er tilbage på den opgave de har siddet med, inden de går hjem.
Send en kommentar
<< Startside