The Sprint is time-boxed to 30 consecutive calendar days. Aside from other factors, this is the amount of time required for a Team to build something of significant interest to the Product Owner and stakeholders and bring it to a state where it is potentially shippable. This is also the maximum time that can be allocated without the Team doing so much work that it requires artifacts and documentation to support its thought processes. It is also the maximum time that most stakeholders will wait without losing interest in the Team’s progress and without losing their belief that the Team is doing something meaningful for them.
The Team can seek outside advice, help, information, and support during the Sprint.
No one can provide advice, instructions, commentary, or direction to the Team during the Sprint. The Team is utterly self-managing.
The Team commits to Product Backlog during the Sprint planning meeting. No one is allowed to change this Product Backlog during the Sprint. The Product Backlog is frozen until the end of the Sprint.
If the Sprint proves to be not viable, the ScrumMaster can abnormally terminate the Sprint and initiate a new Sprint planning meeting to initiate the next Sprint. The ScrumMaster can make this change of his or her own accord or as requested by the Team or the Product Owner. The Sprint can prove to be not viable if the technology proves unworkable, if the business conditions change so that the Sprint will not be of value to the business, or if the Team is interfered with during the Sprint by anyone outside the Team.
If the Team feels itself unable to complete all of the committed Product Backlog during the Sprint, it can consult with the Product Owner on which items to remove from the current Sprint. If so many items require removal that the Sprint has lost its value and meaning, the ScrumMaster can abnormally terminate the Sprint, as previously stated.
If the Team determines that it can address more Product Backlog during the Sprint than it selected during the Sprint planning meeting, it can consult with the Product Owner on which additional Product Backlog items can be added to the Sprint.
The Team members have two administrative responsibilities during the Sprint: they are to attend the Daily Scrum meeting, and they are to keep the Sprint Backlog up-to-date and available in a public folder on a public server, visible to all. New tasks must be added to the Sprint Backlog as they are conceived, and the running, day-to-day estimated hours remaining for each task must be kept up-to-date.