Tidigare har jag förespråkat att använda T-shirt sizing när man estimerar produktbacklog och sedan story points till sprintbacklog-tasks men efter att ha lyssnat på Mike Cohn idag så får jag nog tänka om! Visserligen ska man inte ändra det som funkar och i de projekt jag har varit med så har det fungerat riktigt bra. Men de nackdelar med t-shirt sizing som han tar upp går ju inte att bortse ifrån.
Ett problem är att använda M, L och XXL när man estimerar features på produktbackloggen är att man inte kan addera dessa tillsammans och en kund kommer alltid att vilja veta när man ska vara klar med ett projekt. Att då svara att vi är klara om 4 small, 3 medium och 2 large funkar inte. Man måste ha estimat som går att addera så att man kan ta reda på vilken hastighet man har och därmed också kunna säga när i tiden man kommer att vara klar.
Så vad Mike föreslår är man ska använda story points när man estimerar de items man har på sin produktbacklog. Den typen av estimering gör man normalt innan första sprinten när man gör sin releaseplanering. Man bör försöka komma igenom hela produktbackloggen men inte lägga för mycket tid på varje item (ca 20 i timmen bör man klara av). Nya items kommer att komma in på produktbackloggen kontinuerligt så därför måste man också kontinuerligt estimera under varje sprint. För att estimera produktbacklogen funkar det alldels utmärkt att använda sig av Planning Poker och då behöver man heller inte konverera sina estimat till timmar.
När man sedan ska planer det jobb man ska göra i första sprinten måste man veta vilken hastighet teamet har. Om man har ett team som har genomfört ett antal sprintar är det ju inget problem men om man har ett nytt team så finns det även tekniker för att ta reda på vilken hastighet teamet kommer att ha. Hastigheten baserar man då på hur mycket teamet tror att de kommer att kunna hinna med under nästa sprint och använder det som teamets hastighet.
När teamet sedan ska bryta ner features från produktbackloggen till uppgifter i sprintbackloggen måste uppgifter mätas i ideala timmar. Vi har gjort så att vi har spelat planning poker och satt story points på uppgifterna och sedan räknat om dessa till ideala timmar. Jag frågade Mike vad han tyckte om det och han sa att det är nog i det läget bättre att göra det ”the old fashion way” och bara sätta timmar på de olika uppgifterna. Jag har alltid förespråkat att man ska, även på uppgiftsnivå, dra nytta av allas input i estimaten men Mike menar att om man har en databasexpert i temat som säger att en uppgift tar fyra timmar så är det bara att sätta fyra timmar på den uppgiften. Att implemntera en feature på produktbackloggen blir mest troligt ändå flera olika uppgifter, tex att skapa en stored procedure, att modifiera objektmodellen, att anpassa gränssnittet samt att testa de olika delarna. Och då är det bäst att de olika experterna för de olika områdena får sätta timmar på uppgifterna.
Det jag tror att jag kommer att ta med mig till mitt nästa projekt är att lära mig mer om user stories för att få en bättre produktbacklog. Estimera produktbackloggen mha planning poker i story points och sedan bryta ner den till tasks i sprintbackloggen och direkt sätta optimalatimmar på dessa.
Man blir så lycklig när man känner att bitar faller på plats! Nu måste bara se till att också uppdatera min kurs :-D
Inga kommentarer:
Skicka en kommentar