Free Professional Scrum Master Exam Flashcards

A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Scrum is founded on empiricism and lean thinking, requiring only the parts prescribed in the Scrum Guide to be implemented. It is intentionally incomplete, providing only the rules within which various techniques can be employed.

The principle that knowledge comes from experience and making decisions based on what is observed. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. The three pillars of empiricism in Scrum are transparency, inspection, and adaptation.

The first pillar of empiricism requiring that the emergent process and work must be visible to those performing the work as well as those receiving the work. Important decisions are based on the perceived state of its three formal artifacts, so artifacts with low transparency can lead to decisions that diminish value and increase risk.

The second pillar of empiricism where Scrum artifacts and progress toward agreed goals must be inspected frequently to detect potentially undesirable variances or problems. Inspection enables adaptation and is most beneficial when done by skilled inspectors at the point of work. The five Scrum events are designed to enable inspection.

The third pillar of empiricism where adjustments must be made as soon as possible when any aspect of a process deviates outside acceptable limits or if the resulting product is unacceptable. A Scrum Team must adapt the moment inspection reveals the need. Adaptation becomes more difficult when people are not empowered or self-managing.

The five values that are essential for Scrum Team success: Commitment, Courage, Focus, Openness, and Respect. When these values are embodied by the Scrum Team and the people they work with, the empirical pillars of transparency, inspection, and adaptation come to life building trust. These values give direction to the Scrum Team's work, actions, and behavior.

The Scrum Team commits to achieving its goals and to supporting each other. Members personally commit to the Sprint Goal and to delivering a valuable, useful Increment. This commitment is about dedication to the team's success, not a guarantee of specific outcomes, since complex work has inherent uncertainty.

Scrum Team members have the courage to do the right thing and work on tough problems. This includes having difficult conversations, admitting mistakes, asking for help, and challenging the status quo when it impedes the team. Courage enables transparency and honest communication about progress and challenges.

Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Sprint provides focus by limiting work to a manageable timeframe and committing to a Sprint Goal. This prevents distraction, reduces context-switching, and helps the team make meaningful progress toward their objectives.

The Scrum Team and its stakeholders are open about the work and the challenges. This includes being transparent about progress, impediments, and risks. Openness creates an environment where issues can be addressed quickly, feedback is welcomed, and continuous improvement is possible.

The fundamental unit of Scrum consisting of one Scrum Master, one Product Owner, and Developers. There are no sub-teams or hierarchies within the Scrum Team. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional and self-managing, meaning they internally decide who does what, when, and how.

A Scrum Team that internally decides who does what, when, and how. The 2020 Scrum Guide changed from 'self-organizing' to 'self-managing' to emphasize that the team chooses not only how to do work but also what work to do. Self-management requires trust, transparency, and the empowerment to make decisions.

A Scrum Team that has all the skills necessary to create value each Sprint without depending on others outside the team. This means the team collectively possesses all competencies needed to accomplish the work, though individual members may have specialized skills. Cross-functionality reduces dependencies and enables faster delivery.

The people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. Their specific skills needed are often broad and vary with the domain of work. Developers are accountable for creating a plan for the Sprint (Sprint Backlog), instilling quality by adhering to a Definition of Done, and adapting their plan each day toward the Sprint Goal.

Scrum Teams are typically 10 or fewer people, small enough to remain nimble and large enough to complete significant work within a Sprint. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product and sharing the same Product Goal, Product Backlog, and Product Owner.

The 2020 Scrum Guide replaced 'roles' with 'accountabilities' to emphasize that these are not job titles or positions but minimum responsibilities required for Scrum to work. The three accountabilities are Scrum Master, Product Owner, and Developers. Multiple people can share an accountability, and one person may hold multiple accountabilities.

Scrum Team members respect each other as capable, independent people, and are respected as such by the people with whom they work. Team members respect each other's skills, expertise, and perspectives. This mutual respect creates psychological safety and enables honest collaboration without fear of judgment or blame.

People outside the Scrum Team who have an interest in or are affected by the product being developed. While not part of the Scrum Team, stakeholders provide valuable feedback during Sprint Reviews and help shape the Product Backlog through the Product Owner. The Scrum Master may help facilitate stakeholder collaboration when needed.

The accountability responsible for establishing Scrum as defined in the Scrum Guide, helping everyone understand Scrum theory and practice, and ensuring the Scrum Team's effectiveness. Scrum Masters are true leaders who serve the Scrum Team and the larger organization. They help the team become self-managing and cross-functional.

The Scrum Master serves Developers by coaching them in self-management and cross-functionality, helping them focus on creating high-value Increments that meet the Definition of Done, causing removal of impediments, and ensuring all Scrum events are productive, positive, and kept within the timebox.

The Scrum Master serves the Product Owner by helping find techniques for effective Product Goal definition and Product Backlog management, helping the team understand the need for clear and concise Product Backlog items, helping establish empirical product planning, and facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization by leading, training, and coaching the organization in Scrum adoption, planning and advising Scrum implementations, helping employees and stakeholders understand empirical product development, removing barriers between stakeholders and Scrum Teams.

