PSPO I Exam Simulation

While generating revenue is an important goal of most products, it is not the only one and sometimes not even applicable.

In Scrum, business progress is measured by working software, therefore the Sprint Review is the best occasion for getting informed. Following Sprint progress is less useful for the management, however, if they are really curious about it, they may follow up the same metrics that are used by the Development Team.

A Sprint could be cancelled if the Sprint Goal becomes obsolete.

Further reading: The Sprint

Based on the Scrum Guide, the artifacts are the Product Backlog, the Sprint Backlog and the Increment. Using other tools/techniques/documents may also be beneficial but those are not Scrum artifacts.

Further reading: Scrum Artifacts

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

- from the Scrum Guide

Further reading: The Definition of Done

Note: the previous version of the Guide made the Development Team responsible for creating a Definition of Done. However, as the Development Team is no more, the new Guide assigned this responsibility to the entire Scrum Team, not to the Developers of the Scrum Team. Arguably, the Scrum Master and the Product Owner are also parties with interest in having a neat Definition of Done, thus this minor change is a positive one.

"Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum."

Thus the guide recognizes the potential need for other meetings.

The thumb rule is, the Product Owner is accountable for the Product Backlog. However, the Product Owner can trust the Developers to elaborate it.

In the guide, we can find it in combination with the Product Owner's accountabilities and the following statement:

"The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable."

Further reading: Product Backlog

The Scrum Guide does not prescribe this anymore, however, common sense still suggests that refinement typically impacts Product Backlog items of future Sprints so that they are ready for selection during Sprint Planning. For the current Sprint, it is a bit too late to perform refinement, though better late than never.

Sprint Review is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

The 4 hours is a timebox, thus it tells the maximum length, only.

Further reading: The Sprint Review

While we can argue that it helps the management and other stakeholders to understand what the team is working on, the most important role of the Sprint Goal is to help the Developers to keep focused and achieve the desired outcome. We have to keep in mind that a Sprint is not about tickets or stories but about a goal! The goal is not the same as the sum of stories selected for a Sprint.

The Product Owner is also accountable for effective Product Backlog management

The Product Owner

"Removing barriers between stakeholders and Scrum Teams."

- from the Scrum Guide

Further reading: The Scrum Master

"To reduce complexity, it is held at the same time and place every working day of the Sprint." - from the Scrum Guide

No exceptions.

Further reading: Daily Scrum

This is the historical truth and even included in the Scrum Guide.

Only the Product Owner can cancel a Sprint.

Every product needs a single Product Backlog even if there are multiple Scrum Teams working on it.

The cone of uncertainty illustrates that the uncertainty of a project decreases as time progresses. It is true from the other perspective, too: the near future is more certain than the far future.

The purpose of the Sprint is to build one or more increments embodying the Sprint Goal.

Wrong answers:

• The Sprint Review is just an event, an element of the Scrum framework but at most a 'by-product'. It is a means, not a result.
• Increments are only released when they provide value to the users or the business, in their current form.

As stated in the guide:

Scrum is founded on empiricism and lean thinking.

Further reading: Scrum Theory

Only the Development Team can estimate Product Backlog Items.

If a Product Backlog item does not fit a Sprint, it would not be inspectable at the end of the Sprint. It would not meet the requirement of being potentially releasable. Any team having half-done stories runs a serious risk of the deterioration of the value of their work.

The 2020 Scrum Guide does not explicitly detail monitoring Sprint-progress. Previously it was the responsibility of the Development Team, which has also been eliminated by the 2020 Scrum Guide. It could be still the responsibility of the Developers since they are in the best position to do so: the Daily Scrum and the Sprint Backlog are good inputs or tools for monitoring the progress. However, the 2020 Scrum Guide also changed an important aspect of Scrum. Previously the Development Team was self-organizing, now the entire Scrum Team is self-managing. This means monitoring progress is either the responsibility of the Developers or the Scrum Team, depending on the offered choices.

There is a subtle difference between the previous editions of the Scrum Guide and the latest one (2020 November). Previously the Scrum Team had a Development Team which was meant to be a role but was perceived as a sub-unit within the Scrum Team. The new Guide eliminated the self-organizing Development Team and made everyone members of the undivided, self-managing Scrum Team.

The correct answers reflect that the Developers are not executors of the Product Owner's orders. They are active participants in shaping the product with their own ideas and insights, whether it comes from their non-Scrum role in the process (e.g. a business analyst) or spontaneously while elaborating the high-level ideas discussed with the Product Owner.

User Story and ROI are optional techniques and using them is not the point of having a Product Backlog.

The Product Backlog is very important for the Developers, thus not something between the stakeholders and the Product Owner.

