Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

● For the Product Backlog it is the Product Goal.

● For the Sprint Backlog it is the Sprint Goal.

● For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Developers, or the Scrum Master.

The Stakeholders must be informed in priority of what is happening. There is no point to conduct a Retrospective if there won’t be another sprint.

Usually, the Retro is the last event of the Sprint. However, when the Product Owner decides that the development work is over, there is no need for a Sprint Retrospective. The transition documentation is defined a part of the Definition of Done if that transition documentation is a requirement for the Increment's release.

Burn-down chart shows the evolution of remaining effort against time.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;

● Adapting their plan each day toward the Sprint Goal; and,

● Holding each other accountable as professionals.

The Product Owner employs an iterative, incremental approach to optimize predictability and control risk. As a Product Owner, you have to release a Product to customers/users early and often, in order to find out if you have delivered value for them. This can be done at least every Sprint.

It's not mandatory in Scrum.org to start and end the Sprints at the same time. That makes it much more difficult to manage the whole project. It's not mandatory, because you may need it in certain cases: maybe some teams are working on parts of the project that need longer Sprints (four-week), while others need shorter ones (two-week) for shorter feedback loops.

The Sprint is cancelled only in the case if the Sprint Goal became obsolete.