The Sprint is a container for all other events… Sprints are the heartbeat of Scrum, where ideas are turned into value. - Scrum Guide
Because Scrum is an incremental and evolutionary development process, it uses consecutive short periods to build a product, Increment after Increment, and frequently inspects and adapts both the product and the process used. These limited-time periods, in Scrum, are identified as Sprints.
All of Scrum events such as Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective events, and all the work that needs to be done to transform PBIs into an Increment happens within a Sprint.
In general, Scrum recommends a Sprint duration of one month or less, with one or two weeks being the most commonly found.
One of the decisions you must make when starting a product development or adopting Scrum is how long Sprints will be. Afterward, you will keep that duration constant over time, which means that a Sprint duration does not change once it has been established. An exception to this rule would be those situations where the team itself decides to try longer or shorter sprints. This decision is mainly based on the volatility of the context: the more volatile it is (changing business, unknown needs, evolving technology, etc.), the shorter the duration of the Sprint. The critical concept to remember is that greater rhythm and predictability are achieved by having Sprints last the same throughout the product development.
Fixed Duration and Goal
During a Sprint, the Scrum Team could be behind or ahead in their work. In this circumstance, the adjustment variable will be the scope of the Sprint, never its duration. This means that if the Scrum Team anticipates that it will have to increase the Sprint’s scope by adding new PBIs and/or reduce it in the event of experiencing a delay, it must never shorten or extend the duration of the Sprint. The power to decide whether to increase or reduce the scope of the Sprint lies within the Scrum Team, and it is, therefore, made between the Developers and the Product Owner.
As mentioned earlier, the Sprint Backlog contains the Sprint plan. As progress is made and the Team experiences discovery and learning during the Sprint, the Sprint plan could be altered without altering the Sprint Goal. Changes to the plan are managed by the Developers.
Non-negotiable Quality
From everything explained before, you could deduce that quality is never negotiable in the face of unforeseen events or impediments. The level of quality of the Increments is determined by what we have called the Definition of Done, which is not altered throughout the project. This means that if the Scrum Team falls behind concerning what it has to deliver, it will never test less or build with lower quality to deliver everything planned in the Sprint. A negotiation space will be called within the Scrum Team where Developers and Product Owner will decide how they adjust the scope without affecting the Sprint Objective or the Definition of Done.
Remember, the Scrum Team is committed to building an Increment that achieves the Sprint Goal while respecting the Definition of Done. The Scrum Team should never commit to delivering a set number of PBIs.
Sprint Progress
Progress during the Sprint is observed day by day by the Developers. There is a daily event that I will discuss later, the Daily Scrum, where Developers reviewed if the current status of the work carried out leads towards the achievement of the Sprint Goal. In case that is not the case, the Developers decide to adapt the remaining Sprint plan to get closer to achieving the goal again.
Sprint Cancellation
A Sprint can be canceled if the Sprint Goal becomes stale or obsolete. This happens when the environmental conditions change so drastically that it no longer makes sense for the Scrum Team to keep working on what they are working on and need to move their attention to something much more important.
As mentioned before, realizing that the Sprint work is not completed and will likely not be finished is not a valid reason for canceling the Sprint since by even building an Increment that is smaller than expected, the Sprint Goal could be achieved. The cancellation of a Sprint is a decision that only the Product Owner can make.