PSM I Exam Simulation

"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." - Scrum Guide (2020 version)

"Implement at least one high priority item in the next Sprint" - is what the 2017 guide recommended

Further reading: Sprint Retrospective

The 3 pillars are transparency, inspection and adaptation.

Further reading: Scrum Theory

Openness and respect are both fundamental values in Scrum. The Scrum Master is the mentor of the team and should reinforce positive behaviour. Instead of suppressing or exacerbating conflicts, should facilitate their resolution in a constructive manner.

The request must be rejected since it is against the rules of Scrum. The Scrum Master, as the coach of the team, should explain the reasons, for instance emphasizing cross-functional development, delivery of 'vertical slices', collective ownership, etc.

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

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

Further reading: The Daily Scrum

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

"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 definition of "Done" should cover everything that is needed for a potentially releasable Increment.

If integration testing is needed for that, it should be part of the definition of "Done". Since the definition of "Done" is applied for all backlog items, it means that in our case integration testing is a prerequisite of claiming a backlog item "Done".

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

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

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

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.

The columns of the Scrum board are up to the team. Every team has different circumstances and processes. All listed solutions make sense.

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

Managers should not approach Developers directly with their ideas without having an agreement with the Product Owner. This is against transparency and self-management and undermines the Product Owner's work to maximize the value delivered. A Developer should not silently cooperate but ask to follow the rules.

The Developer should avoid having unnecessary conflicts with a manager. Scrum may provide ways for working on urgent great ideas if they are really urgent and great. This can even include cancelling the running Sprint or re-negotiating its Scope. However, it should happen transparently, thus if the developer can explain this in detail, that solves the problem.

The Scrum Master is a coach, trainer, and mentor for the Scrum Team and the organization, thus, it is always OK to turn to the Scrum Master for advice. The Scrum Master should be able to handle the situation while inexperienced Developers may not.

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

"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

Product Backlog items are not necessarily user stories. A user story is just another optional agile technique from Scrum's perspective.

A user story does not have a mandatory format, though there are some popular templates.

Acceptance criteria are not a mandatory element of the user story.

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.

The Scrum Master is the coach of the team, thus he or she should ensure the rules of the framework are in place and proper, efficient techniques are applied. Reaching this goal may be a longer journey but should start with inspection and fruitful retrospectives.

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

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.

"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

Remember the 'Uses of Scrum' chapter: Scrum is used for developing, sustaining and renewing products.

Scrum is an empirical framework therefore feedback is an asset, not an impediment.

"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 Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide."

Further reading: The Scrum Master

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

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

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

Definition of Ready is an arbitrary technique. When a Product Backlog item meets the Definition of Ready (e.g. refined, estimated, approved, has all details), the team can mark it as ready for Sprint Planning.

The Definition of Done for the Scrum Team is to assess when work is complete on the product Increment. It is not an arbitrary technique. On the other hand, when a Sprint is already running with an anticipated goal, it should not be impeded. The Retrospective is designed to identify potential improvements in team practices.

With increasing the size of the Team, complexity increases, too. Having two teams and a Nexus instead of one team also increases complexity. The guide states that the ideal team size is 10 or less, however, it does not strictly limit the size. The maximum number of people capable of working together efficiently varies depending on the circumstances. Based on scientific experiments, the efficiency = f(size) function does not have a sharp decline strictly at size = 10. Inspect whether 11 works well and adapt.

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

Further reading: The Sprint

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 burndown chart measures the progress of work in a Sprint and can represent all the related metrics. However, it does not represent velocity from Sprint to Sprint.

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.

"Product Backlog refinement [..] is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work." - from the Scrum Guide

The other two offered answers are not to the point.

Further reading: Product Backlog

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

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

While Agile encourages collective code ownership, no one can give strong specialist skills and system knowledge to all Developers. The Product Owner should set his or her expectations accordingly.

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

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.

The Product Owner is also accountable for effective Product Backlog management

The Product Owner

The Work Breakdown Structure is a traditional project management technique.

A Business Requirement Definition is a traditional business analysis document.

Given - When - Then is a template for writing acceptance criteria.

Acceptance criteria is a technique which supports not only testing but also the better understanding of complex or ambiguous requirements.

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

Defined by the Scrum Guide:

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Further reading: Sprint Planning

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

- from the Scrum Guide

Further reading: Sprint Planning

"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 2020 version of the Guide states that one of the Scrum Master serves the organization with "Planning and advising Scrum implementations within the organization."

The 2019 version mentions this among the services to the organization: "Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization."

Learning about the practices used by other teams is the starting point of this activity.

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

Further reading: The Scrum Team

An Increment is a concrete stepping stone toward the Product Goal.

Further reading: The Increment

The Scrum Values are: Commitment, Focus, Openness, Respect, and Courage

Scrum Values

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.

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

"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

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 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 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." It is possible to answer the three common questions and failing to inspect, adapt and plan at the same time.

"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 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 2020 Guide gives us the following instructions:

"The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems."

The 2017 version of the Guide was verbose on the role of the Scrum Master in this. As per the 2020 version we can still infer this from the accountabilities of the Scrum Master.

"The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change."

The bottom line is, stakeholders should be invited to the review which is one of the major formal events for inspection and adaptation.

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.

Let's check the Scrum Guide!

The 2020 version:

"Product Backlog refinement is 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 a description, order, and size. Attributes often vary with the domain of work."

The 2017 version:

"Product Backlog refinement is an ongoing process in which the Product Owner and the Developers collaborate on the details of Product Backlog items. The Scrum Team decides how and when refinement is done."

This would still not eliminate "Tell the Product Owner that there is no such thing as a backlog refinement event in Scrum." - however, the Scrum Master is expected to mentor, coach, serve, advise the Product Owner instead of giving a lecture.

"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

In Scrum, the Development Team is responsible for architectural decisions. One of the recommended approaches is the 'emergent architecture'.

Scrum values (openness, courage) suggest that the Product Owner should be immediately notified. Furthermore the Definition of Done should be taken into account, a security gap is a serious issue for a potentially releasable Increment. If the fix has an impact on the Sprint Goal, the Product Owner and the Developers may have to renegotiate it.

At Sprint Planning it is enough to plan work for the first days of the Sprint. However, setting a Sprint Goal is mandatory.

"The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning." (from the Scrum Guide)

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.

Call-off planning and postpone the Sprint. It is apparent that backlog refinement is needed. - WRONG, since there is no good reason to postpone a Sprint.

Convince the Developers that they should accept one more item. - WRONG, only the Developers are entitled to forecast what they can deliver. Forcing more work would only result in chaos.

Convince the Product Ower to leave the item since the Developers cannot deliver it. - WRONG, since Increments should be potentially releasable/usable. An inconsistent Increment would not meet this criterium.

Facilitate a trade-off between the Product Owner and the Developers. There is a genuine chance to find a solution with which the Increment will be consistent and deliverable in a single Sprint. - CORRECT, the Product Owner and the Developers are expected to make trade-offs during Sprint Planning.

The Sprint Backlog is a plan by and for the Developers.

Sprint Backlog

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

Daily Scrum

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.

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.