The Developers keep their own list of technical debt and infrastructure work in a separate tool, and pull from it whenever they have spare capacity, so that it never has to compete with features in the Product Backlog. The Product Owner is aware and content with the arrangement. What is the problem?
Professional Scrum Master I, objective 1. Understanding and applying the Scrum framework 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
Correct The Product Backlog is the single source of work undertaken by the Scrum Team, so a second list removes transparency and makes the Product Owner's ordering a partial picture
Correct. Everyone downstream — the Product Owner ordering, the stakeholders at the Sprint Review, anyone forecasting — is reasoning about a product whose real workload is larger than the artifact says.
Not correct Nothing — technical work is the Developers' business and does not belong in a product backlog
Wrong, and it confuses two questions. How work is done is the Developers' business. Whether work is undertaken at all is a product decision, and this work consumes the same Sprint as everything else.
Not correct The only problem is that the Product Owner cannot size the hidden items
Wrong. Sizing would still be the Developers' job even if every item were visible. The failure is that an entire stream of work is invisible at the moment the product's priorities are set.
Not correct The Developers should stop doing technical work unless a stakeholder asks for it
Wrong, and it is the opposite mistake. Technical work is real product work; the fix is to put it in the Product Backlog where it can be ordered against everything else, not to stop doing it.
Why
The Product Backlog is an emergent, ordered list of what is needed to improve the product, and it is the single source of work the Scrum Team undertakes — which makes any second list a transparency problem rather than a tidiness one. The usual objection, that technical work will always lose to features, is a real risk and is answered by the Product Owner understanding the trade-off, not by hiding the work from them.
Where this comes from
- Cited
- Scrum Guide section Product Backlog
- What it says
- It is the single source of work undertaken by the Scrum Team.
Practise this
Reading one question is not practice. The trainer will draw a set from objective 1 and space the ones you get wrong.
Practise Professional Scrum Master I
More questions on this objective
- A department is choosing an approach for a product where both the requirements and the technology are poorly understood and keep changing as the team learns. Someone argues for Scrum "because it is founded on empiricism". What does founding an approach on empiricism actually commit the team to? machine-checked
- At the end of a Sprint three items are functionally complete but have not been through the automated test suite the Definition of Done requires. To avoid an awkward conversation the Developers mark them Done on the board and include them in the Sprint Review. Which pillar has been damaged, and what follows from that? machine-checked
- A Scrum Team holds every event on schedule, keeps a burn-down chart and reviews its metrics carefully. For six Sprints running, the same impediment — a two-day wait for a shared test environment — has been named in the Retrospective, and nothing about it has changed. What is the accurate diagnosis? machine-checked
- Mid-Sprint, the Developers discover that a third-party API rate-limits far below what they assumed, which makes the current plan unworkable. One of them suggests carrying on as planned and raising it at the Sprint Retrospective, so the Sprint is not disrupted. What should happen instead? machine-checked
- Which THREE of these statements about Scrum theory are accurate as the framework defines it? machine-checked
- A Developer is fairly sure the design the team agreed last week will not scale. The team is halfway through the Sprint, everyone else seems content, and saying so means an uncomfortable conversation and probably rework. Which Scrum value most directly asks them to speak? machine-checked
All questions on Understanding and applying the Scrum framework