PSPO I Exam Simulation

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 Product Owner is also accountable for effective Product Backlog management

The Product Owner

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.

This is how Scrum was described in the pre-2020 Scrum Guides. The current one also mentions that it is lightweight and simple. But if not anymore explicitly stated, is it really difficult to master? Have no doubt about it.

"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

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

"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

The stakeholders may give valuable input which may result in a reordered Product Backlog, but it is the Product Owner who has the final say.

Only the Product Owner can decide to cancel a Sprint. Furthermore, an obstacle to delivering one item does not make the Sprint Goal obsolete, thus it is not a good reason for cancelling the Sprint. The Product Owner may have legitimate reasons for being late with the document but should mind the consequences.

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 Daily Scrum is an event for the Developers. While the Scrum Master is responsible to ensure the meeting takes place and the team adhere to the rules, the Scrum Master is not even required to attend it.

"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.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."

- from the Scrum Guide

While 'collaborate' is just a word choice that could have been replaced with some synonyms, it is genuinely and generally true that the Sprint Review meeting is the only Scrum event that stakeholders are expected to visit.

Further reading: The Sprint Review

The Scrum Guide canonized the names of the events (it even canonized that these are events and not ceremonies and not even meetings). No more stand-up and demo. Grooming is called Refinement and is not an event but a process.

Further reading: Scrum Events

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.

"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

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

"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."

"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.

"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

"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

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 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.

"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

"If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done." - from the Scrum Guide

In practice, the thumb rule is, the increments should be compatible, inspectable and transparently done to the same standards. This may mean the exact same Definition of Done for all teams or coherent variants taking into account the peculiarities of each team. The wording of the current Guide suggests these teams should use the exact same Definition of Done.

Further reading: The Definition of Done

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.

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

Further reading: The Daily Scrum

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

• 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 Product Owner is always one person. The Product Owner may receive help from others but still remains responsible for the product.

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.

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

"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

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.

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

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.

"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 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 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 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.

"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 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.

"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

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.

"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 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

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.

"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.

The value of the product is in its characteristics.

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

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.

"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 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

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 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 Scrum Values are: Commitment, Focus, Openness, Respect, and Courage

Scrum Values

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.

As stated in the guide:

Scrum is founded on empiricism and lean thinking.

Further reading: Scrum Theory

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.

Scrum Teams are definitely not led by managers and they are cross-functional.

It may be surprising that it is wrong to say that Scrum Teams consist of developers and testers. From Scrum's point of view, 'Developer' is a role, not a job, and any specialists are referred to as developers. They can be even testers, however, can be analysts, writers, any professionals.

Further reading: The Scrum Team, Developers

Backlog refinement and stakeholder collaboration are Product Owner responsibilities, the rest is either optional or wrong.

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.

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

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

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 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.

"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 3 pillars are transparency, inspection and adaptation.

Further reading: Scrum Theory

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.

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 Master should not do the job of the Product Owner and the Product Owner should not delegate tasks to the Scrum Master. However, as a coach and mentor the Scrum Master can make sure the communication between the Scrum Team and other organizational units follows good patterns.

The Product Owner is also accountable for effective Product Backlog management. - The Scrum Guide

Since the Scrum Team is self-managing, nobody assigns tasks to the team members.

The Sprint Backlog is under the authority of the Developers of the Scrum Team.

Further reading: The Product Owner

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

Further reading: The Scrum Master

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 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 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

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.