Planview-bloggen

Din väg till smidighet i affärsverksamheten

Agil planering för företag, Work Management för team

Mätning av batchstorlek, WIP och genomströmning

Publicerad Av Alex Glabman

Del 1 av denna serie, 5 Lean och Agile Metrics för att mäta och följa med ditt team: Lead Time och Cycle Time, delade jag med mig av två av de fem Lean- och Agile-mätningar som bör följas. I den här bloggen talar vi om att mäta batchstorlek, WIP och genomströmning. Låt oss börja.

Målet för alla agila team är att nå ett tillstånd av kontinuerlig leverans. Detta kräver att teamet eliminerar den traditionella start-stopp-start-processen för projektinitiering och utveckling, och den mentalitet som följer med den. Hur kan teamet åstadkomma detta? Genom att aktivt styra sina batchstorlekar.

PARTISTORLEK: HUR MYCKET ARBETE SKA VI FÖRSÖKA SLUTFÖRA UNDER DEN HÄR SPRINTEN?

Vad det är: Hur många arbetsmoment, eller den totala storleken på arbetet, som tas in i början av varje sprint.

Hur det mäts: Uppskattad ansträngning, mätt genom storleken på berättelsepunkterna, antalet arbetsmoment osv.

Vad den berättar för oss: Det är värdefullt för att skapa realistiska uppskattningar under planeringen av färdplanen.

Batchstorlek är ett mått på hur mycket arbete - krav, design, kod, tester och andra arbetsmoment - som förs in i systemet under en viss sprint. I Agile handlar batchstorlek inte bara om att behålla fokus - det handlar också om att hantera kostnaden för förseningar. Små partier går igenom systemet snabbare och med mindre variationer än större partier. De främjar också ett snabbare lärande - ju snabbare du kan få ut något och se hur kunden reagerar på det, desto snabbare kan du ta med det i ditt framtida arbete.

WIP: HUR MYCKET ARBETAR VI MED JUST NU?

Vad det är: En ögonblicksbild som visar hur många arbetsobjekt som aktivt arbetas med vid en viss tidpunkt.

Hur det mäts: Team som använder Kanban-tavlor kan se WIP genom att räkna hur många kort som för närvarande finns i deras aktiva/in process/görande banor (digitala tavlor kan mäta detta automatiskt).

Vad den berättar för oss: Det här antalet över tid hjälper till att visa om ett team startar arbetsmoment innan det avslutar befintlig WIP (vilket skapar ett push-baserat system i stället för det önskade pull-baserade systemet).

Medan batchstorlek anger hur mycket arbete vi försöker göra under en sprint, anger WIP (work in progress) hur mycket arbete vi aktivt arbetar med vid varje given tidpunkt.

Varför är detta viktigt? Om målet för ett team är att arbeta tillsammans för att få saker gjorda, men alla arbetar med olika saker, blir samarbetet en tävlingssport. Istället för att samarbeta för att flytta uppgifter genom systemet så snabbt som möjligt konkurrerar teammedlemmarna om varandras tid, energi och uppmärksamhet, vilket skapar ett system som fastnar i sin egen ineffektivitet.

För mycket pågående arbete kan leda till förseningar i överlämningen, alltför många möten, byte av sammanhang, dubbelarbete och annat slöseri som kan undvikas med lite mer disciplin (läs mer om varför vi behöver begränsningar för pågående arbete här ). Att aktivt, som ett team, se över hur mycket arbete som pågår och diskutera vad som kan göras för att flytta det arbetet genom innan tar in nytt arbete kan bidra till att lindra många av de spänningar som många team upplever.

Precis som med batchstorlekar är det en process att hitta en "optimal" nivå av WIP för varje team. Det finns ingen formel för att fastställa det exakta antalet WIP som är lämpligt för alla team - det varierar beroende på teamets storlek och hastighet, processens effektivitet, komplexiteten och variationen i arbetet osv.

När du har fastställt ett realistiskt men utmanande mål för teamets nuvarande WIP kan du fastställa en WIP-gräns. Att sätta gränser för WIP kan vara särskilt bra för team som tenderar att känna sig överväldigade, överarbetade eller avskilda från varandra.

Genom att sätta gränser för WIP tvingas teamet att prata inte bara om själva arbetet, utan också om när och hur ni tar in nytt arbete i systemet och hur varje teammedlems handlingar påverkar systemet som helhet. Det är en utmanande men omvälvande metod som kan ha stor inverkan på teamets prestationer med tiden (här finns en övning på för att komma igång med WIP-gränser i teamet).

