To keep a steering report looking healthy, a manager asks the Developers to mark items as done when the code is merged and to record the remaining test work as separate items in a later Sprint. Reported completion rises to ninety-five per cent. What is the effect in Scrum terms?

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

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 It is acceptable, because the remaining work is still visible in the Product Backlog as its own items

Wrong, and it is the sharpest distractor here because the work genuinely is written down somewhere. The report still says finished when the product is not, and that is the number decisions are made on.

Not correct It is a reporting matter outside Scrum, since Scrum does not define steering reports

Wrong. Scrum does not define the report, but it does define the artefact the report describes, and an Increment that overstates what is finished is a Scrum problem wherever the number is printed.

Not correct It is acceptable if the Definition of Done is amended to match the new practice

Wrong. Weakening the Definition of Done to fit the report lowers quality rather than raising completion, and during the Sprint quality does not decrease. Where the organisation already carries a Definition of Done as a standard, no Scrum Team may drop below it either.

Correct It destroys the transparency of the Increment, and decisions based on a misleading artefact diminish value and increase risk

Correct. The Increment is one of the three artefacts on which important decisions are based, and inspecting an artefact that misstates its own state is worse than not inspecting at all.

Why

Transparency is not an honesty virtue in Scrum; it is a precondition for the whole empirical loop. Important decisions are based on the perceived state of the artefacts, so an Increment reported as more complete than it is quietly corrupts every decision downstream — what to release, what to fund, what to promise a customer. Inspection without transparency is misleading and wasteful. A pleasant number that describes nothing real costs more value than the bad news it was invented to avoid.

Where this comes from

Cited
Scrum Guide section Transparency
What it says
Artifacts that have low transparency can lead to decisions that diminish value and increase risk.

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