Professional Scrum Master I Free Sample Questions

Yes, but only for Scrum Teams whose work has dependencies.

Yes, otherwise the Product Owners (and stakeholders) may not be able to accurately inspect what is done.

No, each Scrum Team stands alone.

No, that is far too hard and must be done in a hardening Sprint.

It can’t. Only Product Owners can cancel Sprints.

When functional expectations are not well understood.

When the Product Owner is absent too often.

When the selected Product Backlog items for the Sprint become unachievable.

When a technical dependency cannot be resolved.

The Sprint Backlog.

The Sprint Goal

The release plan.

Sprint Review minutes.

Ensure every Increment meets them.

Make sure the release department understands these requirements, but it is not the Development Team’s responsibility.

Handle them during the Integration Sprint preceding the Release Sprint.

Assign them to the lead developers on the team.

When the Product Owner says it is done.

When all Product Backlog items meet their definition of “Done".

When all the tasks are completed.

When the time-box expires.

True

False

Put them on a separate list on the Scrum board, available for all to see.

Add them to the Product Backlog and keep the Product Owner posted on the expected effort.

Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint.

Add them to the definition of “Done" so the work is taken care of every Sprint.

The break between Sprints is time-boxed to 1 week for 30 day Sprints, and usually less for shorter sprints.

Enough time for the requirements for the next Sprint to be determined and documented.

Enough time for the Development team to finish the testing from the last Sprint.

None. A new Sprint starts immediately following the end of the previous Sprint.

All of the above are allowed depending on the situation.

Cancel the Sprint. Send the entire team to an advanced Scrum training and then start a new Sprint.

Forecast the most likely Product Backlog items to meet the goal and create a Sprint Backlog based on a likely initial design and plan. Once the time-box for the Sprint Planning meeting is over, start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint.

Continue the Sprint Planning meeting past its time-box until an adequate number of Product Backlog items are well enough understood for the Development Team to make a complete forecast. Then start the Sprint.

Discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur.

Ask everyone to take as much time as needed to analyze the Product Backlog first, and then reconvene another Sprint Planning meeting.

What to do and who will do it.

How conditions have changed and how the Product Backlog should evolve.

What can be done and how to do it.

What went wrong in the last Sprint and what to do differently this Sprint.

Who is on the team and what team member roles will be.