GENOMSTRÖMNING (HASTIGHET) OCH LITTLE'S LAG:

Vad det är: Ett mått på hur många arbetsuppgifter som slutförts under en viss tidsenhet.

Hur det mäts: På en Kanban-tavla - kort per dag, kort per vecka osv.

Vad den berättar för oss: Hur effektivt teamet utför arbetet; visar hur mer arbete i systemet kan påverka cykeltiden.

Genomströmning (ibland kallad velocity) är det genomsnittliga antalet enheter som behandlas per tidsenhet. I ett agilt system kan exempel vara "kort per dag", "kort per vecka" eller "story points per iteration".

Att mäta genomströmningen kan vara mycket användbart för prognoser, särskilt efter att en hel del data har samlats in (under flera sprintar). Eftersom rapporter om genomströmning följer det prognostiserade och slutförda arbetet under flera iterationer, blir prognosen mer exakt ju fler iterationer det handlar om.

Produktchefer/ägare kan använda genomströmning för att förutsäga hur snabbt teamet kan arbeta sig igenom den aktuella backloggen (t.ex. "Kommer vi att avsluta de objekt som finns på tavlan i slutet av den aktuella sprinten?").

Eftersom utvecklingsarbetet är mycket varierande är det viktigt att följa upp och definiera genomströmningen beroende på vad som påverkar dina arbetsflöden. Ta en stund och fundera på vad din definition av genomströmning - kort per dag, kort per vecka osv. - betyder i samband med ditt teams arbete. Glöm inte att ta hänsyn till effekten av avvikande värden i din mätning, eftersom en viktig händelse kan förändra hela genomsnittet drastiskt. Det är effektivast att se genomströmningen antingen som en trend eller genom att kombinera den med andra mätvärden, som cykeltid och ledtid, för att få en helhetsbild av teamets kapacitet och produktivitet.

Relaterad till genomströmning är Littles lag, en hypotetisk formel som kan användas för att visa hur förändringar av systemets input kan påverka systemets output.

Formel för cykeltid.

Om ett team till exempel har 25 kort i process (dvs. deras totala WIP) och en genomströmning av 1.5 kort/dag, är den genomsnittliga cykeltiden 16.66. dagar. Om samma grupp behåller samma genomströmning men ökar sin totala WIP till 40 kort blir den genomsnittliga cykeltiden 26.66 dagar. Littles lag kan vara värdefull för att visa hur en minskning av WIP kan minska cykeltiden. Du kan också förbättra cykeltiden genom att öka genomströmningen, även om detta är mycket svårare än att minska den totala WIP-volymen.

FRAMÅT OCH UPPÅT!

Det är värt att nämna ännu en gång att mätvärden inte alltid är till hjälp - när du bestämmer dig för att börja rapportera om något mätvärde bör du fråga dig själv: Varför? Varför är den här mätningen viktig? Vilket mål hjälper den oss att uppnå?

Sträva efter att alltid närma dig rapporteringen med öppenhet och nyfikenhet - för att lära dig nya saker, inte för att bekräfta det du redan vet.

Använd Lean- och Agile-mätningar för att identifiera problem och belysa förbättringsmöjligheter, inte för att straffa någon, bevisa en poäng eller uppnå andra personliga ambitioner. Lean- och Agile-metriker bör vara dina vänner, verktyg som hjälper ditt team att utvecklas till ett effektivare, mer samarbetsvilligt och i slutändan hälsosammare system. Använd Lean- och Agile-mätningar för att göra gott, inte ont, och du kommer att se ditt team åstadkomma stora saker.

Om du redan tillämpar Kanban genererar du som tur är redan data som ger dig insikter om hur du kan förbättra ditt Lean- och Agile-arbetsflöde. Om du inte är det, rekommenderar jag att du går igenom övningarna i Kanban Roadmap med ditt team. När du väl har en tavla som korrekt speglar din nuvarande process har du allt du behöver för att börja utveckla ditt team. Genom att införa Lean- och Agile-metriker kan du blåsa nytt liv i ett team och samla alla kring möjligheten att arbeta smartare, få mer gjort och stressa mindre. Lycklig rapportering!

Relaterade inlägg

Skrivet av Alex Glabman Product Manager

Som produktchef för Planview LeanKit gillar Alex att förenkla det komplexa för potentiella kunder och kunder. Alex har praktisk erfarenhet av att implementera Lean och Agile i olika organisationer och en passion för att visa upp data, och han är en förkämpe för ständiga förbättringar och äter elefanter en bit i taget. Vanderbilt-alumn, hundälskare, bourbonnörd.