One of the key responsibilities of the Scrum Master is causing the removal of impediments to the Scrum Team's progress. Impediments are anything blocking the team from achieving the Sprint Goal. The Scrum Master may remove impediments directly or coach the team to remove them, always working to increase the team's self-management capability.

The leadership style where the Scrum Master leads by serving the Scrum Team and organization, putting their needs first rather than directing them. This includes listening, empathizing, healing, awareness, persuasion, conceptualization, foresight, stewardship, and commitment to growth. Servant leaders enable others to succeed.

The Scrum Master facilitates Scrum events as requested or needed, ensuring they are productive and timeboxed. Facilitation means helping the team have effective conversations, making sure everyone is heard, and guiding discussions toward valuable outcomes. The Scrum Master facilitates but does not direct or control the team's decisions.

The Scrum Master coaches the team members in self-management and cross-functionality, coaches the organization in Scrum adoption, and helps everyone understand Scrum theory and practice. Coaching involves asking powerful questions, active listening, and helping others find their own solutions rather than providing answers.

The accountability responsible for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, teams, and individuals. The Product Owner is one person, not a committee, and represents the needs of many stakeholders in the Product Backlog.

The Product Owner is accountable for developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering Product Backlog items, and ensuring that the Product Backlog is transparent, visible, and understood. The Product Owner may do this work or delegate it, but remains accountable.

The Product Owner is one person with the authority to make decisions about the product and Product Backlog. The entire organization must respect their decisions, which are visible in the content and ordering of the Product Backlog and through the inspectable Increment at the Sprint Review. No one else can tell Developers to work on different requirements.

The Product Owner is responsible for ordering Product Backlog items to best achieve goals and missions. Ordering considers factors like value, risk, dependencies, and learning opportunities. Higher-ordered items are usually clearer and more detailed than lower-ordered items. The order determines what Developers will work on next.

The Product Owner is always one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change the Product Backlog must try to convince the Product Owner. Having a single Product Owner ensures clear accountability and faster decision-making.

The Product Owner represents the needs of many stakeholders in the Product Backlog. They gather input from customers, users, business, and other stakeholders, synthesizing these needs into an ordered Product Backlog. This single point of accountability prevents conflicting priorities and ensures coherent product direction.

A fixed-length event of one month or less that serves as a container for all other Scrum events. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happens within Sprints.

During a Sprint: no changes are made that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner as more is learned. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal.

A Sprint can be cancelled if the Sprint Goal becomes obsolete, but only the Product Owner has the authority to cancel a Sprint. Sprint cancellations consume resources since the team must regroup in a new Sprint Planning. Due to the short duration of Sprints, cancellation rarely makes sense.

The event that initiates the Sprint by laying out the work to be performed. Sprint Planning addresses three topics: Why is this Sprint valuable (Sprint Goal), What can be Done this Sprint (selected Product Backlog items), and How will the chosen work get done (plan for delivering the Increment). Timeboxed to eight hours for a one-month Sprint.

A 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. It is held at the same time and place every working day of the Sprint to reduce complexity. Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal.

The Daily Scrum is an event for Developers. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers. Developers are free to meet throughout the day for more detailed discussions. The Daily Scrum is not the only time Developers can adjust their plan.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders, and progress toward the Product Goal is discussed. The Sprint Review is a working session and not limited to a presentation. Timeboxed to four hours for a one-month Sprint.

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. It is timeboxed to three hours for a one-month Sprint and concludes the Sprint.

The Scrum Team identifies the most helpful changes to improve its effectiveness during the Sprint Retrospective. The most impactful improvements are addressed as soon as possible and may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective is the formal opportunity to focus on inspection and adaptation regarding the team's process.

All Scrum events are timeboxed with maximum durations. For a one-month Sprint: Sprint Planning is 8 hours, Daily Scrum is 15 minutes, Sprint Review is 4 hours, and Sprint Retrospective is 3 hours. For shorter Sprints, events are usually shorter. Events end when their purpose is achieved, but never exceed their timebox.

Scrum's artifacts represent work or value and are designed to maximize transparency of key information. The three artifacts are Product Backlog, Sprint Backlog, and Increment. Each artifact contains a commitment to provide information that enhances transparency and focus: Product Goal, Sprint Goal, and Definition of Done respectively.

An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning. They usually acquire this degree of transparency after refining activities.

The commitment for the Product Backlog that describes a future state of the product which can serve as a target for the Scrum Team to plan against. It is the long-term objective for the Scrum Team and is in the Product Backlog. A Scrum Team must fulfill or abandon one Product Goal before taking on another.

Composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). It is a plan by and for Developers that is updated throughout the Sprint as more is learned. It should have enough detail that progress can be inspected in the Daily Scrum.

The commitment for the Sprint Backlog that is the single objective for the Sprint. It is created during Sprint Planning and provides flexibility in terms of the exact work needed. The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. Multiple Increments may be created within a Sprint, and the sum of the Increments is presented at the Sprint Review. Work cannot be considered part of an Increment unless it meets the Definition of Done.

The commitment for the Increment that is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. If an item does not meet the Definition of Done, it cannot be released or presented at the Sprint Review.

The act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details such as description, order, and size. Developers who will do the work are responsible for the sizing, while the Product Owner may influence them by helping them understand and select trade-offs.