The Scrum Framework has three main components: roles, artifacts, and events. These three components define a way of organizing work to solve complex problems. The roles define accountabilities , making clear who is responsible for various kinds of decision making. The artifacts provide transparency, providing information in support of the decision-making process. The events provide forums within which particular decisions are made.
Scrum is based on the concepts of cross-functional, self-organizing teams using the tools of Empirical Process Control to manage themselves. The five Scrum events are the venues in which the tools of Empirical Process Control are used.
Empirical Process Control relies on the inspection of transparency and adaptation based on the results of that inspection. It is the scientific method in disguise. Scientists performs experiments to make certain phenomena clear, observe the results, and adapt their understanding as a result. The Scrum Framework helps its practitioners do work, observe results, and adapt their strategy and tactics to solve the problems they face.
- 1.
The Sprint: During this event, the product is inspected and the Sprint Increment is created and adapted.
- 2.
The Sprint Planning Meeting : During this event, the Product Backlog is inspected and the Sprint Backlog is created and adapted.
- 3.
The Daily Scrum : During this event, the Sprint Backlog is inspected and the plan for developing the Sprint Increment is adapted.
- 4.
The Sprint Review : During this event, the new version of the product (incorporating all the changes made during the sprint) is inspected and the Product Backlog is adapted.
- 5.
The Sprint Retrospective : During this event, the Scrum Team itself is inspected and its way of working together is adapted.
It is very important to realize that these events support decision making by the participants, so they must be used by people who are able and willing to make decisions. The participants in these events must be empowered and must be accountable.
Product Owners must be empowered to make decisions about the Product Backlog and to negotiate about it with the Development Team. The Development Team members must be empowered to choose their own work and to manage themselves to get it done. Both must accept accountability for their own choices.
When the Product Owner and the Development Team are both empowered and accountable, the tools of Empirical Process Control become quite effective for helping them accomplish their goals. The five Scrum events provide a framework for making decisions in a timely and effective way. They empower decision makers to work together to solve problems. They are essential to success when using the Scrum Framework.
When the Product Owner and/or the developers are not empowered and do not feel accountable, then the tools of Empirical Process Control lose all their effectiveness.
What is the point of a sprint planning meeting when the scope of a sprint has been predetermined by a higher authority? If the Product Owner is constrained by an approved “road map” and cannot change it, what is there to negotiate? If the Development Team is given no choice about what it must work on, what is there for the team members to talk about? Without the ability to make decisions and be accountable for them, the Sprint Planning Meeting is a waste of time
What is the point of a daily scrum if the Development Team feels no accountability for achieving any goals during a sprint? Why should the team get together to make sure it is on track to fulfill a commitment it did not make? If Development Team members make a decision to develop certain features during a sprint, they will find the Daily Scrum to be an essential tool for doing so. If they were given no choice, the Daily Scrum is a pointless exercise.
Many organizations make a serious mistake when trying to implement the Scrum Framework. These organizations try to use Scrum artifacts and events without changing the organization’s internal responsibilities. These organizations have plans and designs drawn up by designers, architects, and other subject matter experts. These plans and designs are then given to developers to follow under the direction and control of a PM. The developers are then expected to use the Scrum artifacts and events to follow these plans successfully. It doesn’t work.
These tools must be used by self-organizing, cross-functional teams. Otherwise, they are worse than useless.
“Time-boxing ”
Scrum events all share two important characteristics. They are all opportunities to make decisions and they all have time-boxes.
Time-boxing is an important concept in the Scrum Framework. Not only does every Scrum event have a specific purpose, it is also associated with a reasonable amount of time within which to serve that purpose.
The longest time-box in the Scrum Framework is the one for the Sprint event. The Sprint may be any appropriate length as long as it is no more than 30 calendar days.
The shortest time-box is the one for the Daily Scrum. The Daily Scrum event should never take more than 15 minutes.
The other events all have time-boxes that are relative to the time-box of the Sprint itself. If a sprint has a time-box of 30 days, then its sprint planning meeting has a time-box of eight hours, the sprint review has a time-box of four hours, and the sprint retrospective has a time-box of three hours. If a sprint is shorter than 30 days, then the time-boxes of these events are correspondingly shorter.
Many people equate these time-boxes to deadlines. They assume that the work of the event must be completed by the end of the time-box or else. Many people shut down events arbitrarily when the time-box has been used up.
It is important to realize that time-boxes are not deadlines. They are reasonable amounts of time for accomplishing the work at hand. If an event takes longer than the time-box to complete, the answer is not to stop the event. The answer is to find out why it is taking so long.
Time-boxes serve the purpose of transparency. They make something clear. If an event runs past its time-box, the “Scrum Police” should not be sent to arrest the team. Instead, the Scrum Master and the Scrum Team should note the event is taking longer than a reasonable amount of time to complete. It is an indication that there is something wrong with the way they are conducting the event.
The Scrum Master should always take note when time-boxes are being exceeded. They are an “early-warning tripwire,” indicating something is wrong.
Something is wrong if the Scrum Team takes longer than eight hours to plan a month-long sprint, more than 15 minutes to understand its daily status, more than four hours to review the results of the sprint’s work, or more than three hours to examine itself and understand what happened. There is also something wrong if it takes longer than expected to complete the work the team itself selects to do during a sprint.
If a time-box indicates something is wrong, it is the responsibility of the Scrum Master to figure out what is out of whack. Scrum Masters are accountable for a Scrum Team’s proper use of the Scrum Framework. They must teach and coach the Product Owner and the Development Team to conduct the events properly so they stay within the time-boxes.
Scrum Masters should not simply stop the event at the end of its time-box. Doing so is similar to turning off a fire alarm after it starts ringing. When the fire alarm rings, it is best to find out what is burning and then put the fire out. Likewise, when an event goes past its time-box, Scrum Masters should find out why, then teach and coach the Scrum Team how to avoid that situation in the future.
Summary
Group decision making can be quite complex if done in an unstructured way. The purpose of the five Scrum events is to provide specific opportunities and venues for making group decisions about specific matters. Each event involves specific decisions that must be made at specific points within the Sprint cycle. This structure is intended to provide focus on the decisions at hand and to help them be made in an efficient way. By encapsulating the decisions within time-boxed events, the amount of time spent on these “overhead” tasks is minimized, freeing up people to spend their time creating the product instead.