Image
Somewhere this week a team will commit to a date. A director asks when the feature lands, a room full of capable people stares at a roadmap, someone picks a quarter that feels safe enough to say out loud, and everyone nods. Meanwhile, in a dashboard nobody has opened since the tool was installed, the team's actual delivery record sits there quietly. Throughput for the last twenty weeks. Cycle times. The age of every item stuck in progress right now. The meeting ignores all of it and picks the quarter anyway.That is the strange ritual at the center of most planning. We have the numbers. We do not use them. We prefer the guess because the guess is comfortable, and then we act surprised when the guess turns out wrong by a factor of two.You can ignore the flow data. The flow data does not care. It keeps running your delivery whether or not anyone is watching, and at the end of the quarter it wins, the way it always wins, because it was never an opinion in the first place.The Four Numbers That Already Run Your TeamDaniel Vacanti spent an entire book making one unfashionable argument: managing flow is the best strategy for predictability. Not better estimates. Not thicker plans. Flow. And flow is described by four plain measurements that every team already produces without trying. Throughput, the number of items you actually finish per week. Cycle time, how long each finished item took. Work in progress, how many things you have open at once. Work item age, how long the things currently open have already been sitting there.These are not reporting metrics you bolt on to please management. They are the physics of the system. Little's Law ties three of them together in a single line: your average cycle time equals your work in progress divided by your throughput. Read that slowly, because it carries a consequence nobody in the roadmap meeting wants to hear. If you keep starting more work without finishing faster, your cycle time gets longer. It is arithmetic. You cannot vote against it, motivate your way past it, or reframe it in a stand-up.Work item age is the one I would keep if I could keep only one. Cycle time reports how long finished work took, which is history, and history cannot be changed. Age tells you how long the thing on your board has been open right now, while you can still act on it. It is the smoke alarm of the system, and most teams have it switched off.Wishful Thinking Has a Track Record, and It Is BadThe reason the roadmap guess feels fine is that it arrives with no memory attached. Every estimate turns up fresh and optimistic, unburdened by the last ten that were wrong in exactly the same direction. This is not a personal failing. It is a documented pattern with a large research base behind it.Bent Flyvbjerg built a career measuring it. His work on reference class forecasting traces bad forecasts to two sources, optimism bias and strategic misrepresentation, and his fix is almost rude in its simplicity: stop forecasting from your hopes and start forecasting from the real results of comparable work you have already finished. The method draws on Nobel-winning decision research, and it holds that the outside view, your own track record, beats the inside view, your story about why this time is different, almost every time.Sit with that for a second. Your team's history is a better predictor of your team's future than your team's plan. The plan is a wish. The history is evidence. When the two disagree, and they always disagree, the evidence is what actually happens.The Honest Forecast Comes With a ProbabilityThe grown-up alternative is not a smarter single date. It is refusing to hand over a single date at all, because a single date is a lie with false confidence baked into it.Run a Monte Carlo simulation on your own throughput and it does something no estimate can. It takes your last few months of real completions, replays them thousands of times in random order, and returns a distribution. Not "we ship on the 14th," which is fiction, but "there is an 85 percent chance we finish 20 items by the 14th, and if you want 95 percent certainty, move the date out two weeks." The flow community even has a nickname for this discipline, getting to 85, because forecasting at the 85th percentile gives you a commitment you can actually keep.This is the part that exposes the whole game. A probabilistic forecast built from your own data sounds less certain than a roadmap date and is far more likely to be right. We reject it precisely because it is honest. A range admits we do not fully control the future. A date pretends we do. Plenty of organizations choose the pretense, then pay for it every quarter without ever connecting the bill to the choice.So Why Does Everyone Look Away?Because the flattering number wins the meeting. Velocity and story points survive not because they forecast well, they forecast badly, but because they yield a single confident figure a manager can drop into a slide. The evidence is almost comic: velocity is one of the most popular agile metrics and also the one most often called unhelpful, which is a strange thing to be at the same time. It stays popular because it feels like control. Flow metrics feel like a mirror, and nobody books a meeting to look in the mirror.There is also the small matter of incentives. Reward a team for hitting a velocity number and the team optimizes the velocity number, which stops meaning anything within two sprints. Underneath the applause the system keeps running on its own arithmetic, completely indifferent to which figure got cheered.Stop Arguing With the SystemNone of this needs new tooling or a transformation program. It needs you to stop treating your own delivery data as wall decoration.Look at the oldest item on your board before you look at anything else, because that is where your next missed date is already forming. Cap the work in progress so Little's Law starts working for you instead of against you. When someone asks for a date, answer with a probability drawn from your throughput rather than a quarter drawn from the ceiling. And when the forecast from your history contradicts the plan on the slide, trust the history.The numbers are not a management fad you can quietly outlast. They are a description of how your work actually moves, and they are running right now, in the background, keeping score. You are free to ignore them. They will simply go on being right, and go on winning, until the day you decide it is easier to think in flow than to keep losing to it.Ralph Jocham is Europe's first Professional Scrum Trainer, co-author of "Professional Product Owner," and contributor to the Scrum Guide Expansion Pack. As an ICF ACC certified coach, he works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.References[1] Vacanti, D.S. (2015) 'Actionable Agile Metrics for Predictability: An Introduction', ActionableAgile Press. Available at: https://actionableagile.com/books/aamfp/[2] Businessmap 'What Is Little's Law and How Does It Work?'. Available at: https://businessmap.io/continuous-flow/littles-law[3] Flyvbjerg, B. (2006) 'From Nobel Prize to Project Management: Getting Risks Right', Project Management Journal 37(3). Available at: https://arxiv.org/abs/1302.3642[4] ActionableAgile 'Products and services to help you improve flow, be predictable'. Available at: https://actionableagile.com/[5] Vacanti, D. 'Getting to 85 - Agile Metrics with ActionableAgile Part 1', Scrum.org. Available at: https://www.scrum.org/resources/blog/getting-85-agile-metrics-actionableagile-part-1[6] Verwijs, C. 'Story Points are not the Problem, Velocity is', Scrum.org. Available at: https://www.scrum.org/resources/blog/story-points-are-not-problem-velocity
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Flow Metrics in Python: 3 Scripts for Ensuring Transparency | 0 | 14.98 | 23-07-2026 |
| 2 | Your Team Isn't Bad at Estimating. Planning Is Just Harder Than We Admit | 0 | 11.64 | 14-07-2026 |
| 3 | Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren | 0 | 11.71 | 28-07-2026 |
| 4 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 5 | Cognitive Trap: Velocity Misinterpretation | 0 | 7.37 | 20-07-2026 |
| 6 | Incremental Delivery and the Need for Speed | 0 | 15.1 | 14-07-2026 |
| 7 | From Chaos to Control, Part 6 - Adapt and Control | 0 | 10.61 | 22-07-2026 |
| 8 | Silos are the Bane of Value Delivery | -5 | 7 | 29-06-2026 |
| 9 | Mehr Flow durch Mob-Programming | 2 | 6 | 07-07-2026 |