Product Backlog items are under the discretion of the Product Owner. Having 'approved requirements' is not an agile solution, even though Scrum does not prescribe what type of agreements are allowed between the Product Owner and the stakeholders.

The 2020 Scrum Guide has different wording for the same statement:

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Further reading: The Definition of Scrum

The traditional 3 questions are optional as the Daily Scrum can take place in any format which suits the needs of the Developers of the Scrum Team.

The rest of the provided options are wrong, those are not really good topics for this event.

"Multiple Scrum Teams working with the same Product Owner must follow the same Definition of Done." - Almost, but it does not depend on the Product Owner but on the Product.

"The Scrum Master serves the Scrum Team by working with other Scrum Masters to define a common Definition of Done." - The Scrum Masters can help their teams in the process of synchronizing their Definition of Done, but the Guide does not prescribe this, and especially not the way that the Scrum Masters define the Definition of Done.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

-- the Scrum Guide

Further reading: The Definition of Done

Only the Developers of the Scrum Team are in the position to produce an educated guess on the effort needed to implement a Product Backlog item or to estimate what can be delivered within a Sprint. They can negotiate trade-offs with the Product Owner, though.

The question targets the Scrum roles. The incorrect answers are flawed in various ways:

• There is no project manager in Scrum
• The Development Team has been eliminated in 2020 and the role has been renamed to Developer
• Tester and architect are job titles, not roles, therefore irrelevant to Scrum

Further reading: The Scrum Team

About the Sprint: "Scope may be clarified and renegotiated with the Product Owner as more is learned." Further reading: Sprint Planning

About the Sprint Backlog: "[...] the Sprint Backlog is updated throughout the Sprint as more is learned." Further reading: Sprint Backlog

Note, the Product Owner can remove selected backlog items in case of obsoletion but cannot add anything unilaterally.

Based on the previous Scrum Guide: Usually not more than 10% of the capacity of the Team.

This is not part of the new Scrum Guide, it is just common sense. Spending too much time on refinement adversely impact the progress of the current Sprint, on the other hand, negligence of the refinement adversely impacts the upcoming Sprint.

The other two answers are straight wrong. The 4-hour limit is set for the Sprint Review meeting while backlog refinement is for the Developers and the Product Owner, not for the Scrum Master.

Further reading: Product Backlog

"Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
5. Sustain and renew products.
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies."

- from the 2017 Scrum Guide

The 2020 version does not have this chapter, arguably not essential for describing Scrum. However, it is important to identify which is the wrong answer and why: build identical products in large quantities is not an agile product development process.

Further reading: Uses of Scrum

"The Sprint Backlog is the set of Product Backlog items selected for the Sprint. Planning means selecting this set of items." - Wrong, since the Sprint Planning consists of 3 topics: the goal, the what and the how. The first sentence only covers the 'what', so the second sentence equating it to Sprint Planning is false.

"The Developers have to create a task list for every Product Backlog item. The Sprint must not start without the complete task list." - Wrong, since this is not really required by Scrum. A team may follow such practices, though.

"The Developers plan the work necessary to create an Increment that meets the Definition of Done." - this is correct, it is part of Sprint Planning.

Further reading: Sprint Planning

The false statement makes a direct connection between the Sprint Goal and the Definition of Done, which is wrong:

• The Sprint Goal has a business purpose and is peculiar to a Sprint;
• The Definition of Done is a generic statement. All Product Backlog Items must meet the Definition of Done when claimed to be done.

Further reading: The Definition of Done, Sprint Planning

Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

Further reading: Purpose of the Scrum Guide

As per the rules of Scrum, it is the Scrum Master.

One of the services of the Scrum Master to the Scrum Team is "Causing the removal of impediments to the Scrum Team’s progress".

Further reading: The Scrum Master

The Scrum Guide briefly mentions:

"If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product."

Previously, the 2017 edition made the 'Development Team' (who are simply the Developers now) responsible for it.

The Product Owner's interest is in understanding the Definition of Done since it has an impact on making decisions on a release.

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."

- from the Scrum Guide

The latest version of the guide is less detailed on this question, however, it is still clear that only the Developers of the self-managing Scrum Team are in the position to track the progress of a Sprint.

Further reading: Daily Scrum

The definition of "Done" is important for the Product Owner. Among others because it is key for transparency and it helps the forecasting process at Sprint Planning.

It has nothing to do with product cost and acceptance criteria.

While the new Scrum Guide issued in 2020 November is less elaborate on this question, we can still assume it is common sense that the Developers work together with the Product Owner transparently and seek ways to find the best outcome of any given Sprint.

