Non-functional requirements should be visible and transparent to the entire Scrum Team and stakeholders. Adding them to the Product Backlog ensures transparency as the Product Backlog is a constantly updated and visible artifact that everyone can see. This helps to keep track of non-functional requirements and their priorities. Including non-functional requirements in the definition of 'Done' ensures that these requirements are addressed during each sprint and not overlooked, maintaining the product’s quality consistently.

In Scrum, a new Sprint starts immediately after the conclusion of the previous Sprint. There is no break required between Sprints. This continuous flow is essential to maintaining the momentum and ensuring that work progresses smoothly. The Sprint Planning meeting, which initiates the next Sprint, begins right after the previous Sprint ends.

In a situation where the Product Owner and Developers cannot fully understand the highest order Product Backlog items, two primary actions should be taken. First, the team should forecast the items most likely to meet the Sprint Goal and begin development work. This allows progress to start while further decomposing and analyzing items during the Sprint as needed. Second, it is important to discuss why this issue occurred during the next Sprint Retrospective to identify any process improvements or changes needed to prevent a recurrence. These actions ensure the team can proceed with the Sprint while also addressing any underlying issues in their planning process.

The Product Owner is the only person who has the authority to cancel a Sprint if the Sprint Goal becomes obsolete. This can happen if there is a change in direction or objectives that makes the current work in the Sprint no longer valuable. The Scrum Master, the Scrum Team, and the Stakeholders do not have the authority to cancel a Sprint.