Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAThe Velocity Misinterpretation TrapMost mistakes in Scrum aren’t because people don’t understand the framework—they come from applying reasonable thinking in the wrong context. Cognitive traps happen when decisions favor efficiency, control, or comfort over transparency, inspection, and adaptation. Here is one of ten cognitive traps, the Velocity Misinterpretation Trap: treating velocity as an accurate forecast that is stable.Velocity gets treated like a measure of productivity or performance. It’s not. It’s just a rough guide for how much work a team might take into a Sprint based on what they’ve done before.Story points are fine—but only for the conversations they force. They help teams talk through complexity, risk, and unknowns. Planning poker works because it surfaces assumptions. That’s the value.Simulated Assessment QuestionA Scrum Team increases its velocity by refining Product Backlog Items into smaller items, but delivers no additional value. What is the most accurate interpretation?Performance has improved due to better refinementProductivity has increased based on higher velocityVelocity has increased, but it does not reflect greater value deliveryThe team is more predictable and therefore more effectiveAnswer: CWhy this is correctVelocity didn’t go up because the team got better. It went up because the team changed how it counts work. By splitting Product Backlog Items into smaller pieces, they changed the unit of measurement. That makes the new velocity number meaningless when compared to previous Sprints. Nothing about value delivery improved.This is the core issue: velocity only works as a planning input when the system behind it is stable. Once you start changing how work is sized, you break that stability. The number might go up, but the signal is gone.So no—this isn’t better performance, increased productivity, or improved predictability. It’s just a different way of counting.The trapThis is metric fixation. It happens all the time. Velocity starts as a planning aid, but once people see it, they start using it as a performance signal. That leads to predictable behavior:splitting work to increase point totalsredefining estimatesfocusing on velocity instead of outcomesNone of this improves delivery. It just improves the number.The real issue isn’t the metric—it’s how it’s used. Metrics feel objective, so they become targets. And once that happens, teams start managing the metric instead of the work.A simple way to think about it: When a metric becomes a target, it stops being useful.From a Scrum perspective, this can break everything:transparency is compromised because the metric no longer reflects realityinspection is misleading because the data is distortedadaptation becomes ineffective because decisions are based on bad signals You end up with the appearance of progress without actual improvement.If you stop using story points for forecasting—and you should—you still need a way to plan. Not forecasting at all isn’t realistic. A better approach is to separate the two concerns. Use story points and planning poker to drive conversation. That’s where they help. Once that’s done, stop treating the numbers as predictive.Instead:refine PBIs until they’re small and clearfocus on how many items you actually complete (throughput)look at how long things take (cycle time)use that data to forecast with probabilities based on flowFor example:“We can complete 30 items next Sprint with 50% probability, 21 with 85%, and 14 with 95%.”That’s a more honest way to plan. It makes uncertainty visible instead of pretending it doesn’t exist.If this required thought—or felt even slightly uncertain—that’s the point. Cognitive traps don’t get resolved through reading; they are discovered and avoided through deliberate practice. The most effective way to discover cognitive traps is through classes. If you want to identify and eliminate these patterns, take one of my classes or run through a simulation assessment—use the links below to get started.My ClassesFree Simulation
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Cognitive Trap: Sprint Commitments Misunderstanding | 0 | 7 | 29-06-2026 |
| 2 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 3 | Incremental Delivery and the Need for Speed | 0 | 15.1 | 14-07-2026 |
| 4 | Your Team Isn't Bad at Estimating. Planning Is Just Harder Than We Admit | 0 | 11.64 | 14-07-2026 |
| 5 | Silos are the Bane of Value Delivery | -5 | 7 | 29-06-2026 |
| 6 | Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren | 0 | 11.71 | 28-07-2026 |
| 7 | You Can Ignore the Flow Data. It Still Decides When You Ship. | 0 | 13.6 | 12-07-2026 |
| 8 | Vibe-Coding für Anforderungen – geht das? Wie Prototypen das Refinement retten, bevor es peinlich wird | 0 | 8.6 | 21-07-2026 |
| 9 | Beyond Blame: Transforming Team Dynamics Through Feedback | 0 | 16.56 | 22-07-2026 |
| 10 | O que aprendeste hoje? | 0 | 10.98 | 14-07-2026 |