Frequently asked Questions about Sprint

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