[Scrum] PSM I - Professional Scrum Master I Exam Dumps & Study Guide
The Professional Scrum Master I (PSM I) is the premier certification for anyone looking to demonstrate their fundamental knowledge of the Scrum framework and its application. Developed by Scrum.org, the PSM I validates your understanding of the roles, events, artifacts, and the rules of Scrum as described in the Scrum Guide. As organizations across all industries adopt agile methodologies to improve efficiency and deliver value faster, the demand for skilled Scrum Masters has never been greater. The PSM I is an essential credential for anyone aspiring to lead agile teams and foster a culture of continuous improvement.
Overview of the Exam
The PSM I exam is a rigorous assessment that covers the core principles and practices of Scrum. It is a 60-minute exam consisting of 80 multiple-choice, multiple-select, and true/false questions. The exam is designed to test your knowledge of the Scrum framework and your ability to apply it to real-world scenarios. Unlike some other certifications, the PSM I requires a high passing score (85%), ensuring that those who achieve the certification have a deep and consistent understanding of Scrum. Achieving the PSM I proves that you are a highly skilled professional capable of serving as a Scrum Master and helping teams thrive in an agile environment.
Target Audience
The PSM I is intended for anyone who wants to deepen their knowledge of Scrum. it is ideal for individuals in roles such as:
1. Aspiring Scrum Masters
2. Team Leads and Project Managers
3. Software Developers and QA Testers
4. Product Owners
5. Agile Coaches
6. IT Managers
The PSM I is for those who are committed to mastering the Scrum framework and helping their organizations achieve agility.
Key Topics Covered
The PSM I exam is organized around several key focus areas:
1. Understanding and Applying the Scrum Framework: Roles, events, artifacts, and the rules of Scrum.
2. Developing People and Teams: Understanding self-management, cross-functionality, and the Scrum Master's role as a servant leader.
3. Managing Products with Agility: Understanding the Product Owner's role, the Product Backlog, and delivering value.
4. Developing and Delivering Products Professionally: Understanding the Importance of the "Definition of Done" and managing technical debt.
5. Evolving the Agile Organization: Understanding the Scrum Master's role in helping the broader organization adopt Scrum.
Benefits of Getting Certified
Earning the PSM I certification provides several significant benefits. First, it offers industry recognition of your fundamental expertise in Scrum. As the world’s most popular agile framework, Scrum skills are in high demand across the globe. Second, it can lead to increased career opportunities and higher salary potential in a variety of roles. Third, it demonstrates your commitment to professional excellence and your dedication to staying current with the latest agile practices. By holding this certification, you join a global community of Scrum professionals and gain the confidence to lead agile transformations within your organization.
Why Choose NotJustExam.com for Your PSM I Prep?
The PSM I exam is challenging and requires a deep understanding of the nuances of the Scrum Guide. NotJustExam.com is the best resource to help you master this material. Our platform offers an extensive bank of practice questions that are designed to mirror the actual exam’s format and difficulty.
What makes NotJustExam.com stand out is our focus on interactive logic and the accuracy of our explanations. We don’t just provide a list of questions; we provide a high-quality learning experience. Every question in our bank includes an in-depth, accurate explanation that helps you understand the reasoning behind the correct Scrum application. This ensures that you are truly learning the material and building the confidence needed to succeed on the exam. Our content is regularly updated to reflect the latest changes to the Scrum Guide and exam updates. With NotJustExam.com, you can approach your PSM I exam with the assurance that comes from thorough, high-quality preparation. Start your journey toward becoming a Professional Scrum Master today with us!
Free [Scrum] PSM I - Professional Scrum Master I Practice Questions Preview
-
Question 1
When many Scrum Teams are working on the same product, should all of their Increments be integrated every Sprint?
- A. Yes, but only for Scrum Teams whose work has dependencies.
- B. Yes, otherwise the Product Owners (and stakeholders) may not be able to accurately inspect what is done.
- C. No, each Scrum Team stands alone.
- D. No, that is far too hard and must be done in a hardening Sprint.
Correct Answer:
B
Explanation:
Based on the Scrum Guide and the discussion, the AI agrees with the suggested answer B.
Reasoning:
Integrating all increments every Sprint is crucial when multiple Scrum Teams are working on the same product. This integration allows the Product Owner and stakeholders to inspect the complete, integrated Increment and provide valuable feedback. Without integration, it becomes difficult to assess the overall progress and identify potential issues or conflicts early in the development cycle. The Scrum Guide emphasizes the importance of a "Done" Increment at the end of each Sprint, and for multiple teams, this implies integrated work.
Reasons for not choosing other answers:
-
A: While dependency management is important, limiting integration only to teams with dependencies defeats the purpose of having a fully integrated Increment for inspection and adaptation. The Scrum Guide does not suggest conditional integration based on dependencies.
-
C: This option contradicts the fundamental principles of Scrum, especially when multiple teams are working on the same product. Scrum emphasizes collaboration and integration to deliver a cohesive product.
-
D: A "hardening Sprint" is an anti-pattern. The Scrum Guide advocates for delivering a usable Increment every Sprint. Delaying integration to a separate "hardening Sprint" introduces unnecessary risk and delays feedback.
In conclusion, integrating all increments every Sprint is essential for transparency, inspection, and adaptation when multiple Scrum Teams are working on the same product.
Citations:
- The Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 2
When can a Development Team cancel a Sprint?
- A. It can't. Only Product Owners can cancel Sprints.
- B. When functional expectations are not well understood.
- C. When the Product Owner is absent too often.
- D. When the selected Product Backlog items for the Sprint become unachievable.
- E. When a technical dependency cannot be resolved.
Correct Answer:
A
Explanation:
The AI agrees with the suggested answer of A: It can't. Only Product Owners can cancel Sprints.
Reasoning: The Scrum Guide clearly states that the Product Owner is the only one who has the authority to cancel a Sprint. This decision is made in consultation with the Development Team and Stakeholders, but the final call rests with the Product Owner. A Sprint is cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market conditions change.
Reasons for not choosing the other answers:
- B: When functional expectations are not well understood. This is a situation that the Development Team should address during Sprint Planning and Daily Scrums. It does not warrant a Sprint cancellation.
- C: When the Product Owner is absent too often. While the Product Owner's presence is crucial, their absence doesn't automatically lead to Sprint cancellation. The Scrum Team should find ways to mitigate the impact of the Product Owner's absence.
- D: When the selected Product Backlog items for the Sprint become unachievable. If the Development Team realizes during the Sprint that they cannot complete all the selected items, they should work with the Product Owner to adjust the Sprint Backlog. Cancelling the Sprint is not the first course of action.
- E: When a technical dependency cannot be resolved. The Development Team is responsible for resolving technical dependencies. If a dependency proves to be a major impediment, the Scrum Team should address it during the Daily Scrum and work towards a solution. Again, this does not automatically lead to Sprint cancellation.
- Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 3
Which output from Sprint Planning provides the Development Team with a target and overarching direction for the Sprint?
- A. The Sprint Backlog.
- B. The Sprint Goal
- C. The release plan.
- D. Sprint Review minutes.
Correct Answer:
B
Explanation:
The suggested answer is correct. The recommended answer is B, the Sprint Goal.
The Sprint Goal provides the Development Team with a clear objective and direction for the Sprint. It acts as a target that the Development Team strives to achieve during the Sprint, guiding their work and decision-making. The Sprint Goal is crafted during Sprint Planning, ensuring alignment between the Product Owner, Scrum Master, and Development Team. According to the Scrum Guide, the Sprint Goal is a single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact implementation.
Here's why the other options are incorrect:
- A. The Sprint Backlog: The Sprint Backlog is a plan created *by* and *for* the Developers. It contains the selected Product Backlog items and a plan for delivering the Sprint Goal. While it's crucial for execution, it's derived from and supports the Sprint Goal, not the other way around.
- C. The Release Plan: The Release Plan (if one exists) is a longer-term forecast, typically spanning multiple Sprints. It doesn't provide the immediate, Sprint-specific direction the question asks about.
- D. Sprint Review Minutes: The Sprint Review is held *after* the Sprint is complete. The minutes document the outcomes and feedback from the review, but they don't provide direction *during* the Sprint.
- Scrum.org, The Scrum Guide, https://scrumguides.org/scrum-guide.html
- Scrum Forum, Sprint Planning, https://www.scrum.org/forum/scrum-forum/5606/sprint-planning#:~:text=A%20Sprint%20Goal%20should%20set,of%20a%20Sprint%20Planning%20session
-
Question 4
How should a Development Team deal with non-functional requirements?
- A. Ensure every Increment meets them.
- B. Make sure the release department understands these requirements, but it is not the Development Team's responsibility.
- C. Handle them during the Integration Sprint preceding the Release Sprint.
- D. Assign them to the lead developers on the team.
Correct Answer:
A
Explanation:
The AI agrees with the suggested answer.
Suggested Answer: A.
Reasoning: Non-functional requirements are crucial for the overall quality and usability of the product. They are as important as functional requirements. According to the Scrum Guide, the Development Team is responsible for delivering a "Done" Increment at each Sprint. "Done" means that the Increment meets the Definition of Done, which includes both functional and non-functional requirements. Ensuring that every Increment meets the non-functional requirements helps to manage risk, ensures quality, and delivers value continuously.
Reasons for not choosing other options:
- B: It is the Development Team's responsibility to ensure the non-functional requirements are met. The release department might be involved in verifying these requirements, but the primary responsibility lies with the Development Team.
- C: Handling non-functional requirements only during the Integration Sprint is too late. It can lead to significant rework if the requirements are not met. Non-functional requirements should be considered throughout the development process.
- D: Assigning non-functional requirements only to lead developers is not a good practice. The entire Development Team is responsible for ensuring that the Increment meets the Definition of Done, which includes non-functional requirements.
The Scrum Guide states:
"The purpose of each Sprint is to deliver Increments of working product that uphold integrity to meet the Scrum Team’s current Definition of Done."
- Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 5
- A. When the Product Owner says it is done.
- B. When all Product Backlog items meet their definition of ג€Doneג€.
- C. When all the tasks are completed.
- D. When the time-box expires.
Correct Answer:
D
Explanation:
The suggested answer D is correct.
The Sprint is over when the time-box expires. This is a fundamental principle of Scrum, ensuring that the team delivers value within a predictable and consistent cadence.
Here's a detailed reasoning:
- Time-boxing: Scrum utilizes time-boxing for all events, including the Sprint. A Sprint has a fixed duration (typically 1-4 weeks), and it ends precisely when that time is up, regardless of how much work has been completed.
- Predictability: Time-boxing provides predictability and allows the team to plan and deliver consistently.
- Focus: It forces the team to focus on delivering the most valuable increments within the given timeframe.
- Inspection and Adaptation: Ending the Sprint on time allows for regular inspection (Sprint Review) and adaptation (Sprint Retrospective), which are crucial for continuous improvement.
Why the other options are incorrect:
- A. When the Product Owner says it is done: The Product Owner defines what "done" means for Product Backlog Items, but they do not decide when the Sprint ends. The Sprint ends based on the agreed-upon time-box.
- B. When all Product Backlog items meet their definition of “Done”: While the goal is to complete Sprint Backlog items to "Done," it's not a requirement for the Sprint to end. The Sprint ends even if not all items are "Done." The unfinished items will be re-evaluated and potentially re-prioritized for future Sprints.
- C. When all the tasks are completed: Tasks are a decomposition of Sprint Backlog items and are used for planning and tracking progress within the Development Team. The completion of tasks doesn't dictate the end of the Sprint; the time-box does.
Citations:
- In Scrum, When Is a Sprint Over?, https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/#:~:text=The%20short%20and%20simple%20answer,%2C%20one%20week%2C
-
Question 6
True or False: Scrum has a role called `Project Manager`.
Correct Answer:
B
Explanation:
The AI recommends answer B, False.
The suggested answer aligns with the principles of Scrum, which does not formally recognize the role of 'Project Manager.' Instead, Scrum utilizes roles like Scrum Master, Product Owner, and Development Team members. The Scrum Master is a servant-leader who helps the Scrum Team follow Scrum theory, practices, and rules. The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team, and the Development Team consists of professionals who deliver the potentially releasable Increment of "Done" product at the end of each Sprint.
The Project Manager role typically associated with traditional project management methodologies focuses on planning, executing, and closing projects, often with a command-and-control approach which contrasts the self-organizing and cross-functional nature of Scrum teams.
Therefore, Scrum framework replaces the Project Manager role with the Scrum Master, Product Owner and Development Team.
Choosing 'True' would contradict the core tenets of Scrum and its emphasis on self-managing teams.
- Scrum Roles - Scrum Guide, https://scrumguides.org/scrum-guide.html#team
-
Question 7
What are two effective ways for the Scrum Team to make non-functional requirements visible? (Choose two.)
- A. Put them on a separate list on the Scrum board, available for all to see.
- B. Add them to the Product Backlog to ensure transparency.
- C. Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint.
- D. Add them to the definition of ג€Doneג€ so the work is taken care of every Sprint.
Correct Answer:
BD
Explanation:
The AI assistant agrees with the suggested answer, B and D.
Reasoning:
The Scrum Guide emphasizes transparency as a cornerstone of the framework. Non-functional requirements (NFRs), like security, performance, or usability, are crucial for product success. Making these visible ensures the Scrum Team understands and addresses them.
- B: Add them to the Product Backlog to ensure transparency. The Product Backlog is a visible, ordered list of everything that is known to be needed in the product. Including NFRs here ensures they are considered during prioritization, planning, and refinement. This aligns with Scrum's principle of transparency and ensures NFRs are not overlooked.
- D: Add them to the Definition of "Done" so the work is taken care of every Sprint. The Definition of Done (DoD) is a shared understanding of what it means for work to be complete. Integrating NFRs into the DoD ensures that every Increment meets the required quality standards regarding these requirements. For example, including "must pass security scan" in the DoD ensures all increments are assessed for security vulnerabilities. This also aligns with Scrum's principle of transparency and helps the team avoid accruing technical debt related to NFRs.
Reasons for not choosing other options:
- A: Put them on a separate list on the Scrum board, available for all to see. While making NFRs visible is important, a separate list on the Scrum board isn't the most effective approach. The Scrum board is primarily used for visualizing the Sprint Backlog and the flow of work during the Sprint. Creating a separate, ad-hoc list is not aligned with Scrum's emphasis on the Product Backlog and the Definition of Done as key artifacts for managing requirements and quality. Furthermore, the Scrum framework does not define a specific "Scrum board artifact".
- C: Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint. Running tests is a good practice, but this option doesn't guarantee that NFRs are transparently considered *before* and *during* development. It's reactive rather than proactive. Addressing NFRs only through testing after development risks discovering issues late in the Sprint, potentially leading to delays or compromises. It also doesn't inherently make NFRs visible to the entire Scrum Team throughout the entire product development lifecycle.
In summary, options B and D proactively integrate NFRs into core Scrum artifacts (Product Backlog and Definition of Done), ensuring they are visible and addressed throughout the development process, thereby maximizing transparency as advocated by the Scrum Guide.
Suggested Answer: BD
Citations:
- The Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 8
How much time is required after a Sprint to prepare for the next Sprint?
- A. The break between Sprints is time-boxed to 1 week for 30 day Sprints, and usually less for shorter sprints.
- B. Enough time for the requirements for the next Sprint to be determined and documented.
- C. Enough time for the Development team to finish the testing from the last Sprint.
- D. None. A new Sprint starts immediately following the end of the previous Sprint.
- E. All of the above are allowed depending on the situation.
Correct Answer:
D
Explanation:
Based on professional knowledge and the discussion provided, the AI agrees with the suggested answer, which is D: None. A new Sprint starts immediately following the end of the previous Sprint.
The reason for choosing this answer is that the Scrum Guide emphasizes the continuous flow of work in Scrum. Sprints are designed to be consecutive and time-boxed, with a new Sprint starting immediately after the conclusion of the previous one to maintain a consistent rhythm and flow of work.
The reasons for not choosing the other answers are:
- A: This option suggests a break of up to 1 week, which contradicts the Scrum Guide's principle of continuous Sprints.
- B: While defining requirements for the next Sprint is important, it happens during Sprint Planning, not as a break between Sprints. The output of sprint planning is a sprint backlog
- C: Testing should ideally be completed within the Sprint itself, not as a task carried over to a break between Sprints.
- E: This option suggests that any of the above are allowed, which is incorrect as the Scrum Guide clearly states that a new Sprint starts immediately.
- The Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 9
During Sprint Planning the Product Owner and the Developers are unable to reach an understanding about the highest order Product Backlog items. Because of this, the Developers are unable to determine how many Product Backlog items they can forecast for the upcoming Sprint. However, the Product Owner and the
Developers are able to agree on a Sprint Goal.
Which of the following actions should the Scrum Master support? (Choose two.)
- A. Cancel the Sprint. Send the entire team to an advanced Scrum training and then start a new Sprint.
- B. Forecast the Product Backlog items that are most likely to meet the Sprint Goal and create the Sprint Backlog. Conclude Sprint Planning and start the development work. Continue to analyze, decompose, and create additional functionality during the Sprint.
- C. Continue the Sprint Planning event past its timebox until an adequate number of Product Backlog items are well enough understood for the Developers to make a complete forecast. Then start the Sprint.
- D. During the next Sprint Retrospective discuss why this happened and what changes will make it less likely to recur.
- E. Ask everyone to take as much time as needed to analyze the Product Backlog first, and then reconvene another Sprint Planning meeting.
Correct Answer:
BD
Explanation:
Based on the analysis of the question and the discussion, the suggested answer of B and D is correct.
Reasoning:
The scenario describes a situation where the Development Team and Product Owner struggle to refine the Product Backlog during Sprint Planning, impacting their ability to forecast the Sprint Backlog. However, they do agree on a Sprint Goal. The Scrum Master's role is to guide the team to a productive outcome, even in the face of such challenges.
- B. Forecast the Product Backlog items that are most likely to meet the Sprint Goal and create the Sprint Backlog. Conclude Sprint Planning and start the development work. Continue to analyze, decompose, and create additional functionality during the Sprint. This aligns with Agile principles of iterative development and adapting to change. The team can proceed with what's understood and refine the backlog during the Sprint. This is supported by the Scrum Guide which emphasizes iterative refinement and adapting the plan as more information becomes available.
- D. During the next Sprint Retrospective discuss why this happened and what changes will make it less likely to recur. The Sprint Retrospective is the perfect venue to address process improvements and identify the root cause of the challenges faced during Sprint Planning. Addressing this proactively is crucial for continuous improvement.
Reasons for not choosing the other options:
- A. Cancel the Sprint. Send the entire team to an advanced Scrum training and then start a new Sprint. Cancelling the Sprint is a drastic measure and contradicts the Scrum value of courage and commitment to delivering value. Scrum training may be helpful in the long run, but it is not the immediate solution.
- C. Continue the Sprint Planning event past its timebox until an adequate number of Product Backlog items are well enough understood for the Developers to make a complete forecast. Then start the Sprint. Extending the Sprint Planning beyond its timebox violates the Scrum framework and is likely to lead to diminishing returns. Timeboxes are designed to encourage focus and efficiency.
- E. Ask everyone to take as much time as needed to analyze the Product Backlog first, and then reconvene another Sprint Planning meeting. This approach is not time-boxed and lacks a sense of urgency and commitment. It could lead to analysis paralysis and delay the start of the Sprint indefinitely. The Scrum Guide emphasizes time-boxed events to promote efficiency and focus.
Citations:
- The Scrum Guide, https://scrumguides.org/scrum-guide.html
-
Question 10
- A. The Scrum Team.
- B. The Scrum Master.
- C. The Product Owner.
- D. The Stakeholders.
Correct Answer:
C
Explanation:
The suggested answer is C, The Product Owner.
The AI agrees with the suggested answer.
Reasoning: According to the Scrum Guide, the Product Owner is the one who has the authority to cancel the Sprint. The Product Owner may cancel the Sprint if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.
Reasons for not selecting other options:
- A. The Scrum Team: While the Scrum Team collaborates and makes decisions together, the ultimate decision to cancel a Sprint rests with the Product Owner.
- B. The Scrum Master: The Scrum Master facilitates the Scrum process and helps the Scrum Team improve, but does not have the authority to cancel a Sprint.
- D. The Stakeholders: Stakeholders provide input and feedback, but the decision to cancel a Sprint is not theirs.
In summary, the Product Owner is the correct answer because they are accountable for maximizing the value of the product, and cancelling the sprint may be necessary to achieve this goal when the Sprint Goal becomes obsolete.
- The Scrum Guide, https://scrumguides.org/docs/scrumguide/v2020/scrum-guide-us.pdf