PSD common mistakes
PSD · Understand the traps and how to avoid them.
Treating the Sprint Review as a status presentation to stakeholders and the Sprint Retrospective as a general team meeting, so questions that ask 'which event produces an adaptable Increment of feedback' or 'where are process improvements inspected' get answered with the wrong event.
Candidates memorize event names and timeboxes but not each event's purpose, so Review and Retrospective blur together, and the Daily Scrum gets confused with a progress report to the Scrum Master.
What to do instead
Build a one-page table with one row per event listing purpose, who attends, what is inspected, what is adapted, and the timebox. For each event write one sentence beginning 'The purpose of the ... is to ...' using the Scrum Guide wording for the purpose only, then test yourself by covering the purpose column.
Answering that the Scrum Master assigns tasks, estimates work, or decides which Developers do what, instead of recognizing that the Developers self-manage how to turn the Product Backlog into an Increment.
Real workplaces often have a de facto lead, and candidates import that hierarchy into answers, or they overcorrect and make the Scrum Master responsible for removing every impediment personally.
What to do instead
Learn the three Scrum Master accountabilities (coaching the team in self-management and cross-functionality, helping focus on creating high-value Increments, and removing impediments) and the Developer accountabilities (creating the Sprint Backlog, instilling quality, adapting the plan daily, holding each other accountable). When a scenario describes a decision about how work is done, ask 'who owns the work?' before choosing.
Choosing 'the Product Owner must attend the Daily Scrum' or 'the Scrum Master runs the Daily Scrum' as correct, rather than recognizing the Daily Scrum is for the Developers and is structured and timeboxed by them.
Candidates conflate the Daily Scrum with conventional stand-ups where a manager facilitates, and they miss that the Scrum Guide says the Developers can select whatever structure and techniques they want as long as it focuses on progress toward the Sprint Goal.
What to do instead
Memorize that the Daily Scrum is a 15-minute event for the Developers, that the Scrum Master and Product Owner may attend only if they are actively working on Sprint Backlog items, and that the Developers own its structure. Practice scenario questions by first identifying who is a Developer on that team.
Assuming the Definition of Done is optional, team-negotiated per Sprint with no organizational baseline, or that it can be relaxed to hit a Sprint deadline.
Teams in practice use 'done enough' informally, and candidates carry that habit in, missing that if the organization has a Definition of Done as a standard, all Scrum Teams must follow it as a minimum.
What to do instead
Learn the Definition of Done as a formal commitment attached to the Increment: a shared understanding of what it means for work to be complete, created and used by the Developers, mandatory as a minimum when an organizational standard exists, and never weakened to declare work complete. Link it to the Increment question: work that does not meet it is not part of the Increment.
Describing the Increment as something delivered only at the end of the Sprint or only at a release, and answering that work must be released every Sprint.
Candidates confuse 'potentially releasable' with 'released' and confuse the Increment with the release, so they pick answers that make releasing mandatory or that defer the Increment to the Sprint Review.
What to do instead
Write the definition out: an Increment is the sum of the completed, usable work produced during a Sprint, added to the value of prior Increments, and it must meet the Definition of Done. It is available as soon as work is done, not only at the Sprint Review, and the Product Owner decides when to release. Practice distinguishing 'must be releasable' from 'must be released'.
Treating the Sprint Goal as a fixed list of Sprint Backlog items or as optional, and answering that scope may not change during a Sprint at all.
Candidates learn 'no changes during a Sprint' as a slogan and miss the nuance that scope may be clarified and renegotiated with the Product Owner as more is learned, while the Sprint Goal is the fixed commitment.
What to do instead
Learn the Sprint Goal as a single objective for the Sprint, a commitment of the Sprint Backlog, created during Sprint Planning, and the thing that gives the Developers flexibility on the exact work. In scenario questions ask 'what must stay stable?' (the Goal, quality) versus 'what can change?' (scope detail, technique, how the work is done).
Answering that the Product Owner writes all Product Backlog items alone, or that anyone can reorder the Product Backlog, instead of recognizing the Product Owner may delegate but remains accountable for effective Product Backlog management and ordering.
Candidates mix up accountability with doing the work, and they over-apply self-management to product decisions that belong to one person.
What to do instead
Separate the concepts: the Product Owner is one person, accountable for maximizing value and for effective Product Backlog management, may delegate the work but not the accountability, and is the only one who orders the backlog. The Developers self-manage how to build, not what to build. Sort every scenario answer by whether it is a 'what/why' decision or a 'how' decision.
Treating technical practices such as test-driven development, continuous integration, refactoring, pair programming, or automated testing as mandated by Scrum, or conversely as irrelevant to Scrum.
Candidates either look for a Scrum rule that prescribes engineering practices (there isn't one) or dismiss practices as outside the framework, missing that Scrum is a lightweight framework that requires the team to choose and apply practices that make the Increment truly done.
What to do instead
Learn the framing: Scrum does not prescribe specific engineering practices, but the Definition of Done and the requirement for a usable Increment create the need for practices like CI, automated tests, and refactoring. In questions, choose answers that describe the team selecting and improving its own technical practices rather than answers that cite a Scrum rule requiring a named practice.
Answering that a Sprint can be extended, that its timebox is flexible, or that a Sprint may be cancelled by the Scrum Master, and missing the conditions under which only the Product Owner may cancel.
Candidates remember 'Sprints are fixed length' but not the cancellation rule or the one-month maximum, and they assume a manager or Scrum Master can call off work.
What to do instead
Memorize: Sprints are fixed-length events of one month or less, a new Sprint starts immediately after the previous one, and only the Product Owner has the authority to cancel a Sprint, typically when the Sprint Goal becomes obsolete. Note that cancellation is rare and consumes resources, and that a cancelled Sprint's completed items are reviewed and returned to the backlog as needed.
Describing the three Scrum artifacts without their commitments, so the Product Backlog is named without the Product Goal, the Sprint Backlog without the Sprint Goal, and the Increment without the Definition of Done.
Candidates study artifacts and commitments as separate lists and never link them, so questions that ask 'which commitment is attached to which artifact' or that describe a missing commitment in a scenario are missed.
What to do instead
Make a three-row artifact table with a commitment column: Product Backlog to Product Goal, Sprint Backlog to Sprint Goal, Increment to Definition of Done. For each row write what the commitment provides (direction, focus and flexibility, quality). Then drill scenario questions by asking 'which artifact is being described, and is its commitment present or missing?'