Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.
In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).
My Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).
Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!
Jo
De beperking van Stories-in-omloop die je aanhaalt, doe je toch sowieso met je Sprint Backlog.
Een Kanban is een fysieke visualisatie onder de vorm van een kaart. In TPS wordt hiermee een balans verzorgd tussen aanvoer en afname van voorraad. Te veel stock = waste en te weinig breekt het proces. Op gezette tijden (niet: on the spot bij het minste verbruik!) worden in productie de kaarten verzameld en wordt in de stock geshopt. Aan de hand van de afgenomen stock kan aangevuld worden. Voor beide processen zijn fysieke kaarten in omloop.
Dat is toch exact wat je doet met de Sprint Planning. Je weet hoeveel Stories je in een Sprint logischerwijze kan maken en dat is dan ook de ‘voorraad’ die je bespreekt en in meer detail uitwerkt. Teveel uitwerking = waste en te weinig zorgt dat je proces kan breken als development goed genoeg vooruit gaat.
En “pull” doe je ook door Stories uit de Product Backlog te trekken tijdens de Sprint Planning, en tijdens development door het team zelf te laten trekken uit de Sprint Backlog. En dat je niet aan een nieuwe Story begint vooraleer je lopende Story afgewerkt is, is toch niet meer dan normaal.
Ik zie dus geen enkele discrepantie in toepassing van het principe en het idee. Letterlijke toepassing is iets anders, want het gaat over 2 verschillende processen, namelijk autoproductie (vrij voorspelbaar) en softwarecreatie (innovatief en creatief). En autoproductie behoeft geen timeboxing, terwijl software development dat wel nodg heeft.
Wel toch met dat verschil dat kanban normaal gezien van een pull-systeem vertrekt, terwijl scrum op zich de geplande stories in een sprint pusht?
Heb ik het goed begrepen dat bij een echte kanban, je geen sprints of iteraties meer hebt (aangezien dat geplande stories in een sprint eigenlijk een soort van inventory is die tot een minimum moet beperkt worden), maar een constante flow. Pas wanneer een user story volledig af is, mag er een nieuwe story op het kanban bord gehangen worden. De kunst is dan te zoeken naar het ideale aantal stories dat in omloop is.
Ik vind het persoonlijk niet evident om de principes van scrum en kanban volledig te handhaven, maar iets er tussen dat probeert om een aantal principes van de twee te combineren is wel mogelijk . Het idee om een maximaal aantal stories in omloop te hebben vind ik sterk, want het motiveert een team om stories af te maken en pas aan nieuwe stories te starten (nieuw development vindt het team meestal leuker dan testwerk, documentatie etc) als een story volledig voldoet aan de definition of done.