Myt #4: Det går inte att estimera test i Scrum

Det går inte att estimera test i Scrum eller i andra agila metoder. Har du hört det förut? Tycker du själv att det är svårt att estimera när teamet arbetar på ett agilt sätt? Först vill vi säga att det är svårt att estimera vad det än må vara, men om det är svårare när ni arbetar med Scrum? Detta skall vi nu diskutera.

Ursprung

I ett icke-agilt projekt är det inte ovanligt att start och slutdatum redan är satta och att testarens uppgift snarare blir att göra så mycket testning som möjligt på den tid som finns avsatt. När ett team väljer att arbeta agilt flyttas ansvaret från individen till teamet för den övergripande planeringen.

Inom Scrum blir planering och estimering ännu viktigare. Precis som allt annat ska även testaktiviteterna rymmas i sprinten då teamet tillsammans gör ett åtagande om att leverera ett visst antal user stories på tid. Det går inte längre att flytta över ansvaret för deadlines, felaktiga projektplaner eller någon annans estimat. I Scrum är teamet delaktigt i hela planerings- och estimeringsarbetet. Detta tror vi kan vara en svår omställning för många icke-agila team. Det är inte ovanligt att det upplevs som svårare att estimera i Scrum och andra agila utvecklingsmetoder än vad teamet tidigare är vant vid.

En annan anledning till ursprunget av myten är svårigheten att estimera tid för rättningar, avvikelser och ledtid i utvecklingsprocessen. I Scrum är inte avvikelser och rättningar av dessa separerade från utvecklingsprocessen utan en naturlig del. Teamet testar, kodar, fixar, testar, kodar och fixar till dess att de är nöjda. Det är inte en avvikelse förrän ni i teamet har bestlutat att koden är färdig.

Att gå från att estimera enbart hur lång tid det tar att skriva testfall, hur lång tid det tar att köra testfallen, o.s.v. till att estimera hur lång tid det tar att som team tillsammans bygga en bra funktion med hög kvalitet kräver både övning och ett annorlunda tillvägagångssätt vid planering och utförande.

.

Om estimering i Scrum

Eftersom estimering alltid är en svår och ibland en hopplös uppgift, känner vi igen frustrationen. Däremot är det varken omöjligt eller svårare att estimera i Scrum. Snarare tvärtom, så anser vi att Scrum kan förenkla för estimeringsprocessen, om ni gör på rätt sätt.

I Scrum är inte test en separat fas, team eller roll utan något som finns med i hela utvecklingsprocessen och något som alla tar ansvar för. Detta gör att estimeringen av testaktiviteter kommer förfinas och uppdateras under arbetets gång. Denna flexibla process stöds av ett agilt arbetssätt som Scrum och test är med som en ytterst viktig komponent.

Enligt Scrum bryts alla uppgifter ner till stories, beställningar eller vad ni vill kalla det för, till mindre delar. Det är som vi alla vet enklare att estimera mindre delar och det minskar eventuella felkällor. I början innan teamet har fått en möjlighet att bryta ner en story kommer estimeringen att vara osäker och risken att estimaten ändras är stor. Men det är inget problem. I Scrum är teamet medvetet om just denna osäkerhet och ser inte det som ett problem för att lyckas estimera sitt arbete. Vi försöker inte förutse allt först (vi är ärliga med att vi inte är ett orakel som kan se in i framtiden), utan vi låter plan, design och estimat förändras allt eftersom vi jobbar och bygger ny kunskap.

I det fall teamet bara är “halv-agilt”, d.v.s. inte har något releasebart i slutet av en sprint utan det krävs en del releasearbete innan allt är färdigtestat och packeterat, så blir även det arbetet enklare att planera och estimera. Dels har vi längs med resan undanröjt en massa risker. Vi har testat kontinuerligt vilket leder till generellt färre funna galenskaper i releasetestningen. Slutligen – vi har lärt oss massor under resan; hur vi testar på ett smart sätt, hur lång tid olika typer av tester brukar ta och vad vi bör lägga testkrutet på.

.

Alltså

Att estimering är svårt är inget vi behöver förklara. Det är alltid svårt att estimera hur lång tid något tar att genomföra. Det är nästan omöjligt innan teamet kommit en bit in i arbetet. Är teamet oerfaret eller om det är komplexa system, eller kanske helt nya lösningar, kommer estimeringen att bli än mer osäker.

En övergång till Scrum utgör ofta en utmaning och kommer att kräva ett nytt mindset. Från att estimera test som något som görs i slutet är det nu plötsligt något som sker kontinuerligt och av alla under hela utvecklingsprocessen. Som testare har du inte längre en separerad roll utan bidrar med en kompetens till ett team som tillsammans tar ett ansvar att leverera önskad lösning. Det låter bra men är ingen enkel omställning, detta behöver få ta tid och det behövs träning.

Scrum försöker hantera estimering av utvecklingen på ett sätt som förhoppningsvis förenklar för även er som har er huvudkompetens inom test och kvalitetssäkring. Detta görs bland annat genom att bryta ner till mindre delar och genom att hela teamet tar ansvar för det totala estimatet och att det hålls.

Utifrån detta anser vi att myten är BUSTED. Visst förstår vi att det initialt kan vara svårt att estimera, men har teamet övat och satt en agil kultur i företaget så kommer Scrum att förenkla när ni ska estimera.

.

.

.

.

Men alltså, alltså…

Är det inte ännu viktigare att diskutera myt nummer 42; “Att estimera är viktigt och tillför värde”? Jo, det kan man tycka. Nu råkade vi dock dra ovanstående myt ur kortleken och då var det myten “Det går inte att estimera test i Scrum” som blev satt under lupp.

Men visst. Har man kommit långt på sin agila resa och lärt sig organisera sig för att optimera flöde av värde, då tillför troligtvis estimat ingenting. Vissa argumenterar till och med för att de är kontraproduktiva. Men har man precis börjat jobba agilt är det dock en ypperlig idé att köra Scrum enligt regelboken och estimera för att lära sig de agila mekanismerna bakom, finna och undanröja waste, lära sig slutföra framför att påbörja nytt, osv. Det är först när man lärt sig cykla som stödhjulen blir ett hinder snarare än ett stöd. Djupare än så går vi inte denna gång gällande myt 42.