Free PSD practice test: 30 questions with answers

Product Backlog refinement is an ongoing activity in which the Developers who will do the work collaborate with the Product Owner to make items smaller and clearer. The Scrum Master does not own refinement, waiting delays the work without reason, and starting oversized items reduces predictability and transparency.

Test-driven development reverses the usual order: a failing automated test comes first, and the code is written to satisfy it, which keeps the design shaped by behaviour. Exploratory, acceptance and load testing are valuable but happen after the code exists, so they do not change the sequence described.

A test pyramid with many fast unit tests and few slow end-to-end tests keeps feedback quick, and independent tests can run in parallel without hidden coupling. Running only end-to-end tests is slow, deleting flaky tests hides defects, and order-dependent tests are fragile.

Emergent design means the architecture grows with the product, so the team designs enough for the current items and refactors as understanding improves. A fixed up-front design and a frozen architecture both ignore what the team learns, and the Scrum Master does not approve design decisions.

Technical debt describes the cost paid later for shortcuts taken now, such as weak tests or messy code. Scope creep, velocity variance and release burnup are real terms, but none of them describes the accumulated cost of poor-quality implementation.

Frequent integration into a shared mainline, backed by automated builds and tests, keeps each change small and surfaces conflicts early. Delaying merges, giving one owner per module and long-lived branches all make conflicts larger and harder to resolve.

Automated tests verify behaviour the team agreed to build, but usability and value need feedback from real users and stakeholders. Unit tests cannot judge usability, removing integration checks weakens quality, and a Done Increment does not have to satisfy every individual user.

Scrum Developers collectively have all the skills needed to create the Increment, so cross-functional work removes the handoffs that cause the waiting. Coordination meetings, queue tracking and an integration role manage the handoffs rather than removing them.

Empiricism rests on transparency, inspection and adaptation, and a visible board makes the real state of the work observable to everyone. Adaptation and inspection depend on that visibility rather than being the practice itself, and commitment is not about ignoring new information.

Courage is the Scrum value that lets people raise uncomfortable concerns and tackle hard problems despite fear. Focus, respect and commitment are also Scrum values, but none of them addresses the fear of speaking up in the scenario.

The Product Owner is accountable for maximizing product value, and ordering the Product Backlog is one of the ways that accountability is met. The Scrum Master supports Scrum, the Developers manage the Sprint Backlog, and stakeholders do not approve Product Backlog items as a formal role.

The Sprint Review is where the Increment is inspected with stakeholders and feedback is used to adapt the Product Backlog. The Daily Scrum, Sprint Retrospective and Sprint Planning each have different purposes, and none of them is the event for stakeholder inspection of the Increment.

The Sprint Retrospective inspects the Sprint's people, relationships, processes and tools, and produces improvements for the next Sprint. Presenting the Increment belongs to the Sprint Review, the Retrospective follows the Review rather than preceding it, and all Scrum Team members take part.

The Increment is the sum of completed Product Backlog items from this Sprint and the value of all earlier Increments, and it must be usable and potentially releasable. The forecast, the task list and the approved set describe other things, such as forecasts or the Sprint Backlog.

Work that does not meet the Definition of Done is not part of the Increment, however close it is. The Definition of Done is a commitment to quality rather than a guideline the Scrum Master can waive, and product owner acceptance does not replace it.

Only the Product Owner has the authority to cancel a Sprint, and that is done when the Sprint Goal becomes obsolete. Developers, stakeholders and the Scrum Master do not hold that authority, although they can give the Product Owner information to act on.

The Scrum Guide describes Developers as self-managing, which means they decide who does what, when and how. Assignment by the Scrum Master, by the Product Owner or by functional managers all conflict with that description.

Self-management means the team decides how to do the work within the constraints the organization imposes, so it should build the review into its own agreements. Ignoring the rule, demanding its removal or splitting out a separate team each conflict with self-management or with the cross-functional team.

A structured round gives quieter people equal space to contribute before discussion, which is a facilitation technique rather than a directive. Silencing a team member, taking over decisions and cancelling the event each work against the team's ownership of its improvement.

Good facilitation keeps the Daily Scrum on the Sprint Goal and impediments, and it lets the Developers decide their own next steps. Status reports to the Scrum Master, reports to the Product Owner and assigned actions all turn the event into something the Scrum Team is not meant to do.

Sharing practical technical skills so that a colleague grows is mentoring. Facilitation concerns meetings, forecasting concerns planning and stakeholder management concerns external parties, so none of them describes the skill transfer in the scenario.

Pairing and building learning into the team's routine is coaching that grows the Developer's own skill. Writing the tests for the Developer removes the learning, and certification gates or performance reports to the Product Owner are not how Scrum Teams develop skills.

Coaching helps the individual and the team see that self-management includes owning decisions and commitments. Assigning tasks, removing the person or handing their daily work to the Product Owner would all undermine the self-managing team the Scrum Guide describes.

Agile forecasts are probabilistic, so presenting a range that reflects observed throughput and scope changes gives the stakeholder honest information. A single committed date from the best Sprint, a refusal to forecast and a single average-based guarantee each hide the uncertainty.

A release burnup chart plots completed work against total scope over time, so growth in scope is visible. A Sprint burndown covers only one Sprint, and a cumulative flow diagram or a per-Developer velocity chart does not show release scope growth.

Maximizing value means weighing expected outcomes, including uncertainty, using evidence, and ordering the backlog to match. Seniority, building everything at once and choosing the easiest work all ignore value, which is what the Product Owner is accountable for.

A healthy Product Backlog is more detailed at the top, where work is near, and is ordered by the Product Owner in a way others can see. Exact hour estimates, changes made without the Product Owner and an ever-growing undifferentiated list each undermine those qualities.

The Product Owner stays accountable for ordering the Product Backlog even when others help with the work, so the Developer can contribute input. Handing accountability to the Developers, giving ordering to the Scrum Master or requiring written approval for each decision all misstate the accountability.

The Sprint Review is where stakeholders inspect the Increment and provide feedback that informs adjustments to the Product Backlog. Deployment, individual performance approval and decision auditing are not purposes of the Sprint Review.

Usage data is evidence of whether delivered features create value, so the Product Owner should investigate with customers and adapt the backlog. Praise from stakeholders is not the same as customer value, and more features or a weaker Sprint Review avoid the real problem.