Posts

A rising velocity line doesn’t always mean the team is actually faster. When managers push for speed, builders will often unconsciously de-value points to make the numbers look better. Points become a currency, and inflation follows. That upward slope can be pressure, not progress. Velocity is a measurement, not an objective. Don’t force the thing you’re measuring. We estimate work during the planning meeting so the stakeholders can choose stories and plan for the next iteration. And that estimate is a forecast, not a promise. ...

We update the burn‑down and velocity charts only with points for stories that have passed their acceptance tests. Recording only done stories prevents optimistic noise and makes the charts honest signals. After several iterations both charts start to reveal a slope. And the burn‑down slope can help to predict the date for the next major milestone. The velocity slope helps to show how effective and consistent the team is running (early iterations will be noisy; but expect stabilization after a few sprints). ...

Stakeholders operate the system during the demo. When stakeholders click the buttons and run the flows themselves, the team sees real reactions and honest feedback. Stakeholder-driven demos remove the temptation that builder team might hide flaky features, and the team might discover gaps in the acceptance criteria, or might surface usability issues. This hands-on approach builds trust, teaches stakeholders the system, and gives the team clearer, actionable data to fix what matters. ...

Leveraging an agile approach to software development isn’t just about going faster. It’s about concrete, measurable progress. Reliable data matters. Completion is achieved when the acceptance tests pass. Then the story is considered done. Saying a story is “90% done” hides uncertainty and misleads planning. It doesn’t tell us what’s left, how risky the remainder is, or when the work will be releasable. For honest forecasting and useful velocity charts, we only record stories that have passed their acceptance tests. That keeps our metrics trustworthy and reduces false optimism. ...

As we approach the end of an iteration we need to decide which stories we’ll see to completion and which we’ll postpone or abandon, so we can reallocate our team’s efforts to finalize more work. We proactively make decisions to put-aside some “almost-done” stories so we can let others reach done status. Two half-done stories aren’t progress. We are explicit about which work we stop and why, and then refocus the team’s attention on finishing the chosen set of stories. This keeps momentum, reduces waste, and preserves quality. ...