From the 2020 Scrum Guide, we know that “Sprints are the heartbeat of Scrum, where ideas are turned into value.”

Sprint Duration:
The length of the Sprint is fixed and less than 30 days – most commonly used duration is 2 weeks. Once chosen, the duration remains the same.  Extending the Sprint is discouraged as it will affect the consistency, predictability, and commitment. The Sprint ends when the Time-box ends like a clock. The consideration of extending the Sprint usually comes up when a team find that they cannot complete the work they planned for the Sprint. By not extending, the team tend to learn to plan better the next time. Take this as an opportunity to learn why they are not able to complete the work they selected? Reasons could be overcommitment, pressure from the organization to pick up more work, etc.

Determining the amount of Work:
The Scrum Team collaboratively decides how much work goes into a Sprint. Developers have the final say, considering, size of the product Backlog items considered to be included, their past performance, upcoming capacity, and the Definition of Done. Input about what needs to be included, primarily comes from the Product Owner.

Tracking Work During the Sprint:
One common question is, "Who keeps track of the Sprint Burndown Chart?" The Sprint Burndown Chart serves as a progress tracking tool for the Sprint. Developers collectively track their work to meet the Sprint Goal, with the Scrum Master offering support. Therefore, the primary responsibility is on the developers. If they are using a tool like Sprint Burn Down chart, It is developers who are primarily responsible. The Scrum Master can provide assistance, but the crucial question is whether the developers are dedicated enough to ensure they are on track for the work they selected. It's essential to remember that the Scrum Master is not a taskmaster but rather a helper and guide.
As a Scrum Master if you see that you are more concerned about the progress made in the Sprint than the developers, then your job as a Scrum master is to inquire why the developers are not concerned. Is there an organization structure that is affecting the commitment of the developers individually and collectively as team? Is the team not familiar with self-management? This is something to be discussed at the retrospective. Scrum Master has the responsibility to help the team become a self-managing team.Ultimately, it is the developers who are accountable, and if they are not, the Scrum Master's role is to investigate why and help them become a self-managing, focused, and committed team.
Adding Items to the Sprint:
Developers can add work to the sprint backlog if it aligns with the Sprint goal. Others will be requested to wait until the current Sprint ends and asked to request the Product Owner for prioritization. Unexpected events (like a high impact production issue) can lead to the team being redeployed. It is a good idea to discuss this event in the retrospective meeting to decide how a situation like this can be handled in the future. 


Further Reading:
 The Scrum Guide 2020

According to the 2020 Scrum Guide where Scrum is defined, “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”. Scrum is most suitable for product development that lack clear definition or comprehension with the definition of product and the work involved in making the product. We call this type of work complex product development. In these cases, new information can emerge at any time. Scrum enables the flexibility to change direction without wasting effort. While it's possible to use Scrum for routine repetitive, and predictable work, its benefits and costs in such cases may be questionable. We call this type of work simple product development. For simple product development, upfront detailed planning is possible and following the plan will be adequate to reach the goal.

In order to asses the complexity, one needs to look how much of the product is know/unknown and how much of the skills to create the work is known/unknown. We also need to look at the environment the product belongs to that can change the need or the product itself. The unknowns in all these areas will affect how much of the work can be predicted upfront. If the work you are undertaking in unpredictable, crating a detailed plan upfront and sticking to it will be both waste of time and possibly end up creating a product that is unsuitable for the changed environment. In a complex product development, the issue at hand has never been previously resolved, and a solution has never been devised, which means there's no established formula to rely on. In these cases, an empirical process control will be better suited. Scrum provides a simple and adaptable framework based on empiricism. It’s iterative incremental way of working help to produce small incremental value, inspect it and adapt as needed.

Scrum or an adaptive process is NOT necessary if simple or complicated product development. In Simple product development, most of the elements are known and an upfront plan can be made. In a complicated product development, about 70% about the product and the work very well defined.  In the case of Complicated product development, with some amount of work upfront, a good plan be created and then be followed to build the product.
Example of simple product development: The table I am using right now was bough on Amazon. It was 5K positive reviews which might means that about 5K people built it successfully by following the instructions just as it is on leaflet that came with it in the box. I don’t really need an iterative incremental process for building that table. And example of a complex product development: The work of building a mobile App such as Uber in 2007-2010 was a complex product development for many reasons including 1) the customers were new to this way of service. 2) The technology was new.

There are a few models available to asses the complexity. Two of them are Dr. Ralph Stacey’s work (Stacy Matrix) on complexity and Dave Snowden’s work know as Cynefin framework.

Scrum operates as an adaptive process primarily suited for handling complex product development. However, its effectiveness hinges on the organization's willingness to embrace changes in plans. Several factors may influence this stance. For instance, some organizations may resist change because they perceive no immediate need for it. An organization's core objective is to efficiently complete its tasks, and if it firmly believes that traditional processes are vital for its operations, Scrum may not offer discernible benefits to anyone involved.
​
Scrum practices are rooted in the principles of empirical process control, relying on adaptation for both product and process improvements. The crucial elements of inspection and transparency are essential for facilitating adaptation. If an organization lacks transparency due to various reasons or if the organizational culture and environment do not foster a safe space for transparency, the empirical process control, and consequently, the framework will not be useful.


Further Reading:
Cynefin framework by  David Snowden
Dr. Ralph Stacey’s work (Stacy Matrix) -  Ralph Stacey's Agreement & Certainty Matrix