Free Scrum PSM-I Practice Exam with Questions & Answers | Set: 9

According to the Scrum Guide1, self-organization is one of the essential characteristics of Scrum Teams. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Self-organization enables teams to deliver faster and better results by harnessing their creativity and skills. Some benefits of self-organization are:

• Increased creativity, as team members have more freedom and autonomy to explore new ideas and solutions.
• Increased self-accountability, as team members take ownership and responsibility for their work and outcomes.
• Increased commitment, as team members are more engaged and motivated by having a say in how they work.

The other options are not benefits of self-organization, as they may imply external control or pressure.

References: Scrum Guide

The Scrum Master should ask the person to share the issue with the team as soon as possible, as stated in [5]: “The Scrum Master should encourage transparency and collaboration within the team and with other stakeholders. If there is a concern about data security issues, it should be brought up to the team and discussed openly. The team can then decide how to handle it, whether by creating a Product Backlog item, updating the definition of “Done”, or taking some other action.”

According to the Scrum Guide1, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is accountable for maximizing value resulting from work by Developers. The Product Owner is also accountable for effective Product Backlog management, which includes:

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

Therefore, the Product Owner is responsible for clearly expressing Product Backlog items.

References: Scrum Guide

If the Development Team cannot complete its work by the end of the Sprint, then the Sprint length holds and the Development Team continuously learns what is actually possible to do within a Sprint of this length, as stated in [7]: “If a Development Team determines it has overcommitted itself for a Sprint, one option is to collaborate with the Product Owner to negotiate removing or reducing scope. Another option is to simply work hard and do its best, without cutting quality or pressuring individuals. In either case, the Development Team learns from its experience and uses this learning when planning future Sprints.”

According to the Scrum Guide1, the Sprint Review is an informal meeting at the end of the Sprint, where the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on what to do next. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”; the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved; and the Development Team demonstrates the work that it has “Done” and answers questions about the Increment. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning. The Sprint Review is mainly an inspect and adapt opportunity for the Scrum Team and stakeholders.

References: Scrum Guide

The Product Owner is responsible for engaging the stakeholders, as stated in the Scrum Guide1: “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.”

The correct answers are B and E, because Scrum has no “tester” role and everyone in the Development Team is responsible for quality. The Scrum Guide states that “the Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”

The correct answer is D, because there is no gap between Sprints in Scrum. The Scrum Guide states that “a new Sprint starts immediately after the conclusion of the previous Sprint.” Therefore, there is no time required after a Sprint to prepare for the next Sprint.

According to the Scrum Guide, management external to the Scrum Team is not involved in the Daily Scrum at all. The Daily Scrum is an internal event for the Development Team to inspect their progress toward the Sprint Goal and plan their work for the next 24 hours. The other options are not valid ways for management to be involved in the Daily Scrum, as they are either intrusive (such as giving an update or speaking on behalf of others) or unnecessary (such as being represented by the Product Owner or the Scrum Master).

According to the Scrum Guide1, there is no such thing as a Release Sprint in Scrum. A Release Sprint implies that there are other Sprints that don’t produce a potentially releasable Increment, which violates the core principle of Scrum. Every Sprint should result in a “Done”, useable, and potentially releasable product Increment.