Ideally, the Scrum Team should have all the skills to deliver the Product Backlog items. While complex organizations may not be able to avoid minor dependencies, a Scrum Team must not critically depend on others to build the Increment.

The Scrum Guide does not define strict limits. Previously 3-9 was recommended for the Developers, even before 7+/-2. However, the current Scrum Guide only states that a Scrum Team (including the Scrum Master, the Product Owner and the Developers) has typically 10 members or less.

Further reading: The Scrum Team

Even though in certain cases the Product Backlog may contain business secrets, it must be transparent for those who are involved in its implementation. These include the Developers, the Scrum Master, the Product Owner and those stakeholders whose contribution is critical and their involvement is inevitable.

However, set aside the rare cases when the Product Backlog contains sensitive material, it should be transparent as much as possible to all those functions of the organization who are interested in implementing it.

Whatever motives the Developers to build a solution, satisfactory collaboration with the Product Owner is the key to meet his/her expectations.

While the guide does not give a comprehensive list of Product Backlog management activities, the following items are explicitly mentioned as part of the Product Owner's accountabilities:

• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.

Further reading: The Product Owner

In contrast, the Scrum Board is just a popular 'arbitrary' tool for managing the Product and/or the Sprint Backlog and the Definition of Ready is an optional technique to flag Product Backlog Items that are ready for implementation.

"The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. [...] If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."

Thus, this meeting is exclusively for the developers, so much that even the Scrum Master and the Product Owner are not required/expected to participate unless they have developer duties, too. There is no explicit ban for others to occasionally attend but they cannot participate. However, it is still true that outsiders can derail the meeting even with their passive presence.

Further reading: The Daily Scrum

"A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint. "

- from the Scrum Guide

This is fairly logical since it the who is PO is responsible for the business outcome. Before the first Scrum Guide was published there was no clear consensus whether the developers could also cancel a sprint, e.g. if the PO requests significant changes to the product backlog. Such action would be pretty concerning, however, the PO has the right to negotiate changes to the Product Backlog Items with the Developers.

Further reading: The Sprint

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.

Further reading: The Daily Scrum

This is not regulated by Scrum. The Guide only states:

"The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable."

The 3 pillars are transparency, inspection and adaptation.

Further reading: Scrum Theory

"This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter."

- from the Scrum Guide

Further reading: The Sprint Review

The Product Owner is always one person. The Product Owner may receive help from others but still remains responsible for the product.

"Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint." - from the Scrum Guide

These are the well known

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective"

The answer is in the Guide:

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Further reading: Sprint Retrospective

The value of the product is in its characteristics.

The current Scrum Guide does not elaborate this, however, but definitely does not forbid it either. The 2017 Scrum Guide was more verbose on this question:

"As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality."

This is logical in an empirical process since we cannot expect anyone to draft the perfect Definition of Done before the development starts.

The three correct statements were explicitly stated by the 2017 Scrum Guide. The 2020 version is less elaborate on these questions. However, the truth behind these statements is still supported by the Scrum Guide:

• In the Daily Scrum chapter, it states that this meeting is for the Developers. It also states that the Scrum Master and the Product Owner should participate only if they are 'Developers' themselves (in the sense of working on backlog items).
• In the Scrum Master chapter, it states that Scrum Master ensures all Scrum events take place and are positive, productive, and kept within the timebox.

"The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done."

- from the Scrum Guide

People are often confused about whether the retro is for the developers only. While it might be true that the presence of managers, outsiders, and unfriendly stakeholders can derail this event, the Product Owner and the Scrum Master should definitely participate.

Further reading: Sprint Retrospective

"The Scrum Team may also invite other people to attend Sprint Planning to provide advice."

- from the Scrum Guide

Further reading: Sprint Planning

"As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included." - the Scrum Guide

Whatever "Developers" develop, that is "development". Depending on the context, it may have nothing to do with software development.

Further reading: Purpose of the Scrum Guide

The Scrum Master must ensure that the Daily Scrum reaches its goal. Doing nothing is not a good solution.

Developers should be self-managing. The Daily Scrum is a very simple event that does not need to be orchestrated by a Scrum Master. Micromanaging the team is not a good solution.

The Scrum Master is responsible for transparency, thus cannot just ask a stakeholder to leave without ensuring that transparency is not negatively impacted. Furthermore, using the word 'chicken' to a group of people lacks respect and should be avoided. [Note, the 'chicken' term actually originates from an early version of the Scrum Guide but was not meant to be a reference to people.]

The Scrum Master is a coach of the organization and of the Scrum Team, including the Developers, thus it is important to facilitate reaching a solution for their problems.

