Velocity Is the Only Number on the Wall
Atlas Fintech's leadership wall displays a single chart: story points completed per sprint. The three teams are compared on it monthly. Estimates have drifted upward by roughly 40 percent over two quarters with no change in delivered scope. The Product Owner orders the backlog by whichever internal stakeholder shouted loudest. Releases go out every nine weeks after a feature freeze. Product telemetry collected over a year shows that 58 percent of released features have fewer than five active users after 90 days, and nobody has reviewed that data. A regulatory deadline in fourteen weeks requires a specific reporting export that the team has not started.
1. What is wrong with the measurement system, and what would you replace it with? Be specific about what to stop, what to start, and how to avoid gaming.
Read the worked answer
Stop. Comparing teams on story points, ranking them monthly, and treating velocity as a target. Points are relative and team-specific; the moment they are used to compare, they cease to measure size and become a currency. The 40 percent drift with unchanged scope is not dishonesty, it is the rational response to being scored on the number. Any measure used as a target will be optimized directly.
Start. Outcome and flow measures: feature adoption and retention, conversion, cycle time, throughput, change failure rate, and time from idea to validated learning. Each backlog item carries a stated hypothesis and the signal that would confirm or kill it. Review the 58 percent telemetry as a first-class input in every Sprint Review, not as an annual curiosity.
Avoid gaming. Measure at the product level, never per team. Pair metrics that pull against each other - adoption with change failure rate, throughput with cycle time - so that improving one by degrading the other is visible. Forecast with ranges (80 percent confidence) rather than single numbers, and never attach a forecast to an individual's evaluation. Publish what you are not measuring, and revisit quarterly: every metric on a wall becomes a target eventually.
The through-line: the current system rewards shipping volume, and the telemetry shows the product is being optimized for the reward rather than for users.
2. Given fourteen weeks and finite capacity, how should the Product Owner decide what to build? Show the reasoning with the Sprint Review as an evidence point.
Read the worked answer
Treat the deadline as a constraint that shapes scope, not as an instruction to add work. The export is externally fixed, non-negotiable, and currently unstarted.
1. Slice to the minimum compliant scope and validate it early. Get compliance to confirm what the smallest acceptable export is, in writing, in week one. Teams routinely build three times the required scope because nobody asked.
2. Reserve capacity explicitly rather than hoping. For example, 35 percent of each of the next three sprints, with the remainder continuing on the Product Goal. A big-bang at week twelve has no room to recover.
3. Deliver the riskiest slice first. Earliest possible end-to-end proof, even ugly, so the unknown is discovered in week four rather than week thirteen.
4. Use each Sprint Review as a gate. Compliance attends; the real export output is inspected; scope is re-decided on evidence. The review every two weeks is the only mechanism that converts fourteen weeks of uncertainty into a sequence of informed decisions.
5. Say no out loud. Name what is deferred and to whom. A silent yes to everyone is a delayed no to the deadline.
6. Forecast honestly. Use throughput ranges to state now whether the date holds. Surfacing a 30 percent risk in week three is worth more than certainty in week fourteen.
3. A stakeholder asks the team to skip automated regression tests for two sprints to protect the deadline. What is your answer and how do you frame it?
Read the worked answer
Answer: no, not as a silent trade. Frame it around what the definition of done is for: it exists so that the Increment is genuinely releasable. Removing regression testing does not save two sprints of work; it moves the work to a place where it is more expensive and less visible, and it means the artifact being inspected at the Sprint Review is not what the organization thinks it is.
Redirect to the real trade. The deadline constrains time, so scope is the variable. Ask what the stakeholder would rather not have: three lower-value features, a narrower export, or a later phase for one market. Offer to bring that choice to the Product Owner with data rather than to make it in a corridor.
Offer options that preserve quality. Add pairing or a second tester for two sprints; shorten the feedback loop so regressions are caught in hours; run a targeted risk-based subset rather than nothing, with the excluded areas named.
If leadership overrides. Make it an explicit management decision with a named owner, a written consequence, and a scheduled repayment. Then make the consequence visible: track defects escaping to production and present them at the Sprint Review. The Scrum Master's job is not to win the argument but to ensure the trade-off is transparent, owned, and reversible.