Professional Scrum Master II Free Sample Questions

Reporting on the performance of the Sprint.

The way Scrum is understood and enacted within the organization.

Managing the capacity and utilization of each Development Team member.

Managing the process in which Scrum is applied.

Managing the Product Backlog items and work in the Sprint Backlog.

Removing organizational impediments that limits the team’s progress and productivity.

It is easier to compare the performance between cross-functional teams in order to identify to which teams to assign tasks and which teams need additional coaching.

Newly formed teams will need time to stabilize before reaching their peak performance. During the initial stages of forming, performance will suffer and productivity may be low, although even then delivery of business value is still likely to increase.

Without feature teams, you cannot do Scrum. Postpone Scrum adoption until the teams are reorganized in feature teams.

People from the different layers and components will need time to become accustomed to working and delivering unified functionality together as one Scrum Team thus productivity may suffer.

In the next Sprints, the Development Team strives to make the selected work as close to ‘done’ as possible and at the minimum 90% completed. Any undone work is divided into new Product Backlog Items that will be deferred to the last Sprint in order to maintain stable velocity.

The Development Team informs Paul that the progress he has perceived to date is not correct.
The Increment is not releasable. They give Paul their estimate of the effort it would take to get the previous work ‘done’, and suggest doing that work first before proceeding with new features. The team also re-estimates the effort to make the remaining Product Backlog items ‘done’, including all integration effort. In the end, it is Paul’s call to continue the project or to cancel.

The Scrum Master will manage the Sprint Backlog and assign work to the Development Team members to ensure maximum utilization of each member. He/she will keep track of unused resources so that it does not impact the budget. Unused budget can be allocated for additional Sprints if needed.

The Scrum Master sets the open work aside to be performed in one or more release Sprints. They remind Paul to find funding for enough Release Sprints in which this remaining work can be done.
Up to one release Sprint per three development Sprints may be required. It is Paul’s role to inform users and stakeholders of the impact on the release date.

Ask Paul to stop attending the Daily Scrum.

Coach Paul and Development Team members on the purpose of the Scrum events and let them figure out what to do in this situation.

Allow the Paul to participate in the Daily Scrum as he is responsible for the success of the product.

Facilitate the Daily Scrums to avoid any conflicts between the Development Team members and Paul.

Reject the decision as the long term maintainability of the product will be negatively impacted by modifying the Definition of Done.

Accept the decision as a mutual agreement has been made between the Development Team and the Product Owner.

Ask the Development Team and the Product Owner what problem they are trying to solve by altering the Definition of Done and removing regression testing from it. In what ways will this decision impact transparency and quality?

Ask the Development Team and the Product Owner if they are still able to produce potentially shippable product increments by altering the Definition of Done?

The Scrum Master has not ensured transparency.

The project plan proposed to the sponsors at the start of the project followed stringently.

The Product Owner has not been engaging with sponsors frequently enough and has not been kept aware of the overall progress of the project.

The sponsors haven’t been using the Sprint Reviews to actively engage, and inspect and evaluate progress.

The scope changes have not been tracked adequately and the change request process has not been followed properly.

The stakeholders have not been using the Daily Scrum effectively to track the Development Team’s progress.

The Scrum Master has not ensured transparency.

The project plan proposed to the sponsors at the start of the project followed stringently.

Manage the items in the Sprint Backlogs so that Dan can be utilized evenly for each team.

Assign Dan to the team with the most urgent tasks first and then move him to the next team and so on until the required support is completed.

Facilitate a discussion with all Development Teams on how they want to deal with this issue, and help them implement their preferred solution.

Ask Dan to work with the HR department to recruit and hire additional database specialists. In the meantime, have the Product Owner move items that do not depend on Dan to the top of the Product Backlog.

Each Scrum Team has its own Product Backlog with items only their team will be working on.

One Product Backlog to represent all of the known work needed to be done for the product.

Three Product Owners, one for each Scrum Team.

Having one Product Owner to be accountable for maximizing the flow of value throughout the development process and provide transparency on the overall progress.

Impediments are raised and resolved more slowly.

Opportunities to inspect and adapt the Sprint Backlog are reduced.

Less information about the progress will be shared causing the Sprint plan to become inaccurate and reducing transparency over progress toward the Sprint Goal.

The Scrum Master loses the ability to update the burndown chart adequately.

The Product Owner cannot accurately inspect utilization of the individual team members.

Each Scrum Team delivers Increments in its own code branch. After UAT is performed at the Sprint Review, the code branch is isolated until enough Increments are considered acceptable. All code branches will then be merged during the release phase.

Each Scrum Team delivers functionality at the end of each Sprint. New Product Backlog items will then be added to the next Sprint Backlog to integrate their functionality with the other teams to create a unified Increment.

All Scrum Teams agree on a mutual understanding of ‘done’ that defines all work necessary to deliver a potentially shippable Increment that includes all previous Increments delivered for the product.

Wait until enough of the infrastructure and architecture is in place before starting the first Sprints.
This will increase the success of delivering integrated Increments in Sprint 1.