Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

Om WIP-gränser och kortstorlek

Publicerad Av Chris Hefley

En av de nya funktionerna som just släppts i Planview AgilePlace Kanban är möjligheten att specificera WIP-gränser med hjälp av kortstorlek, istället för antalet kort i en körfält. Tidigare i veckan, efter att jag hade meddelat att den här funktionen skulle införas, fick jag ett par "Verkligen?"-mejl, som det här från Arne Roock:

Chris,

Jag såg precis era nya funktioner. De flesta av dem ser riktigt bra ut! Men en funktion förvirrar mig: "WIP-gränser efter kortstorlek".

Enligt vad jag har förstått har vi för avsikt att begränsa antalet objekt som vi arbetar med - inte antalet Story Points etc. Att arbeta med 10 objekt med storleken 1 är alltså helt annorlunda än att arbeta med två objekt av 5 eller ett objekt av 10!

Nu är jag intresserad: Har du någonsin sett lag lyckas med att begränsa den totala ansträngningen i stället för antalet kort?

Skål,
Arne

Och han har naturligtvis helt rätt.  Det bästa sättet att begränsa pågående arbete är att begränsa det totala antalet objekt som du arbetar med samtidigt. I vårt team använder vi inte fältet Kortstorlek alls, och när det är möjligt uppmanar vi våra kunder att inte använda det. De mest framgångsrika Kanban system som vi har observerat följer inte upp kortstorleken alls, när ett objekt väl har hamnat på tavlan (även om en viss storlek på planeringsnivå kan ha förekommit när man bestämde hur man ska dela upp ett större objekt i olika delar för att få fram det på tavlan).

Så varför göra denna funktion tillgänglig överhuvudtaget? För att våra kunder ville ha det, och för att fler och fler av våra kunder använder Planview AgilePlace för andra saker än Capital-K Kanban:

  • Vi har många rena Scrum-team som använder Planview AgilePlace som visualiseringsmetod - utan något egentligt behov av att betrakta sig själva som "ScrumBan" eller att "konvertera" till Kanban. Genom att tillämpa WIP enligt kortstorlek kan dessa team planera sin sprintbacklog baserat på kortstorlek och fastställa en WIP-gräns för en "sprintbacklog"-fil antingen på vänster sida av tavlan eller i huvudbackloggen i Planview AgilePlace.
  • Vi har också många -team utanför mjukvaruutveckling och IT-organisationer som använder Planview AgilePlace för akademiska forskningsprojekt, visualisering av försäljningspipeline, marknadsföringsplaner, strategiska målningar och mycket mer.
  • Många av våra kunder använder Planview AgilePlace på lagnivå, men vi får fler och fler som använder det för att visualisera och planera på portföljnivå - en enterprise Kanban-vy. Vid planering på den här nivån vill vissa grupper kunna tilldela kapacitet baserat på storlek, inte bara på antalet artiklar.

Så för de av er som är nya i Kanban och försöker lära er hur ni ska lyckas med det rekommenderar vi definitivt att ni begränsar ert arbete i processen genom antalet objekt, inte genom storleken på dessa objekt.  Men för de av er som tänjer på gränserna i alla riktningar, tillämpar traditionell Scrum (lustigt... när blev Scrum "traditionellt"?), eller tillämpar Kanban utanför IT i andra miljöer där "bästa praxis" inte riktigt är välkänd ännu, är ni välkomna att använda den nya WIP-gränsen efter kortstorlek.

Och lycka till.

Relaterade inlägg

Skrivet av Chris Hefley

Chris Hefley är medgrundare av LeanKit. Efter att i flera år ha kämpat med "trasiga" projektledningssystem inom mjukvaruutveckling hjälpte Chris till att bygga LeanKit som ett sätt för team att bli effektivare. Han tror på att bygga programvara och system som gör människors liv bättre och förändrar deras förhållande till arbetet. I 2011 nominerades han till Lean Systems Society's Brickell Key Award. Följ Chris på Twitter @indomitablehef.