A delivery manager introduces a quarterly target: every Scrum Team must raise its velocity by fifteen per cent, and team performance reviews will cite the number. Within two Sprints the team's story point totals have risen and no more working software is reaching users than before. What is the most accurate statement about this measure?

Professional Scrum Master I, objective 3. Managing products with agility medium

Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.

Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.

The options

Not correct Velocity is a valid measure of value as long as the team's estimates stay consistent between Sprints

Wrong, and it is the tempting one because it sounds like a fixable measurement problem. Even perfectly consistent points measure how much work was undertaken, never whether the result was worth having.

Not correct Velocity is the correct measure but the target should be set by the Scrum Master rather than the manager

Wrong twice over. It keeps the wrong measure and hands it to someone whose accountability is effectiveness, not throughput reporting.

Correct Velocity measures output, and in order to provide value the Increment must be usable — points completed say nothing about that

Correct. The Guide ties value to a usable Increment and offers no measure of value at all, so the question worth asking each Sprint is what users can now do that they could not do before, not how many points were burned getting there.

Not correct The team should stop estimating altogether, since Scrum does not require velocity

Wrong, and it overcorrects. Scrum prescribes no estimation technique, but the Developers doing the work are responsible for sizing items, so abandoning estimation altogether removes something the Guide does expect. The defect here is what the number is being used for, not that it exists.

Why

Every measure an organisation reaches for by default — velocity, hours logged, items closed, percentage of plan delivered — describes the work, not the result of the work. Each one can be raised without a single user being better off, which is exactly what happens when it becomes a target. Scrum offers no measure of value in its place; what it points to is the Increment itself, usable and Done and inspected with stakeholders. Ask what the product can now do for someone, and you cannot game the answer by re-scoring the backlog.

Where this comes from

Cited
Scrum Guide section Increment
What it says
In order to provide value, the Increment must be usable.

Practise this

Reading one question is not practice. The trainer will draw a set from objective 3 and space the ones you get wrong.

Practise Professional Scrum Master I

More questions on this objective

All questions on Managing products with agility