Fortsätt till huvudinnehåll

Lider ni av otydligt klarkriterium?

Har du varit med om följande? Ni samlas för att planera upp en sprint, men kör snabbt fast i en diskussion om hur lång tid saker och ting kommer att ta. Till slut lyckas ni med möda få ihop en plan för sprinten, men när väl sprintgranskningen kommer visar det sig - alldeles för sent - att ni inte alls är överens om att ni är klara. Produktinkrementet har ojämn kvalitet. Några saker är väl testade, andra håller knappt ihop för demo.

Ni kan lida av otydligt klarkriterium. Många gör det.

Vad kan orsaka otydligt klarkriterium? Här är några möjliga orsaker:
  • Det känns så självklart vad "klart" betyder att det känns onödigt att prata om det
  • Ni förstår att ett försök att definiera vad klar betyder kommer att visa hur icke-överens ni är, vilket gör att ni skickligt undviker ämnet
  • Ni har inte sett behovet av att definiera "klar", eftersom ni ännu inte upplevt några problem av att inte ha en gemensam definition
Klarkriteriet hjälper teamet att samarbeta. Utan ett gemensamt klarkriterium kan man egentligen inte veta vilket slutmål man siktar på. Såväl estimering och planering som genomförande blir lidande. Där någon tänker "if it compiles, ship it", tänker en annan sig att automatiserade tester, uppdaterade byggscript och granskning av koden krävs för att en ny funktion ska anses klar. Det blir en källa till konflikter.

Ett kännetecken hos ett effektivt team är att man har en gemensam överenskommelse om hur man arbetar tillsammans. Klarkriteriet är en del av en sådan överenskommelse för effektiva scrumteam.

Är ert klarkriterium tillräckligt tydligt? Samla ditt team och be alla deltagare att, utan att prata med varandra, skriva ned sin definition av "klart" som en punktlista på ett indexkort. När alla är klara, visa korten för varandra och berätta vad ni skrivit? Är era kort ganska lika eller ganska olika? Vad kan ni lära er av de skillnader som finns?

Kommentarer

Martin sa…
Vårt team hade god nytta av att ägna ett helt skulle-ha-varit-retrospective-möte åt att skapa en gemensam klardefinition. Vi utgick från det här klargörande blogginlägget:
http://www.gettingagile.com/2007/10/05/building-a-definition-of-done/
Tobias Fors sa…
Hej! Det låter som en alldeles utmärkt användning av tiden!

Populära inlägg i den här bloggen

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k