Free PSM-1 Practice Test

In Scrum, the traditional role of management shifts from command-and-control to that of a servant-leader and enabler. Management is responsible for fostering an environment where Scrum can succeed. This involves empowering the self-managing Scrum Teams by providing them with the necessary resources, support, and insights. Their primary function is to remove organizational impediments that are beyond the team's capacity to resolve, thereby helping the teams to continuously improve their processes, capabilities, and ability to deliver value.

B. The Development Team is self-managing and is responsible for tracking its own progress and productivity. Management monitoring this directly is an anti-pattern that undermines team autonomy.
C. The Scrum Team is collectively accountable for its performance. Management directly removing individuals bypasses the team's responsibility to resolve internal challenges and erodes trust.
D. Scrum Teams perform best when they are stable and long-lived. Continual monitoring and adjustment of staffing levels by management is disruptive and hinders the team's ability to build cohesion.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. On page 5, it states that Scrum Teams are "self-managing, meaning they internally decide who does what, when, and how." This principle of self-management makes direct management oversight (options B, C, D) inappropriate. Management's role is to support this structure.

2. Hoda, R., & Noble, J. (2017). Becoming a self-organizing team. IEEE Software, 34(5), 26-31. This paper discusses the transition to self-organizing teams, noting that managers must shift from being directors to facilitators, "letting go of control" and supporting the team's journey (p. 28). This aligns with providing insights and resources for improvement. https://doi.org/10.1109/MS.2017.3641538

3. Stray, V., & Moe, N. B. (2020). Understanding coordination in global software engineering: A mixed-methods study on the use of meetings and Slack. Journal of Systems and Software, 170, 110717. The study highlights the importance of autonomy and notes that external management control can be detrimental. It reinforces that management's role is to create a supportive context rather than direct the work. https://doi.org/10.1016/j.jss.2020.110717

Non-functional requirements (NFRs) define the quality attributes of a system, such as security, performance, and usability. The Scrum framework provides two primary ways to make them visible and ensure they are addressed. First, if an NFR is a pervasive quality standard that should apply to every relevant Increment (e.g., "all code must pass security scans"), it should be included in the Definition of Done. This ensures the team consistently meets this quality standard every Sprint. Second, if an NFR requires a significant, discrete piece of work (e.g., "Refactor the database to support 1 million concurrent users"), it should be added to the Product Backlog as a Product Backlog Item (PBI). This makes the work transparent, allowing the Product Owner to prioritize it against other functional requirements.

A. Deferring incomplete work to the next Sprint is an anti-pattern. The goal is to produce a "Done" Increment that meets all requirements, including NFRs, within the Sprint.
B. Creating separate lists outside the official Scrum artifacts (Product Backlog, Sprint Backlog) reduces transparency and can lead to work being overlooked. All work should be in the Product Backlog.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide.

For option C (Definition of Done): "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product." (p. 10). NFRs are critical quality measures.

For option D (Product Backlog): "The Product Backlog is an emergent

ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team." (p. 8). This confirms that any work

including for NFRs

must reside in the Product Backlog to be transparent and prioritizable.

2. Inayat

I.

Salim

S. S.

Marczak

S.

Daneva

M.

& Shamshirband

S. (2015). A systematic literature review on agile requirements engineering. IEEE Transactions on Software Engineering

41(9)

839-860. https://doi.org/10.1109/TSE.2015.2433479

This review synthesizes research on agile practices. It identifies that NFRs are commonly handled in two ways: "as constraints on functional requirements (often in the form of acceptance criteria or the Definition of Done) or as separate non-functional requirements in the product backlog." (Section 4.2

"Handling NFRs"). This directly supports options C and D as established practices.

The Sprint Backlog is a direct output of the Sprint Planning event. According to the Scrum Guide, Sprint Planning initiates the Sprint by laying out the work to be performed. The Scrum Team collaborates to define the Sprint Goal, select Product Backlog Items for the Sprint, and create an actionable plan to deliver the Increment. This resulting plan, which includes the Sprint Goal (the "why"), the selected Product Backlog Items (the "what"), and the plan for delivery (the "how"), is the Sprint Backlog. It is created by and for the Developers to guide their work during the Sprint.

A. The Sprint Backlog is specific to a single Sprint and is created anew for each one, not once at the beginning of a project.
C. The Sprint Backlog is an output of the Sprint Planning meeting; therefore, it cannot be created prior to it.
D. While the Sprint Backlog is a living artifact that is updated by the Developers as more is learned during the Sprint, its initial creation occurs during Sprint Planning. ---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 8

