PSM I Exam Simulation

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

"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

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.

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 Scrum Team may also invite other people to attend Sprint Planning to provide advice."

- from the Scrum Guide

Further reading: 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.

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

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.

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

"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

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

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

Further reading: Scrum Theory

"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

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)

"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

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

Story points are estimates. Velocity is based on estimates and has a variance. We can use velocity to estimate the number of Sprints needed - but it is an estimation, only.

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.

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 the historical truth and even included in the Scrum Guide.

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

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

Scrum Values

Talking about impediments only makes sense when there are impediments. It is OK not to mention any.

While the Developers may meet right after the Daily Scrum, they do not have to. They may not need it on a given day or they may meet at another time.

Tracking Sprint progress is the responsibility of the Developers. If metrics are not available at Daily Scrum, they will not even know if there is a need for replanning. Though answering the 3 questions takes the team closer to this goal, it is hardly enough alone.

In agile, we usually call the timebox an iteration and the outcome an increment. This is because the two approaches can be combined with synergy and used in this format in agile invariably. However, iterative development does not have to deliver increments at all. It simply means that features, functions, components are evolving from iteration to iteration, as more is learned about the nature of the product.

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

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

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

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.

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

Further reading: The Daily Scrum

"Removing barriers between stakeholders and Scrum Teams."

- from the Scrum Guide

Further reading: The Scrum Master

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

Further reading: The Sprint

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

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.

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

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.

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.

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

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

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

Further reading: The Scrum Master

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

Velocity is calculated from estimations and estimations are peculiar to a given team. Two teams may apply utterly different estimation techniques.

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

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

"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

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

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

"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

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.

As stated in the guide:

Scrum is founded on empiricism and lean thinking.

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.

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.

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

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

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.

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.