Kanban

Visualize your work for sure — but go the extra mile to optimize the flow of value. This piece dives into what happened when an advanced Featureban simulation got real: variable PBIs per feature, inter-dependencies, cost of delay profiles, classes of service, and a few "black swans" thrown in for good measure (one predicted millions in value and earned 50 cents; another predicted 20k and earned 5 million — proof that small bets matter). Along the way, see how teams discovered "Little's Flaw killer policies" that improved Scrum performance up to 10x, why aged work management trumps fancy ranking schemes, and why a PBI shouldn't move through two in-progress columns in one day. Don't be fooled by temporarily rising throughput without WIP limits. WIP is a leading indicator of cycle time — and cycle time is where the real game is played.

Don't just limit WIP — optimize it. The Sprint itself is a form of WIP limiting, but adding more granular WIP limits dramatically improves Scrum team performance. This piece digs into the four basic flow metrics every Scrum team using Kanban should track (WIP, cycle time, work item age, and throughput), and shows what 90 advanced Featureban simulations across the US and EU revealed about WIP limits in practice. The sweet spot? Roughly 2/3 to 3/4 of the number of development team members. Why does limiting WIP reduce cycle time? Because Little's Law — proven in 1961, still true today — kicks in once you stop allowing work to age. Plus a look at "Little's Flaw killer policies," why fake WIP limits behave like push systems, and why a frugal product owner can't substitute for team discipline. WIP is a leading indicator of cycle time. Don't be fooled by temporarily rising throughput.