"Sprint Planning" section: "Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team."

Page 9

"Sprint Backlog" section: "The Sprint Backlog is a plan by and for the Developers. It is a highly visible

real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal... It is created during the Sprint Planning event."

2. Verwijs

C.

& Russo

D. (2023). A Theory of Scrum. Zenodo. https://doi.org/10.5281/zenodo.10033478

Page 11

Section 3.2.1 "Sprint Planning": "The primary purpose of Sprint Planning is to create a plan for the upcoming Sprint. This plan is captured in an artifact called the Sprint Backlog." This academic source confirms that the Sprint Backlog is the plan created during the Sprint Planning event.

According to the Scrum Guide, a Sprint can be cancelled only if the Sprint Goal becomes obsolete. This situation might arise from a significant change in business strategy, market conditions, or technology, rendering the current goal irrelevant. Continuing the Sprint would be wasteful as the outcome is no longer valuable. The authority to cancel a Sprint rests solely with the Product Owner, who must weigh the significant cost and disruption of a cancellation against the value of pursuing a new direction.

A. The Development Team is expected to collaborate and adapt to overcome challenges; difficulty is not a valid reason for cancellation.
C. New business opportunities should be added to the Product Backlog and prioritized by the Product Owner for a future Sprint.
D. Not completing all forecasted work is a common outcome; the primary measure of success is achieving the Sprint Goal.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. p. 9. "A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint."

2. Stray, V., & Sjøberg, D. I. (2012). Coordination in Global Software Engineering: A Study of a Large-Scale Agile Project. In Agile Processes in Software Engineering and Extreme Programming (pp. 16-30). Springer. p. 20. The paper discusses Scrum mechanics, noting that Sprints are protected from external changes, with cancellation being the exception only when the goal is no longer valid. DOI: https://doi.org/10.1007/978-3-642-30350-02

3. University of California, Berkeley. (Course Material). CS169: Software Engineering. The course curriculum on Agile methodologies emphasizes that Sprints are time-boxed iterations that are cancelled only under exceptional circumstances, such as the Sprint Goal becoming obsolete, consistent with the official Scrum Guide.

The most effective tactic, aligned with Scrum principles, is for the Scrum Master to facilitate a process where the developers organize themselves into teams. This approach respects the core Scrum value of self-management. The developers, who will be doing the work, are in the best position to determine team compositions that balance skills, foster collaboration, and ensure cross-functionality. The Scrum Master's role is not to dictate team structure but to guide and empower the developers to make these decisions, ensuring they understand the constraints and goals, such as team size and the need for all skills to produce a "Done" Increment.

A. Creating teams based on skills across multiple layers (e.g., a UI team, a database team) establishes component teams, which is an anti-pattern. This creates dependencies between teams and impedes the ability to deliver a fully integrated, valuable Increment each Sprint.
B. The Product Owner is responsible for maximizing product value by managing the Product Backlog. Assigning people to teams is a management function outside the Product Owner's defined responsibilities and undermines the developers' self-management.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide.

Page 5: "Scrum Teams are self-managing

meaning they internally decide who does what

when

and how." This core principle directly supports the developers organizing themselves.

Page 6: The guide defines the Developers as "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint." It does not state that an external party should organize them.

2. Scrum.org. (2021). The Nexus Guide.

Page 4: When scaling Scrum

the guide states

"The individual Scrum Teams in a Nexus are self-managing and cross-functional." This reinforces that the principle of self-management in team formation holds true even for large groups.

3. Verheyen

G. (2021). Scrum - A Pocket Guide (3rd edition). Van Haren Publishing.

Section 3.3

"Self-managing": "Scrum requires the people doing the work of creating product Increments to be in charge of how they organize and perform their work... A Scrum Master can help people understand and enact self-management." This highlights the Scrum Master's role as a facilitator

not a director

of team formation.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects the last Sprint regarding individuals, interactions, processes, tools, and its Definition of Done. Therefore, discussing how the team collaborates (interactions) and identifying high-priority process improvements are central to this event. The outcome is an actionable plan for improvement in the upcoming Sprint, which may include adding specific improvement items to the next Sprint Backlog.

B. The order of items in the Product Backlog is the accountability of the Product Owner and is typically discussed during Product Backlog refinement, not the Sprint Retrospective.
D. Documenting acceptance criteria is an activity of Product Backlog refinement, which focuses on preparing items for future Sprints, not inspecting the process of the completed Sprint.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 12

"Sprint Retrospective": "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals

interactions

processes

tools

