Kanban is data-driven continuous improvement. Test your flow hypotheses here: change WIP or variability and see the real impact before touching the team.
Form a hypothesis, set a baseline, change one variable and run the experiment. Compare before and after, like a flow scientist.
No experiments saved yet.
The tool runs the simulation. What separates an experiment from a guess is what you define before pressing the button.
One sentence in the shape of “if I cut WIP from 15 to 8, lead time drops and predictability rises”. A hypothesis written after the result is not a hypothesis, it is a justification.
Without a starting point there is no comparison. The baseline is the picture of the flow as it stands today, with the numbers you will look at again at the end.
If you move WIP and variability together and lead time improves, you will not know which one caused it. One experiment at a time costs more time and returns real knowledge.
The simulation proves nothing about your team, it shows how the system behaves. The value is leaving with a small, reversible change to test in real life.
The variable with the strongest and most counterintuitive effect. Lowering WIP usually cuts lead time without anyone working faster, because it removes queues from the system. It is worth finding the point where further cuts stop paying off.
Irregular demand arrival and items of very different sizes. Raising variability at the same WIP shows why overloaded teams get slow: waiting grows non-linearly.
How long an item takes end to end. It is the number the customer feels.
How many items come out per period. Shows whether the change raised delivery or just rearranged it.
How much work sits in progress at once. It is the cause, not the effect.
How repeatable the results are. A fast but unpredictable flow is still hard to promise.
Flow changes are counterintuitive with uncomfortable frequency. Raising people utilization usually makes delivery worse. Adding people to the bottleneck sometimes changes nothing, because the bottleneck was somewhere else. Reducing work in progress speeds up delivery without anyone speeding up the work.
Testing those ideas straight on the team is expensive in two senses. It costs weeks before the effect shows in the data, and it costs credibility when the change makes things worse and has to be undone. A simulation does not replace the real experiment, but it removes the hypotheses that do not survive even on paper.
The result that matters is not the number from the simulation. It is the conversation it lets you have with the team before changing any policy.
You set a baseline, change one variable (WIP or variability) and run the experiment. The tool simulates the flow and shows the before and after comparison in lead time, throughput, WIP and predictability.
Because flow changes have counterintuitive effects. Testing the hypothesis in a simulation avoids optimizations that make delivery worse.
Yes, in your browser. You build a history of experiments and conclusions.
No. It simulates a flow system with the parameters you set. To work with your real numbers, the path is the flow analyzer, which reads your board CSV.
You can, but the result becomes ambiguous: you will know something improved without knowing what. To learn, change one at a time and compare against the same baseline.
Take it to the team as a hypothesis, not as proof. The useful experiment is the next one: a small policy change, with a timebox and an agreed metric to watch.
No. The lab runs straight in the browser and experiments are saved locally, on your own device.
The analyzer reads your board CSV inside your own browser and shows cycle time, percentiles and the delivery forecast.
Open it straight from your home screen, full screen, like an app.
On iPhone: tap Share , then "Add to Home Screen".