Professional Scrum Developer (PSD) Exam Guide
The Professional Scrum Developer certification validates whether you understand how to deliver quality software with Scrum while applying modern Agile and DevOps practices. It is relevant to developers and to other Scrum-Team members who influence 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 emphasis.
What does the PSD certification validate?
PSD validates practical knowledge of delivering quality software with Scrum, not simply familiarity with Scrum vocabulary. The assessed scope connects Scrum principles and team behavior with backlog work, architecture, programming, testing, quality, forecasting, release planning and product value.
The certification is aimed at the development work that turns Product Backlog items into usable outcomes. That includes understanding how a self-managing, cross-functional team collaborates, how quality is built into the Increment, and how technical decisions affect the ability to deliver value.
The official scope includes self-managed development, design and architecture, documentation, programming, quality, testing, forecasting and release planning, and product value. These areas overlap in real work. For example, a feature-slicing decision can affect architecture, testability, technical debt and the team’s forecast at the same time.
The course associated with PSD also addresses 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. Treat these as connected practices rather than isolated glossary entries.
What the certification does not prove
A PSD credential does not by itself prove proficiency in a particular programming language, framework, cloud platform or employer-specific toolchain. The supplied official scope describes knowledge of software development with Scrum and related practices; it does not identify a technology-specific skills test.
It also should not be treated as evidence that memorizing answer banks is enough. Preparation is stronger when you can explain why a development practice supports transparency, inspection, adaptation and a usable Increment in a given situation.
Who should consider PSD?
PSD is relevant to anyone on a Scrum Team who participates in software delivery or makes decisions that affect it. Scrum.org lists architects, analysts, programmers, database developers, testers, managers, IT operations, Scrum Masters and Product Owners among the intended audience for the related course.
Developers may use PSD to organize technical practices around Scrum rather than treating coding, testing and integration as separate activities. Testers can use it to examine how quality and the Definition of Done shape development work. Architects and operations professionals can connect design and deployment concerns to incremental product delivery.
The certification can also suit a Scrum Master or Product Owner who needs a better understanding of the development work behind a forecast or release discussion. That does not mean every role should study in the same way. A programmer may need more deliberate revision of product value and forecasting, while a Product Owner may need more hands-on attention to technical quality and testing concepts.
The official information does not state a prerequisite involving a job title, programming language or previous certification. Attendance at the Applying Professional Scrum for Software Development course is not required to take the PSD assessment, although Scrum.org highly recommends the course.
Choose self-study or training deliberately
Self-study may be a sensible route if you already work in a Scrum development environment and can connect the terminology to actual backlog, quality and delivery decisions. A course is worth stronger consideration if your experience is mostly theoretical, your team does not use Scrum consistently, or you want structured hands-on practice with other Scrum-Team members.
The course uses hands-on Scrum-Team work over multiple Sprints, including creating code on a realistic software system. That experience can expose gaps that reading alone may leave hidden, particularly around feature slicing, collaboration, quality and the relationship between a Definition of Done and an Increment.
How is the PSD assessment weighted?
Use the blueprint to allocate study time, but do not ignore the smaller Scrum foundation. Approximately 85% of PSD questions come from professional product-development focus areas, while approximately 15% cover broader Scrum areas. Each percentage should guide prioritization only; it does not remove the need to understand the full stated scope.
Approximately 85% of PSD questions come from the professional product-development focus areas of backlog refinement, cross-functional development, architecture, programming, quality and testing. This is the main preparation center of gravity. Study how these areas work together in a Scrum context rather than revising programming techniques as if the assessment were a language exam.
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. This domain is smaller, but misunderstandings here can distort how you interpret development scenarios.
The official information provides these approximate groupings, not a promise that every preparation session or practice exercise will reproduce the same distribution. Use them to sequence revision: establish Scrum fundamentals, spend most of your time on professional development topics, then return to the full scope for integration and review.
Turn the blueprint into a study matrix
Create a matrix with one row for each major topic and three columns: definition, practical application and likely confusion. For “Definition of Done,” write what it means, how a team uses it to judge the Increment, and which tempting shortcut would weaken transparency or quality. For “feature slicing,” record how to seek a valuable, testable slice rather than merely splitting technical tasks.
Repeat the exercise for architecture, technical debt, programming, testing, forecasting, release planning and product value. The goal is not to produce elaborate notes. It is to reveal topics where you can repeat a term but cannot yet explain a decision. Those weak rows should determine your next study block.
What should you study first?
Start with the Scrum foundation and the meaning of a Done, usable Increment, then move into the development practices that make that Increment possible. This sequence prevents a common error: studying technical methods as standalone techniques without understanding how they support inspection, adaptation and value delivery.
First, review Scrum’s accountabilities, events, artifacts, commitments, empiricism and Values. Pay particular attention to the Scrum Team as a self-managing and cross-functional group, because many development questions depend on who collaborates, who decides and how work becomes transparent.
Next, study the Definition of Done and quality. Ask whether a proposed practice creates a usable Increment or merely produces work that someone hopes to finish later. Connect quality to testing, code quality, technical debt, integration and the team’s ability to forecast.
Then study Product Backlog management and feature slicing. Practice distinguishing a valuable slice from a collection of implementation tasks. Consider acceptance expectations, dependencies, learning, architecture and testability without turning refinement into a promise that every detail will be known in advance.
After that, cover architecture, programming and collaborative development practices. Review how an agile architecture can evolve while supporting current delivery, how technical debt affects future options, and how practices such as test-driven development and pair programming may contribute to feedback and shared ownership.
Finish the main pass with agile testing, DevOps with Scrum, forecasting, release planning and product value. These topics belong together: a team cannot make a credible delivery conversation by separating quality, deployment readiness, technical uncertainty and the value of the product.
A useful question for every topic
For each topic, ask four questions: What problem is this practice addressing? What becomes transparent? What feedback does the team inspect? What can the team adapt? This is a study method, not an additional official requirement, but it helps connect technical activities to Scrum’s empirical approach.
For example, when reviewing automated testing, do not stop at a definition. Ask how tests provide feedback, how the Definition of Done treats quality, and what happens to the forecast when unresolved defects remain. When reviewing architecture, ask how design choices support the next valuable Increment without pretending that all future requirements are known.
How should you prepare without the course?
Independent candidates should replace classroom interaction with deliberate application. Read the official assessment scope, work through Scrum development scenarios, and explain your reasoning in writing. If possible, review your answers with developers, testers, architects or Scrum practitioners who can challenge assumptions.
Use a three-pass method. In the first pass, build a vocabulary and scope map from the official topics. In the second, apply each idea to a small product example: slice a feature, define quality, identify technical debt and decide what evidence supports a forecast. In the third, revisit only the areas where your explanation is vague or internally inconsistent.
A useful exercise is to take one hypothetical Product Backlog item and follow it through development. Describe how the team might refine and slice it, what architecture concerns could arise, how programmers and testers collaborate, which quality checks are required by the Definition of Done, and what information a forecast or release discussion would need. Keep the exercise focused on reasoning rather than inventing a supposedly authentic exam question.
Do not rely on dumps, leaked questions or memorized answer patterns. They cannot establish that you understand why an option is consistent with Scrum, and they create a particular risk with multiple-answer questions: remembering one attractive phrase is not the same as evaluating every statement.
Use the official course topics as a coverage check even if you do not attend training. The course’s listed subjects provide a practical reminder to include feature slicing, technical debt, agile architecture, test-driven development, pair programming, agile testing and DevOps rather than studying only the Scrum framework.
How should you prepare if you attend APS-SD training?
Treat the Applying Professional Scrum for Software Development course as practice time, not as a substitute for personal review. Arrive with questions about your weakest development topics, participate in the Scrum-Team work, and record the reasoning behind decisions rather than copying terminology.
The course is generally delivered over three consecutive days in person, while live virtual classes may be split into shorter days. Delivery details can therefore vary by class format. Scrum.org states that a free PSD I exam attempt is included with the course, so confirm the current arrangements with the course provider when scheduling.
After training, reconstruct the learning flow from memory: how the team handled backlog work, how it created code over multiple Sprints, how quality was assessed and where uncertainty affected planning. Then compare your notes with the official assessment scope. This exposes gaps more effectively than rereading every slide in the same order.
What are the PSD assessment format and requirements?
The PSD assessment has 80 questions, a 60-minute time limit, and multiple-choice, multiple-answer and true/false formats. A passing score is 85%. Plan for careful reading and disciplined pacing, especially when a question asks you to select all applicable statements rather than one best-looking option.
The assessment costs $200 USD per attempt according to the official certification page. Attendance at the Applying Professional Scrum for Software Development course is not a prerequisite. The course is highly recommended by Scrum.org, but candidates may choose independent preparation instead.
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 before scheduling in case the current instructions or supported arrangements change.
The certification includes a free Credly digital credential and does not require an annual renewal fee. Those are credential-maintenance details, not preparation shortcuts; your immediate decision remains whether your knowledge and timing justify an attempt.
Make a pacing plan before the attempt
A 60-minute limit for 80 questions means you should avoid allowing one uncertain item to consume the time needed for several answerable items. The official format supplies the fixed facts; your pacing method is a practical recommendation. Read the complete question, identify whether it asks for one or multiple answers, and mark uncertainty rather than spiraling.
For multiple-answer items, assess each option independently against the scenario and Scrum principles. Do not assume that two plausible options mean both are correct, and do not select an option merely because it describes a familiar technical practice. The question is whether the statement fits the Scrum development context presented.
For true/false items, look for absolute wording and hidden changes in scope, but do not reject a statement solely because it sounds concise. Test it against the official concepts and the exact conditions in the question. Reserve final review for marked items after you have addressed the rest.
Which mistakes most often weaken preparation?
The most damaging mistakes are usually conceptual rather than technical: treating Scrum as a sequence of handoffs, confusing activity with value, postponing quality, and assuming that a developer’s specialization removes the need for cross-functional collaboration. Correct these patterns before spending more time on terminology.
Mistake one is studying only coding. PSD includes programming, but the official scope also covers backlog management, architecture, quality, testing, forecasting, release planning and product value. A strong programmer who cannot explain how development work fits a self-managing Scrum Team still has a significant preparation gap.
Mistake two is treating the Definition of Done as optional documentation. Study it as a shared quality threshold for the Increment. When reviewing a scenario, ask whether the proposed outcome satisfies the team’s agreed standard or merely moves incomplete work toward a later stage.
Mistake three is confusing a technical task list with a valuable Product Backlog slice. A slice should help the team and stakeholders inspect a meaningful outcome. A vertical slice may involve several technical skills; splitting work by component does not automatically make it independently valuable.
Mistake four is assuming that architecture must be completed before iterative development begins. The relevant preparation question is how design and architecture support incremental delivery, learning and maintainability. Avoid simplistic extremes such as “design everything first” or “architecture never matters.”
Mistake five is equating DevOps with a tool or a deployment department. Study how development, quality, operations and feedback can support delivering and learning about usable software with Scrum. The official course topic is DevOps with Scrum, not a product-specific tool examination.
Mistake six is ignoring broader Scrum because it represents approximately 15% of PSD questions. The broader Scrum domain includes empiricism, Scrum Values, the Scrum Team, events, artifacts, Done, self-managing teams, facilitation, coaching, forecasting, product value and stakeholders. Keep this domain in your review plan.
Mistake seven is using unsupported certainty in scenario reasoning. If a question gives limited information, do not invent organizational policies, technical constraints or role permissions. Base your choice on the facts presented and the Scrum concepts that apply.
How can you build a practical study roadmap?
A four-stage roadmap works well when you have enough time for more than a last-minute review: establish the framework, map development practices, apply the ideas to integrated scenarios, and perform a focused final check. Adjust the calendar to your experience; the sequence matters more than an invented number of study hours.
Stage one is scope discovery. Read the official PSD certification information and list every stated area, including the broader Scrum topics. Mark each topic as familiar, partly understood or unfamiliar. Do not start with the topics you enjoy most; start by identifying what the assessment can actually cover.
Stage two is development depth. Work through backlog refinement and feature slicing, cross-functional development, architecture, programming, quality and testing. For each area, write one explanation of its purpose, one example of how it affects an Increment, and one failure mode. Include the course topics of technical debt, test-driven development, pair programming and DevOps with Scrum.
Stage three is integration. Use a single product example and examine it from several perspectives. What does the Product Owner need to learn? What must the developers make transparent? How does the team know the work is Done? What technical risk could affect future delivery? What evidence would support a forecast? This stage is especially useful for candidates whose experience has been limited to one specialist role.
Stage four is assessment readiness. Review the format, passing score and language information from the official page. Practice reading carefully across multiple-choice, multiple-answer and true/false formats without treating unofficial practice material as a source of live exam content. Revisit your weak-topic matrix and stop expanding notes when you can consistently explain the underlying decisions.
On the final review day, use short prompts rather than broad rereading. Define the purpose of the Definition of Done. Explain the difference between a valuable slice and a technical task split. Describe how quality and testing affect an Increment. Explain how a self-managing, cross-functional team handles development work. Then review the official assessment page for current instructions before you schedule or begin the attempt.
A sample weekly structure
If your preparation is spread across several weeks, assign the first study block to Scrum foundations and the second to backlog management, slicing and product value. Use the next blocks for architecture, programming, quality and testing, then reserve a separate block for forecasting, release planning, DevOps with Scrum and broader Scrum review.
At the end of each block, produce an artifact that tests understanding: a decision table, a worked feature slice, a Definition of Done analysis or a short explanation of how a quality problem changes the team’s options. If you cannot create the artifact without copying language, return to the source material.
Keep one session for mixed review. Real development decisions cross topic boundaries, so a schedule that studies each subject only once in isolation may leave you unprepared to connect them. The mixed session should target your error log, not repeat your strongest topics.
How do you decide when to schedule the assessment?
Schedule when you can explain the assessed concepts in unfamiliar combinations and can read all stated question types without rushing. Do not use the absence of a formal course prerequisite as evidence that you are ready; it only means course attendance is not required.
Before scheduling, confirm three practical points from the official source: the current assessment instructions, the listed English-language arrangement and the current attempt cost. The supplied official information states a cost of $200 USD per attempt, but candidates should still verify live details on Scrum.org before purchase.
If you are taking the course, use the included free PSD I exam attempt as part of your planning and ask the provider how it is administered. The course’s hands-on format may also help you judge readiness: if you could participate in multiple-Sprint development work but cannot explain the quality or product-value decisions involved, continue studying those connections.
If English is not your strongest assessment language, review the Google Translate Plugin information on the official page before the attempt and make sure you understand the permitted setup. Do not assume that translation support removes the need to interpret Scrum and software-development terminology precisely.
Set a clear postponement rule. If your error log shows repeated confusion about the Definition of Done, feature slicing, quality or broader Scrum concepts, postpone rather than hoping favorable questions will compensate. The official passing score is 85%, so preparation should focus on reliable understanding rather than barely recognizing familiar terms.
What should you do after reviewing this guide?
Your next action is to compare the official PSD scope with your actual experience, then choose a preparation route. Read the assessment page, decide whether hands-on APS-SD training would address your gaps, and build a topic matrix before spending money on an attempt or study material.
If you choose self-study, begin with Scrum foundations and the Definition of Done, then move through backlog refinement and feature slicing, architecture, programming, quality, testing, forecasting, release planning and product value. Use the broader Scrum domain as a recurring review thread rather than leaving it to the end.
If you choose training, verify the provider, delivery format and current course arrangements. Participate fully in the hands-on Scrum-Team work and use the included PSD I attempt information when planning, while still checking current details with the provider.
Finally, treat the credential as the result of demonstrated knowledge, not as the purpose of preparation. The most durable readiness signal is your ability to reason about how a self-managing, cross-functional team creates a quality Increment, learns from feedback and makes product-development decisions with Scrum.
Conclusion
PSD preparation is most effective when it combines Scrum understanding with software-delivery reasoning. Give the largest share of your effort to the professional product-development domain, but keep the broader Scrum concepts active throughout your review. Confirm current assessment instructions on Scrum.org, choose self-study or APS-SD training based on your experience, and schedule only when you can explain the decisions behind quality, value, slicing, architecture and delivery.