"No, the Sprint has been planned, this is what the team is going to deliver." - WRONG, this is the opposite of being agile and would result in pointless waste.

"No, the Sprint Backlog belongs to the Developers, no one else can change it." - WRONG, this is an oversimplification of the question on semantic grounds.

"The Product Owner can decide anytime that a backlog item is not needed anymore. The scope can be re-negotiated with the Development Team which is especially feasible when work is removed." - CORRECT, this answer corresponds best to the Scrum Guide.

"Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how." - the Scrum Guide

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." - the Scrum Guide

"Within a Scrum Team, there are no sub-teams or hierarchies." - the Scrum Guide

Further reading: The Scrum Team

There is no Sprint 0 in Scrum.

While there is nothing against drafting a high-level plan even before the first Sprint to establish a shared understanding, detailed up-front planning is discouraged in agile software development.

The main reasons are accountability and the efficiency of communication and decision-making.

The Product Owner may not even be involved in writing product documentation.

There are no financial considerations behind the need for a single Product Owner.

When maximizing the value delivered by the team, multiple factors should be considered. If building the most 'important' backlog items is impeded, try to find other backlog items worth delivering.

A time-box is the maximum allocated time for an event.

"Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."

- from the Scrum Guide

Implementing Scrum typically requires many process and organisational changes and a cultural shift from the participants. It can be very tempting to cut the corners, cherry-pick some of the easy-to-adopt elements and overrule the rest, however, Scrum is lenient on all of its components.

Further reading: Purpose of the Scrum Guide

The current Scrum Guide states:

Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency.

Accuracy matters on a PSM exam. Further reading: The Sprint

Why are the other answers wrong?

Before the release of the first Scrum Guide, various definitions and recommendations existed. Some of the offered answers reflect these.

• "30 days" was mentioned by Sutherland as a synonym of a month, however, shorter sprints were never disfavoured.
• 1-4 weeks is the practical advice and this is the typical length in practice, however, it is not a rule.
• The 'as long as needed' is used by other agile frameworks, however, Scrum prefers fixed-length Sprints and no (frequent) changes in Sprint length.

• It reduces complexity. If it where held every second day, people would be confused why we call it 'daily'. -> Kind of true but this is not the reason.
• It informs the Product Owner and the stakeholders about the status of the project. -> Daily Scrum is not for the Product Owner, stakeholders should not be involved at all finally, Scrum is not about projects.
• The Scrum Master can replan the Sprint based on the daily reports. -> This is flawed in every way, the Scrum Master does not plan or replan sprints and even if creates reports, the Daily Scrum is not an even for that.
• It helps the Developers to have a shared understanding of the situation and to plan their day accordingly. -> this is short summary of the purpose of the Daily Scrum.
• If not yet done so, impediments can be raised for the Scrum Master. -> Even though the Scrum Master is not necessarily required to attend the Daily Scrum, it is typically a good occasion to raise impediments. This answer is clearly among the best two.

The correct answer is: "Scrum Teams and their associated roles, events, artifacts, and rules", so much that this statement was part of the Scrum guide until the 2020 overhaul. The other answers are wrong for various reasons, e.g. Scrum has no ceremonies and detailed processes, elaborate methods and instructions. The "values, principles, pillars and rules" list is vaguely related to Scrum, however, it clearly misses the point.

The answer which claims that the Product Backlog is optional contradicts the Scrum Guide in multiple ways:

• The Product Backlog is not optional in Scrum.
• User Stories can be used in Scrum (as an optional technique) for describing Product Backlog Items but these two are not the same.

Further reading: Product Backlog

"When the corresponding business requirement specification is approved by the stakeholders." - Wrong: while we cannot exclude that in rare scenarios stakeholder approval might be necessary, in general, this is not a Scrum practice.

"When its User Story and Acceptance Criteria are finalized and its value is quantified." - Wrong: User Story and Acceptance Criteria are optional techniques for defining Product Backlog Items.

"When the Scrum Master considers its details and quality appropriate for Sprint Planning." - The Scrum Master has no such authority. Her or his responsibility is to ensure the team can identify when the necessary details and quality is reached.

"When it is understood by the Development Team good enough to forecast its delivery in line with a Sprint Goal." - Correct! This is what supports the goals of Sprint Planning best.

"The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide."

Further reading: The Scrum Master

This is so much not required that even the example is removed from the new Scrum Guide. However, still a practice worth considering.

Further reading: The Daily Scrum

The Scrum Board is a potential representation of the Sprint Backlog, but not a Scrum artifact.

The Burndown Chart is an optional technique for monitoring Sprint progress, but not a Scrum artifact.

There is no project plan in Scrum.

Further reading: Scrum Artifacts

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."