Professional Scrum Master I (PSM I)

B. Openness

Openness in Scrum means the Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Lack of communication about dependencies and progress indicates a lack of openness within the Developers, leading to hidden problems.

A. The Product Backlog is not being frequently refined with stakeholders' evolving needs.

Even with a 'Done' Increment, if the Product Backlog isn't frequently refined with evolving stakeholder needs, the 'perceived value' by the Product Owner might diverge from the actual 'critical business needs' as understood by stakeholders. Product Backlog refinement is a continuous process involving collaboration to ensure the backlog reflects the latest understanding of value.

A. The Developers should pull the security fix into the Sprint Backlog and collaboratively re-negotiate the Sprint Scope with the Product Owner to maintain the Sprint Goal.

When unexpected critical work arises mid-Sprint, the Developers, who own the Sprint Backlog, should collaboratively work with the Product Owner. They need to assess the impact, and if necessary, re-negotiate the Sprint Scope to ensure the Sprint Goal remains achievable, or if not, discuss options like Sprint cancellation (a last resort).

C. Work with management to remove the organizational impediments causing the dependencies and access issues.

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. This includes removing impediments to the Scrum Team's progress and helping the organization adopt Scrum. External dependencies and lack of access are organizational impediments that the Scrum Master should address at a systemic level.

D. The Product Backlog

The Product Backlog is the single source of work to be done by the Scrum Team, and the Product Owner is solely accountable for its content and ordering. Direct stakeholder requests to Developers undermine the integrity of this artifact and the Product Owner's accountability.

C. To inspect how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done, and to plan improvements.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Its purpose is continuous improvement, not blame.

A. Remove some Product Backlog Items from the Sprint Backlog in collaboration with the Product Owner.

If the Developers realize they cannot complete the planned work, they should collaborate immediately with the Product Owner. They can then re-negotiate the scope of the Sprint Backlog with the Product Owner, ensuring the Sprint Goal remains the primary focus.

B. The Sprint Backlog for the upcoming Sprint.

Improvements identified during the Sprint Retrospective, especially those with a concrete action plan for the next Sprint, are often added to the Sprint Backlog. This makes them visible, transparent, and ensures the Developers allocate time to implement them alongside other Product Backlog Items.

D. The Scrum Team should update their Definition of Done to include automated testing and plan how to achieve it in upcoming Sprints.

The Definition of Done is a commitment for the entire Scrum Team. If they identify a necessary improvement, they should update the DoD to reflect the desired quality standard and then plan how to achieve that new standard. This might involve dedicating Sprint work to implementing automated testing. The DoD is not owned by a single role, nor is it a separate PBI.

D. Collaborate with the Product Owner to determine if the bug should be added to the Sprint Backlog and how it impacts the Sprint Goal.

The Sprint Backlog is flexible and can be re-negotiated with the Product Owner. While the Sprint Goal should not be endangered, critical issues may necessitate adapting the Sprint Backlog. Collaboration with the Product Owner ensures alignment on priorities and impact.

D. The entire Scrum Team

While the Developers will likely implement the technical solution, the Scrum Guide states that the Sprint Retrospective identifies the most helpful improvements to increase effectiveness. These improvements are added to the Sprint Backlog for the next Sprint. The entire Scrum Team is accountable for creating value and continuously improving, and thus for implementing the agreed-upon improvements.

C. Sprint Retrospective

The Sprint Retrospective is specifically designed for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This includes examining how their process impacts their ability to meet the Sprint Goal.

D. It is not comprehensive enough to ensure a usable and potentially releasable Increment.

A 'Done' Increment must be usable and potentially releasable. If a critical feature is not fully functional and has known bugs, even if code is written and unit tested, it does not meet the standard of 'usable' or 'potentially releasable'. The Definition of Done needs to be comprehensive enough to ensure this quality standard.

A. The Product Backlog; by engaging in more frequent and effective Product Backlog refinement.

The Product Backlog is an ordered list of everything that might be needed in the product. If Developers struggle with understanding PBIs, it indicates insufficient Product Backlog refinement, which is the act of breaking down and further defining Product Backlog items into smaller, more precise items.

C. Refined

A healthy Product Backlog has items that are understood and detailed enough for the Developers to work on. This is achieved through ongoing Product Backlog refinement, which involves adding detail, estimates, and order to items, making them 'ready' for a Sprint.

A. The Product Owner is not adequately engaging with stakeholders and transparently communicating Product Backlog status.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team, which includes effective Product Backlog management and engaging with stakeholders. If stakeholders are surprised, it indicates a lack of transparency or insufficient communication regarding what is being built and why.

C. Focus on improving the clarity and readiness of Product Backlog Items before Sprint Planning.

Ineffective Sprint Planning often stems from an unprepared Product Backlog. If PBIs are not clear, well-understood, and appropriately sized (ready), the team will struggle to forecast work accurately and create a meaningful Sprint Goal. Improving Product Backlog Refinement (an ongoing activity, not an event) is key to better Sprint Planning.

A. Self-management

Self-managing Developers choose how to accomplish the work within the Sprint. This includes coordinating their efforts as a team to achieve the Sprint Goal, not just individual tasks. Picking up new work without considering the Sprint Goal or team's overall progress indicates a lack of collective self-management.

B. It must be usable and meet the Definition of Done.

The Scrum Guide states that an Increment must be usable and meet the Definition of Done. Whether it is released to production or approved by all stakeholders is a business decision, not a mandatory characteristic of a 'Done' Increment itself.

C. The Product Owner

The Product Owner is primarily accountable for maximizing the value of the product resulting from the work of the Development Team. This includes effectively communicating the product's value and functionality to stakeholders during events like the Sprint Review.

B. Empiricism

Scrum is founded on empiricism, which asserts that knowledge comes from experience and making decisions based on what is observed. Asking for fixed, long-term forecasts for complex work goes against the empirical approach, where adaptation based on learning is expected. The events (Review, Retrospective) support empiricism, but the stakeholders' expectation contradicts it.

B. Product Backlog Refinement

Product Backlog Refinement is the ongoing process of adding detail, estimates, and order to Product Backlog items. This activity helps the Developers understand items better, identify dependencies, and uncover technical challenges *before* Sprint Planning, thus preventing late-Sprint surprises.

C. To define the overarching objective for the Sprint, guiding the Developers' work.

The Sprint Goal is the single objective for the Sprint. Although the Product Backlog items selected may be flexible, the Sprint Goal provides focus and coherence, guiding the Developers on *why* they are building the Increment.

A. The Daily Scrum is not focused on the Sprint Goal and progress toward it.

The primary purpose of the Daily Scrum is for the Development Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. Discussing technical implementation details without linking them to the Sprint Goal detracts from this focus and makes it difficult to understand overall progress.

C. Sprint

The Sprint itself is a time-boxed event of one month or less during which a 'Done', usable, and potentially releasable Increment is created. Its fixed length provides regularity and predictability for planning and inspection. Varying Sprint durations indicates a misunderstanding of the Sprint as a time-box.