Professional Scrum Developer (PSD) Exam Guide
The Professional Scrum Developer certification validates whether you understand how to deliver quality software with Scrum, including modern Agile and DevOps practices. It is relevant to developers and to other Scrum-Team members who contribute to software delivery, from testers and architects to Product Owners and Scrum Masters. This guide helps you decide whether self-study is sufficient, whether the Applying Professional Scrum for Software Development course fits your needs, and how to organize preparation around the assessment’s product-development focus rather than memorizing isolated Scrum terms.
What does the PSD certification validate?
PSD tests applied knowledge of delivering quality software with Scrum. The subject is broader than programming syntax: it includes how a self-managing development group works with the Product Backlog, creates a usable Increment, handles quality, and makes technical decisions while pursuing product value.
The assessment covers self-managed development, design and architecture, documentation, programming, quality, testing, forecasting and release planning, and product value. These areas connect technical work to Scrum’s empirical approach. A candidate should therefore be able to explain not only how a team builds software, but also why a particular way of working supports transparency, inspection and adaptation.
The certification is a useful fit for someone who participates in software delivery and needs a shared model for building, testing and releasing valuable Increments. It is not presented by Scrum.org as a narrow programming examination. The official course audience includes architects, analysts, programmers, database developers, testers, managers, IT operations, Scrum Masters and Product Owners.
The practical question to ask before booking
Ask whether you can reason through software-delivery situations using Scrum principles, not merely recite the names of Scrum events or practices. If your experience is mainly in one technical specialty, preparation should deliberately connect that specialty to backlog management, cross-functional collaboration, quality and the Definition of Done.
If you already work in a Scrum Team and regularly discuss slicing, testing, technical debt and release decisions, independent preparation may be realistic. If Scrum is new to you, or if your team uses Scrum vocabulary without consistently applying its accountabilities and quality expectations, the official course may provide a more structured route.
How is the assessment structured?
The PSD assessment contains 80 questions, has a 60-minute time limit, and uses multiple-choice, multiple-answer and true/false questions. The passing score is 85%. Those constraints make precise reading and disciplined pacing important preparation targets, alongside subject knowledge.
The assessment is listed as English-language. Scrum.org says candidates may use the Google Translate Plugin for another language. Check the official assessment page for the applicable instructions before scheduling, particularly if language support will affect how you plan your reading time.
The listed cost is $200 USD per attempt. Treat the fee as a scheduling consideration rather than a reason to rush. A sensible decision point is whether you can explain the main product-development topics without relying on answer memorization or unofficial question collections.
What the question formats require
A multiple-choice item generally asks you to select one response, while a multiple-answer item requires you to identify all options that satisfy the wording. True/false questions can be deceptively demanding because a single qualification may change the correctness of a statement.
Read for scope words such as best, primarily, must, can and not. For multiple-answer questions, evaluate each option independently against Scrum and software-development principles. Do not assume that an option is correct merely because it describes a useful engineering practice; it must also fit the situation and the Scrum context described.
Which subjects deserve the most study time?
Approximately 85% of PSD questions come from professional product-development focus areas, including backlog refinement, cross-functional development, architecture, programming, quality and testing. Allocate most of your study effort to these areas, then use broader Scrum knowledge to interpret the situations in which the development work occurs.
Approximately 15% of PSD questions cover broader Scrum areas including empiricism, Scrum Values, the Scrum Team, events, artifacts, Done, self-managing teams, facilitation, coaching, forecasting, product value and stakeholders. The percentage describes the assessment emphasis; it does not make these subjects optional, because they shape how product-development decisions are understood.
Build a topic map instead of a vocabulary list
Create two study columns. In the first, place product-development topics: refinement and feature slicing, architecture, programming, documentation, code quality, technical debt, testing and DevOps. In the second, place the broader Scrum concepts that govern those activities: empiricism, the Scrum Team, events, artifacts, the Definition of Done, forecasting, product value and stakeholders.
For each topic, write three short answers: what problem the practice addresses, how it supports a usable Increment, and what mistake would undermine transparency or quality. This forces you to connect concepts instead of memorizing definitions in isolation.
Use the official course topic list as a checklist. It includes the Definition of Done, backlog management and feature slicing, code quality and technical debt, agile architecture, test-driven development, pair programming, agile testing and DevOps with Scrum.
Should you take the official course?
Attending the Applying Professional Scrum for Software Development course is not a prerequisite for the PSD assessment, although Scrum.org highly recommends the course. The course is most compelling when you need guided practice applying Scrum to software work, rather than only reading about the framework.
The course is generally delivered over three consecutive days in person, while live virtual classes may be split into shorter days. A free PSD I exam attempt is included with the course. Verify the provider’s current schedule and course terms before registering, because delivery arrangements can differ.
What the course adds to preparation
The course uses hands-on Scrum-Team work over multiple Sprints, including creating code on a realistic software system. That format can expose gaps that reading alone may hide: oversized features, unclear quality criteria, late testing, weak collaboration between specialists, or architecture decisions that delay usable value.
Choose the course when you would benefit from instructor feedback, team-based exercises or a realistic setting for connecting engineering practices to Scrum. Self-study may be more efficient when you already have substantial software-delivery experience and can review the official topics critically with colleagues.
The former Professional Scrum Developer training was renamed Applying Professional Scrum for Software Development on January 10, 2021. When searching for training, use the current course name and confirm that the class is the Scrum.org offering associated with PSD preparation.
How should you prepare without relying on dumps?
Use the official assessment page and course topics to create a study plan, then test yourself with explanations that you write yourself. Unofficial dumps can encourage recognition of memorized wording instead of understanding, and leaked or copied questions are not a sound basis for certification preparation. Passing depends on applying the subject matter to unfamiliar situations.
Start with Scrum’s purpose and quality expectations, then move into the development practices that make an Increment usable. Finish by combining technical and Scrum decisions in scenario exercises. This sequence reduces a common error: learning engineering techniques as disconnected tools without understanding their relationship to product value and empirical planning.
A four-pass study method
Pass one is orientation. Read the official PSD certification description and list every stated coverage area. Mark each topic as familiar, partly familiar or unfamiliar. Do not estimate readiness from how recognizable a term sounds; familiarity with a label is not the same as being able to choose an appropriate action.
Pass two is concept building. Study one cluster at a time: Scrum foundations; backlog and slicing; self-managed, cross-functional development; architecture and documentation; programming and collaboration; quality and testing; forecasting, release planning and product value. After each cluster, explain how it contributes to a usable Increment.
Pass three is application. Take a hypothetical backlog item and walk through refinement, slicing, design, implementation, testing, integration and review against the Definition of Done. Identify where technical debt could appear, how quality would remain visible, and what information stakeholders would need for a product decision.
Pass four is assessment rehearsal. Practice reading mixed question types under a strict time limit. Review every uncertain answer, including correct guesses. Record the principle that resolved each item and the distractor that initially seemed attractive. This produces a targeted final-review list instead of another unfocused reading cycle.
What should you study in the development-focused domains?
Study the product-development domains as connected decisions. Backlog refinement affects the size and clarity of work; architecture and design influence the ability to deliver; programming and collaboration turn an item into a product Increment; testing and quality provide evidence that the result is usable. Treating these as separate silos misses the central PSD concern: delivering quality software with Scrum.
Backlog management and feature slicing
Practice turning a broad feature into smaller pieces that can produce meaningful value and be completed to the Definition of Done. A technically convenient task split is not automatically a valuable slice. Ask whether each slice can be understood, built, tested and inspected without leaving essential quality work for an undefined later stage.
Review how refinement supports a shared understanding of Product Backlog Items. Look for ambiguity in acceptance expectations, dependencies, data needs and non-functional concerns. Avoid the pitfall of treating refinement as a separate approval gate or as a promise that every future detail must be specified before development begins.
Architecture, design and documentation
Prepare to reason about architecture as an enabler of incremental product development. Consider which design information the team needs now, what can be learned through implementation, and how documentation preserves useful transparency without becoming an excuse to delay a usable Increment.
A common mistake is to present architecture as the exclusive responsibility of one specialist. The course topics include agile architecture, and the assessment covers cross-functional product development. Study how the team can collaborate on technical choices while retaining enough design clarity to build, test and adapt the product.
Programming, code quality and technical debt
Connect programming practices to the Definition of Done and product quality. Code that compiles but has inadequate tests, unresolved defects or unacceptable maintainability concerns is not automatically a quality Increment. Review how code quality is made visible and how technical debt can affect future delivery and product value.
Pair programming appears among the official course topics. Study it as a collaborative development practice rather than a universal rule. In a scenario, consider the problem being addressed, the team’s ability to maintain quality, and whether the proposed practice helps create a Done Increment.
Testing, test-driven development and DevOps
Study testing as part of development rather than a final inspection step. Test-driven development, agile testing and DevOps with Scrum are official course topics, so prepare to explain how feedback, automation, integration and deployment practices can support frequent inspection and a usable Increment.
Do not assume that adopting a named tool or pipeline automatically makes a team Agile. A strong answer will relate the practice to quality, transparency, feedback and product delivery. When reviewing a scenario, ask what evidence exists that the Increment meets the Definition of Done and whether technical work is being hidden outside the Product Backlog.
How do broader Scrum topics affect PSD answers?
The broader Scrum portion is smaller but foundational. Empiricism, Scrum Values, accountabilities, events, artifacts, the Definition of Done, self-management, facilitation, coaching, forecasting, product value and stakeholders provide the context for technical choices. A technically attractive answer can still be wrong if it bypasses transparency, weakens self-management or separates quality from the Increment.
Review the Scrum Team’s responsibility for creating a valuable, usable Increment and understand how collaboration supports that responsibility. Revisit what the Product Backlog, Sprint Backlog and Increment make transparent, and distinguish forecasting from a guarantee. Product decisions should be connected to value and evidence, not presented as certainty unsupported by inspection.
Use scenario prompts to test the connection. For example, if a team discovers that a feature cannot meet its quality expectations within a Sprint, ask what should become transparent, who collaborates on the decision, and how the Product Goal and product value influence the next step. The point is not to invent a procedural shortcut, but to reason from Scrum’s accountabilities and empirical control.
A useful rule for ambiguous options
When two answers sound plausible, prefer the one that preserves transparency, supports self-management, protects the Definition of Done and enables inspection and adaptation. Then check the product context: the best Scrum response should also help the team deliver or learn about valuable software, rather than merely produce activity or documentation.
What four-week roadmap can you follow?
A four-week roadmap works when you study actively and adapt it to your background. The first week establishes Scrum foundations and assessment scope; the second concentrates on backlog and development practices; the third integrates quality, testing and product decisions; the fourth is for timed practice and closing gaps. Extend any phase if you cannot explain the concepts without notes.
Week one: establish the operating model
Read the official PSD assessment description and map its coverage areas. Review empiricism, Scrum Values, the Scrum Team, events, artifacts, the Definition of Done, self-management and product value. Write brief scenario answers rather than copying definitions.
At the end of the week, explain how a Scrum Team makes work and quality transparent, how a usable Increment supports inspection, and why a forecast is different from a promise. If these explanations are unclear, do not move straight to technical techniques; your later answers will lack context.
Week two: work through the development flow
Study backlog management, refinement, feature slicing, cross-functional development, architecture, design, documentation, programming, code quality and technical debt. Use one example Product Backlog Item and repeatedly improve its slice, quality expectations and technical approach.
Discuss the example with a developer, tester or product colleague if possible. Ask what would make the item difficult to complete to the Definition of Done. Record disagreements and resolve them through the official material, not through whichever practice is most familiar in your workplace.
Week three: make quality and value visible
Focus on test-driven development, pair programming, agile testing and DevOps with Scrum. Trace how feedback is generated, how defects and technical debt become visible, and how the team knows whether the Increment is usable.
Add forecasting, release planning, stakeholders and product value to the same exercises. Practice explaining what information supports a release or product decision and what remains uncertain. Avoid turning a forecast into a fixed commitment simply because a date or estimate appears in a scenario.
Week four: rehearse decisions and schedule deliberately
Use mixed practice questions, including multiple-answer and true/false formats, and review your reasoning after every session. Revisit only the topics that produce uncertainty. In the final days, prioritize the Definition of Done, backlog and slicing, quality, testing, self-management and the relationship between technical work and product value.
Schedule when you can read carefully without interruption. Confirm the assessment language and any permitted translation support on the official page. If your preparation relies on memorized answers, postpone the attempt and return to scenario-based study. The $200 USD per attempt cost makes a readiness check worthwhile.
What mistakes commonly weaken preparation?
The most damaging mistakes are not usually lack of technical vocabulary. They are studying only generic Scrum, treating engineering practices as optional add-ons, confusing activity with value, and answering from local team habits instead of the Scrum and PSD context. Correct these patterns by explaining the effect of each decision on quality, transparency and a usable Increment.
Studying only programming
PSD is not limited to writing code. The official coverage includes backlog management, architecture, documentation, quality, testing, forecasting, release planning and product value. A strong programmer can still have gaps in slicing, stakeholder decisions or Scrum accountability. Reserve deliberate study time for the non-coding areas.
Memorizing the Definition of Done
Knowing the phrase is not enough. Apply it to design, implementation, testing, integration, documentation and technical debt. Ask whether the proposed work meets the team’s quality standard and whether anything essential is being deferred while the result is presented as complete.
Treating tools as the answer
Continuous integration, automated tests, pair programming and DevOps practices can support quality, but a tool does not resolve unclear ownership, poor slicing or hidden work. In scenario questions, identify the underlying Scrum and product-development problem before selecting a technique.
Relying on a single role’s viewpoint
The course is intended for varied Scrum-Team members involved in software delivery. Prepare to see a situation from the perspective of development, product value, testing, operations and facilitation. Cross-functional collaboration matters because a Done Increment requires more than one specialty working in isolation.
Ignoring question wording
Candidates can know the topic and still miss an item by overlooking whether it asks for one answer, multiple answers, a necessary condition or a false statement. Slow down at the start of each item, identify the requested decision, and eliminate options that introduce unsupported certainty or bypass Scrum principles.
What should you do on assessment day?
Approach the assessment as a reasoning exercise with a pacing plan. Read each question fully, classify its format, and answer from the Scrum and software-delivery principles you prepared. Mark uncertainty mentally or through the available assessment controls, move on when an item consumes disproportionate attention, and return only if time permits.
A practical pacing approach
Because the assessment has 80 questions and a 60-minute time limit, avoid spending the early part of the attempt debating one ambiguous option. First secure the questions you can answer confidently. For difficult items, identify the relevant domain—such as slicing, quality, testing or self-management—then compare each option with the Definition of Done, transparency and product value.
For multiple-answer items, check every option instead of stopping after finding one plausible response. For true/false items, inspect qualifiers and exceptions. Do not change an answer merely because another option sounds more sophisticated; change it when your review identifies a concrete conflict with the question or the Scrum context.
Language and administrative checks
The official assessment is listed as English-language, with Google Translate Plugin support mentioned by Scrum.org for another language. Review the current official instructions before starting and make sure your planned setup follows them. Assessment delivery details can be subject to official instructions, so do not rely on third-party descriptions.
What happens after certification?
The PSD certification includes a free Credly digital credential and does not require an annual renewal fee. Keep the credential information available after passing, and continue developing the underlying engineering and Scrum habits rather than treating the certificate as a substitute for delivery experience.
If you do not pass on the first attempt, use the result as a diagnostic signal. Rebuild your study plan around the domains that caused uncertainty, especially where your workplace practice differs from Scrum’s empirical and quality-oriented model. Review the official material again before making another attempt; do not respond by memorizing more unofficial questions.
The certification is most useful when it informs how you discuss backlog slices, architecture, code quality, testing, technical debt and product value with a Scrum Team. Those conversations provide a practical test of whether the knowledge has become usable.
Your next actions
First, open the official PSD assessment page and confirm the current assessment information, language guidance and purchase details. Second, compare your experience with the stated coverage areas. Third, choose self-study or the Applying Professional Scrum for Software Development course based on the kind of support you need—not on the assumption that attendance is mandatory.
Finally, create one small study board with the topics you can explain, the topics you can apply, and the topics you still confuse. Work through that board using realistic software-delivery scenarios, then schedule only when your decisions are grounded in quality, transparency, self-management and product value.
Conclusion
PSD preparation is strongest when it mirrors the work the certification describes: connecting backlog decisions, design, programming, testing, quality and product value within a self-managing Scrum Team. Use the official assessment scope to weight your study, use the course when hands-on guidance would close practical gaps, and use scenario reasoning instead of memorized answers. Before scheduling, verify the official details and make sure you can explain how a team creates a usable Increment—not simply define the practices associated with it.
