Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
Every organization has a version of the same conversation: a delivery date slips, and someone asks why the estimate was wrong. The unspoken assumption is that better estimators, more detailed plans, or stricter processes would have gotten it right. That assumption is comforting, but largely false.In 1979, Daniel Kahneman and Amos Tversky described what they called the planning fallacy. This is the tendency to predict task completion times that are far too optimistic, even when people know from experience that similar tasks have historically taken longer. What makes the planning fallacy interesting is that it persists among experts, even when past failures are fully visible and the stakes are high. Bent Flyvbjerg's later research into large infrastructure projects found much the same pattern at massive scale. He learned that nine out of ten megaprojects run over budget because the act of planning itself is biased toward best-case thinking. People adhere to the plan as written and discount the countless ways reality diverges from it.Software and product delivery are not exempt from this. If anything, they are more exposed to it, because the work is often genuinely novel. You cannot look up how long it takes to build something that has never been built before.The Plan Is Not the TerritoryThe instinctive response to unreliable forecasts is to demand a better plan: more detail, more up-front analysis, more confidence before committing to a date. This is where Scrum's underlying theory offers a useful correction. Scrum is founded on empiricism, the idea that knowledge comes from experience and that decisions should be based on what has actually been observed rather than what was assumed in advance. The Scrum Guide is direct about what this means for forecasting:"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."That last sentence is worth sitting with. Forecasting has to be built from evidence, not intention. A plan built primarily on how a project is supposed to go is a hypothesis, not a forecast. The two get treated as the same thing far too often, and that conflation is where most of the trust in planning quietly erodes.Measuring the Wrong Things Makes It WorseEvidence-Based Management, Scrum.org's framework for decision-making under uncertainty, draws a distinction that's easy to state but hard to practice: the difference between outputs and outcomes. Outputs are the things an organization produces: features shipped, story points completed, velocity charts trending upward. Outcomes are what those outputs actually change for the customer or the business. Organizations gravitate toward measuring outputs because outputs are easy to count. Outcomes require harder thinking about value.This matters for planning because most forecasting failures get diagnosed at the output level: "We said we'd deliver twenty items; we delivered fourteen." The more useful diagnostic question is upstream of that: what changed between the estimate and the delivery, and was that change knowable in advance? Almost always, the answer involves things that don't show up on a burndown chart until they've already caused damage, such as unplanned work arriving mid-sprint, technical debt quietly taxing every subsequent estimate, or backlog items getting re-sized as understanding improves. None of these are signs of a poorly run team. They are signs of a team doing real work in a complex environment, where the environment itself is part of the system being estimated.From Defending a Date to Enabling a DecisionThe healthiest shift a team can make in planning is toward a different purpose altogether, rather than a precise plan. A forecast used to defend a date invites exactly the behavior that erodes trust, like padding estimates, hiding risk, or quietly redefining "done" to hit a number. A forecast used to inform a decision does something different. It tells a Product Owner, a stakeholder, or a leadership team what is likely, what is uncertain, and what would have to be true for either to change. That's a much more honest and ultimately, more useful conversation than "Will we hit the date?"Probability and range-based forecasting exist precisely because certainty was never available in the first place. Communicating a date as a range with a confidence level is fostering transparency about what is actually knowable at the time the forecast is made. This is the same principle that makes Scrum's artifacts useful; transparency precedes any meaningful inspection or adaptation.The Real Skill Is Not Predicting the FutureTeams that get better at planning are the ones that get better at building forecasts from real evidence, communicating what those forecasts do and don't tell you, and treating every miss as information about the system rather than a failure of the people in it. That's a different skill set than traditional estimation, and it's one worth deliberately building.Scrum.org recently launched a self-paced course, Estimation and Planning for Scrum Teams, that delves deeper into this territory. It explores how empiricism, probability, and visualization combine to produce forecasts that hold up under real-world conditions such as technical debt and unplanned work. Whether that course is the right next step for you or not, the underlying idea is worth carrying into your next planning conversation; the goal was never to predict the future; it was to always make better decisions with the evidence you have.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Warum Aufwandsschätzungen in der Softwareentwicklung gleichzeitig sinnvoll und gefährlich sind | 0 | 6.5 | 28-07-2026 |
| 2 | Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren | 0 | 11.71 | 28-07-2026 |
| 3 | Cognitive Trap: Velocity Misinterpretation | 0 | 7.37 | 20-07-2026 |
| 4 | You Can Ignore the Flow Data. It Still Decides When You Ship. | 0 | 13.6 | 12-07-2026 |
| 5 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 6 | Cognitive Trap: Sprint Commitments Misunderstanding | 0 | 7 | 29-06-2026 |
| 7 | How to Manage Product Risk When You Can’t Predict Everything | 0 | 10.55 | 23-07-2026 |
| 8 | Flow Metrics in Python: 3 Scripts for Ensuring Transparency | 0 | 14.98 | 23-07-2026 |
| 9 | The Project Manager Isn't Dead. It Was Disassembled on Purpose! | 0 | 16.43 | 27-07-2026 |
| 10 | Ordering the Product Backlog with RICE: From Opinion to Evidence | 0 | 5 | 09-07-2026 |