and their Definition of Done." (This supports option C).

Page 12

"Sprint Retrospective": "The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint." (This supports option A).

Page 9

"Product Backlog": "The Product Owner is also accountable for effective Product Backlog management

which includes: ... Ordering Product Backlog items". (This supports the reasoning for why option B is incorrect for this event).

2. Dingsøyr

T.

Dybå

T.

& Moe

N. B. (2018). A systematic review of the factors that contribute to the success of software process improvement. IEEE Transactions on Software Engineering

44(6)

588-605. https://doi.org/10.1109/TSE.2017.2699822

Section 3.2.2

"Retrospectives": The paper analyzes retrospectives as a key practice for continuous improvement

emphasizing their role in reflecting on the process and team collaboration to identify actionable improvements

which aligns with options A and C.

3. University of California

Berkeley. (n.d.). CS 169 Software Engineering Course Materials. EECS Department.

In lectures on Agile and Scrum

the Sprint Retrospective is defined as the event for the team to reflect on its own process ("what went well

what could be improved") and create a plan for improvements in the next Sprint. This distinguishes it from product-focused activities like backlog ordering or writing acceptance criteria.

When multiple Scrum Teams work on a single product, they must integrate their work to create one single, usable, and "Done" Increment by the end of the Sprint. This is fundamental to maintaining transparency, one of the three pillars of Scrum. An un-integrated Increment is not a true representation of the product's current state. This lack of integration obscures progress and prevents the Product Owner and stakeholders from accurately inspecting the Increment during the Sprint Review. Without a fully integrated Increment, meaningful feedback cannot be gathered, and future adaptations to the Product Backlog may be based on flawed assumptions.

A. Yes, but only for Scrum Teams whose work has dependencies. This is incorrect because all teams contribute to a single product. Integration is required to ensure a coherent and valuable product Increment, regardless of direct dependencies.
C. No, each Scrum Team stands alone. This is false. When working on the same product, teams share a single Product Goal, Product Backlog, and Product Owner, and must collaborate to produce a single integrated Increment.
D. No, that is far too hard and must be done in a hardening Sprint. This describes an anti-pattern. Deferring integration to a "hardening Sprint" introduces risk, delays feedback, and violates the core Scrum principle of producing a potentially releasable Increment every Sprint.

1. The Scrum Guide (2020):

Page 9

"The Increment": "The moment a Product Backlog item meets the Definition of Done

an Increment is born... Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. ... Work cannot be considered part of an Increment unless it meets the Definition of Done." When multiple teams work on one product

their collective "Definition of Done" must include integration to create a single

usable sum of Increments.

2. The Nexus Guide (January 2021): (The official Scrum.org guide for scaling Scrum with multiple teams)

Page 5

"Nexus Artifacts": "At least once every Sprint

a Nexus produces and delivers a common Integrated Increment... The Integrated Increment is the sum of all integrated work completed by a Nexus. The Integrated Increment must be usable and potentially releasable... It is inspected at the Sprint Review." This explicitly states the requirement for a single

integrated Increment from all teams.

3. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide.

Page 5

"Scrum Theory": "Scrum combines four formal events for inspection and adaptation... These events work because they implement the empirical Scrum pillars of transparency

inspection

and adaptation." An un-integrated Increment is not transparent

which breaks the empirical process control that is the foundation of Scrum.

The Scrum Guide recommends that a Development Team should have between three and nine members. A team with fewer than three members may struggle with skill constraints and reduced interaction, which can lead to lower productivity. Conversely, a team with more than nine members requires too much coordination and generates excessive complexity, which is detrimental to an empirical process. This size range is considered optimal for maintaining agility, facilitating effective communication, and ensuring the team is large enough to complete a significant amount of work within a Sprint. This count excludes the Product Owner and Scrum Master unless they are also executing work from the Sprint Backlog.

A. 7 plus or minus 3 results in a range of 4 to 10, which is not the officially recommended range.
B. A minimum of 7 is incorrect; the Scrum Guide explicitly states that effective teams can be as small as 3 members.
C. 9 is only the recommended maximum size, not the single required size. The guide provides a range to allow for flexibility.

1. Schwaber

K.

& Sutherland

J. (2017). The Scrum Guide™: The Definitive Guide to Scrum: The Rules of the Game. Scrum.org. (Page 6

Section: "Development Team Size").

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains... Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful."

2. Verwijs

C.

& Russo

D. (2022). A Theory of Scrum Team Effectiveness. In Proceedings of the 23rd International Conference on Agile Software Development (XP 2022). Association for Computing Machinery. (Page 100

Section 3.2). https://doi.org/10.1145/3533716.3533730

This academic paper discusses team size as a structural factor for effectiveness

referencing the Scrum Guide's recommendation: "The Scrum Guide (2017) recommends a size of 3 to 9 developers."

When faced with a growing list of impediments, the Scrum Master must act effectively to support the team. The most helpful techniques involve collaboration, prioritization, and escalation. First, consulting the Development Team is crucial as they have the most context, can help clarify the impact, and may offer solutions (A). Second, not all impediments are equal; prioritizing the list allows the Scrum Master to focus on resolving the most critical blockers first, maximizing their impact (B). Finally, for impediments beyond the team's or Scrum Master's control (e.g., organizational policies, resource issues), the Scrum Master must ensure transparency by alerting management to the problems and their impact on the team's progress (D).

C. Arranging a triage meeting with all project managers. Scrum does not define a "project manager" role. This approach suggests a bureaucratic, non-agile solution rather than engaging the specific individuals who can actually resolve the impediments. ---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Reference for A & D: Page 7

"The Scrum Master serves the Scrum Team in several ways

including: ... Removing impediments to the Development Team’s progress." and "The Scrum Master serves the organization in several ways

including: ... Leading

training

and coaching the organization in its Scrum adoption; ... Helping employees and stakeholders understand and enact an empirical approach for complex work." This supports consulting the team (A) and escalating to the organization/management when necessary (D).

Reference for C: The role of "Project Manager" is not defined anywhere in the Scrum Guide

making option C inconsistent with the Scrum framework.

2. Verwijs

C.

& Russo

D. (2022). A Theory of Scrum Team Effectiveness. In Proceedings of the 23rd International Conference on Agile Software Development (XP 2022). Association for Computing Machinery

New York

NY

USA

19–35. https://doi.org/10.1145/3533716.3533720

Reference for A

B

D: The paper discusses how effective teams "actively manage their impediments" (p. 28). It emphasizes the team's role in this process (supporting A) and the need to "escalate impediments they can't resolve" to management (supporting D). The act of managing a list of impediments inherently requires prioritization (supporting B) to be effective.

3. Stray

V.

& Moe

N. B. (2020). Understanding coordination in global software engineering: A mixed-methods study on the use of meetings and Slack. Journal of Systems and Software

170

110717. https://doi.org/10.1016/j.jss.2020.110717

Reference for A & D: This study highlights that impediment removal often requires coordination beyond the team. The Scrum Master facilitates this by "removing impediments by communicating with people outside the team

for example

management" (Section 4.2.3)

which supports both consulting the team to understand the issue and escalating to management for resolution.

The Product Owner is the sole person responsible for managing the Product Backlog and stakeholder expectations. The Development Team's focus during a Sprint is on achieving the Sprint Goal. When a stakeholder, such as the CEO, requests a change, the Development Team should not act on it directly. Instead, they must redirect the stakeholder to the Product Owner. The Product Owner will then discuss the new item with the stakeholder, assess its value and priority, and if necessary, negotiate with the Development Team about how to best accommodate the request without endangering the Sprint Goal. This maintains the proper roles, responsibilities, and flow of work within the Scrum framework.

A. The Development Team should not unilaterally make scope trade-offs. This bypasses the Product Owner's accountability for maximizing the value of the product by managing the Product Backlog.
B. Adding work without any adjustments is not feasible and would endanger the Sprint Goal, which is a core principle of Scrum that must be protected during the Sprint.
D. The Development Team does not decide the content of the next Sprint. Committing to work in a future Sprint is a decision made during Sprint Planning, led by the Product Owner.

1. The Scrum Guide (2020)

K. Schwaber and J. Sutherland.

Page 5

"Product Owner" section: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team... For Product Owners to succeed

the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog... No one else is allowed to tell the Developers to work from a different set of requirements." This establishes the Product Owner as the single point of contact for all product requirements and priorities.

Page 9

"The Sprint" section: "During the Sprint... No changes are made that would endanger the Sprint Goal... Scope may be clarified and re-negotiated with the Product Owner as more is learned." This reinforces that any scope negotiation during a Sprint must involve the Product Owner.

2. Agile Software Development with Scrum

K. Schwaber and M. Beedle

Pearson

2002.

Chapter 6

"The Product Owner": This chapter details the Product Owner's role as the "single wringable neck" responsible for the product's success

which includes managing and prioritizing the Product Backlog and being the interface between stakeholders and the Development Team. The team is shielded from conflicting stakeholder demands.