Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specially designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
The Sprint
The heart of Scrum.
A time-box of one month or less (one-week, two-week, three-week, four-week Sprint).
Done, usable, shippable, potentially releasable product increment is created.
New Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During Sprint:
No changes are made that would endanger the Sprint Goal
Quality goals do not decrease
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.
Sprint cancellations consume resources, and are often traumatic to the Scrum Team, and are very uncommon.
Sprint planning
Maximum of eight hours for a one-month Sprint.
Topic One - What can be done this Sprint?
The Development Team work to forecast the functionality that will be developed during the Sprint. The Product Owner discuss the objective that the Sprint should achieve and the Product Backlog Items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
Product Backlog
The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Topic Two - How will the chosen work get done?
The Development Team decides how it will build this functionality into a "Done" product increment during the Sprint.
The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
Daily Scrum
15-minute time-boxed event.
Is held at same time, same place to reduce complexity.
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, The Scrum Team and stakeholders collaborate about what was done in the Sprint.
The presentation of the Increment is intended to elicit feedback and foster collaboration.
Four-hour meeting for one-month Sprints.
The Sprint Review includes the following elements:
Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
Three-hour meeting for one-month Sprints.
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process and tools.
Identify and order the major items that went well and potential improvements
Create a plan for implementing improvements to the way of Scrum Team does its work.
All events in Scrum are time-boxed events.
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specially designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
The Sprint
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.
Sprint cancellations consume resources, and are often traumatic to the Scrum Team, and are very uncommon.
Sprint planning
Topic One - What can be done this Sprint?
The Development Team work to forecast the functionality that will be developed during the Sprint. The Product Owner discuss the objective that the Sprint should achieve and the Product Backlog Items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
Product Backlog The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Topic Two - How will the chosen work get done?
The Development Team decides how it will build this functionality into a "Done" product increment during the Sprint.
The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
Daily Scrum
15-minute time-boxed event.
Is held at same time, same place to reduce complexity.
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, The Scrum Team and stakeholders collaborate about what was done in the Sprint.
The presentation of the Increment is intended to elicit feedback and foster collaboration.
Four-hour meeting for one-month Sprints.
The Sprint Review includes the following elements:
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
Three-hour meeting for one-month Sprints.
The purpose of the Sprint Retrospective is to: