Defining Scrum Events

Scrum implements its iterative workflow via a series of Scrum Events. These events support the three foundational underpinnings of Scrum: transparency, inspection, and adaptation. In other words, events provide visibility at key points of the Scrum process, offering opportunities to inspect the progress of the work and the delivery and value of the increments. If any aspect of the project places the Sprint Goals at risk, the team can adapt their work and strategies to either fix the problems or optimize the outcomes.

As an analogy, the driver of a car cannot merely set their wheels in a set direction and expect the car to stay on the road. The driver must have clear visibility to continuously inspect the trajectory of the car against the variations in the road and terrain, and then adjust their steering and acceleration to keep the car on the track. Likewise, the Scrum Team must continuously inspect and adjust its trajectory against the Product Backlog and Sprint Goals.

Let's continue for a moment with this analogy. A driver can review maps and create a detailed plan describing all the locations where they want to go, places where they want to eat, sleep, and get gas, the roads that the drivers must follow, the turns that they need to make, and speed limits along the route for an upcoming trip. Once they start the trip, reality sets in. They may encounter road construction, bad traffic, unfavorable weather conditions, unexpected points of interest, and a host of other factors that will change the outcome of their trip from the initial plan. The driver continually adjusts their plan as they encounter these unexpected conditions. They may also add or delete stopover points or pitstops based on their current personal needs.

This empirical process is precisely how software development works in Scrum. The world is full of complexity and unknown probabilities. The astute team knows that change is the norm and not something to be fought. With that in mind, let's look at how Scrum Events provide opportunities for us to observe, inspect, and adapt a Scrum Team's activities to maximize their outcome, given the conditions they face along their journey to deliver a high-value product.

Scrum Events include Sprints, Sprint Planning meetings, Daily Scrum meetings, Sprint Review meetings, and Sprint Retrospective meetings. The next five sections describe the Scrum Events under the same names.

Sprints

Scrum employs an iterative development strategy that breaks up life cycle development work into relatively small and frequent intervals. The necessary interval of Scrum is anywhere from 1 week to 30 days, with the norm following into 1-week to 2-week intervals. During the Sprint, the team works on a subset of the Product Backlog that represents the current high-value priorities, called the Sprint Backlog.

The development team self-organizes to assign work tasks to individual members, usually based on their skills and availability. For example, if someone has previously worked on a similar development task, they might be assigned the new task to reduce the time and effort to understand the problem, develop the approach, and implement the functionality. Sometimes, a task might be assigned to more than one team member if the feature is unusually large. Or, the teams may employ paired programming techniques that allow members of the team to work side by side, leveraging both their skills and knowledge to build, inspect, and adapt each segment of code in conformance with their definition of Done:

Figure 2.1 – Traditional graphical model of a single Sprint within the Scrum framework

The preceding diagram graphically depicts a single Sprint within the Scrum Framework. The graphical model starts with the Product Backlog, which is owned by the Product Owner. Before the Sprint can start, the development team must decide what the goals for the upcoming Sprint are, as well as the work they must accomplish. The Sprint Team conducts a Sprint Planning session to define the work they can accomplish from the prioritized Product Backlog, as they must also define the work tasks that are necessary to produce the Product Backlog Items. The PBIs and tasks collectively form the Sprint Backlog.

The current iteration begins, and the Scrum Team meets daily to provide visibility on their progress and to bring attention to any impediments that may cause delays. Any issues are taken offline in working sessions to address these problems. The Scrum Master may facilitate the Daily Scrums and other meetings, and they assist in resolving the impacts from identified impediments.

At the end of each Sprint, the outcome is a Potentially Shippable Product that meets its definition of Done for this Sprint. The definition of Done is a shared understanding by the Product Owner and team members of what the final state of a new incremental slice of functionality must have. In addition to achieving the customer's desired functionality, the definition of Done for each feature must also conform to the organization's standards, conventions, and guidelines.

Increments do not meet the definition of Done until the Scrum Team implements all desired capabilities, thereby meeting all acceptance criteria. Ultimately, only the Product Owners, customers, and end-users must decide whether the product meets the definition for the release and whether other items need to be added to the Product Backlog. The Sprint Reviews provide an opportunity to demo and get feedback on the product.

The last Event within a Scrum Sprint is the Sprint Retrospective. All Scrum Team members attend the Retrospectives to discuss the areas that they can improve in the next Sprint.

Now that you understand the Events associated with each Scrum Sprint, let's take a closer look at the activities involved with each Event, starting with Sprint Planning.

Sprint Planning

The development team gets together with the Product Owner at the beginning of each Sprint to inspect and adapt the Product Backlog. They do this to focus on the highest priority requirements. The Sprint Planning meeting is timeboxed limited to approximately 2 hours for every week of Sprint duration. So, if your Sprints have a 2-week duration, the Sprint Planning meeting should be limited to about 4 hours.

Though organizational stakeholders will express their preferences regarding feature priorities, the Product Owner is always the final authority on any changes to the Product Backlog; for example, additions, deletions, and changes in priorities. The reason for this is that the Product Owner is an independent and business-oriented authority who can look across all functional and non-functional requirements and accurately assess backlog priorities in terms of the highest value and return on investment.

Going back to the 80/20 rule, as discussed previously in this chapter, the highest value features form a relatively small subset of the features described within the Product Backlog. It makes no sense to work on the lower 80% of product features, which collectively require a much larger work effort when the customer only places value on the top 20% of the features contained within the Product Backlog. Yet, the traditional model forces the team to place equal value on the entire set of requirements. The Sprint Planning process helps the team avoid that type of error in thinking.

The Sprint Planning meeting has two objectives. First, the team must evaluate what they can deliver in the upcoming increment in terms of functionality. Second, the team must decide how they will build the functionality of the increment. These questions are answered in parallel during the Sprint Planning meeting, not sequentially.

To support the first objective, the Product Owner discusses their goals for the Sprint in terms of implemented functionality for the increment. An increment may include one or more features, depending on complexity. Similarly, features specified within the Product Backlog may have one or more Stories that define the requirements.

Unless the development team is just starting on a new product development effort, with few identified requirements, it's highly likely the 20% of high-value features in the Product Backlog represents more work than the team can get done during an upcoming Sprint. Working with the Product Owner, the development team evaluates the functional and non-functional requirements in terms of difficulty.

The team may use a game-based assessment strategy, such as planning poker, to assign points representing the degree of difficulty for each of the highest priority backlog items. Likewise, a mature development team will have tracked, over several Sprints, the average number of points of work they can complete within a Sprint. With these two pieces of information, the team can determine how much work they can complete in the upcoming Sprint.

An important note to make here is that only the development team can decide how much work they can accomplish within the upcoming Sprint. Executive Managers, Customers, Product Owners, and Scrum Masters have no say in the matter, as they are not responsible for completing the work. Forcing their will won't change the outcome and simultaneously undermines the team's ability to do good work. In fact, by adding work in progress beyond the team's capacity to deliver, those individuals may introduce inefficiencies that further delay the release of the desired functionality.

In support of the second objective, the development team must analyze the functional requirements to determine the best approach to build the product. The development team evaluates the functional requirements and comes up with an initial design or design enhancement. The team further analyzes the work to come up with a series of work necessary to build the features. Those work tasks form the Sprint Backlog. Once the tasks have been defined, the team self-organizes by assigning work tasks to individuals or groups within the team in the upcoming Sprint.

The deliverable of the Sprint Planning process is the Sprint Goal. Although the Product Owner is the first to specify the goals of the Sprint, it's the development team that refines the parameters of the Sprint Goal through the Sprint Planning process.

The Sprint Goal defines the increment of functionality from the Product Backlog that is the focus of the upcoming Sprint. However, rather than focusing on discrete backlog items, the objective of the Sprint Goal is to provide an abstraction that helps the individual members understand the purpose of their work as a team on this Sprint. Thorough inspection and adaption across the Sprint, the team's approach to supporting the goal may change, and not the goal itself. If the inspection activities indicate the scope of work is different than initially conceived, the team can negotiate with the Product Owner to re-specify the scope of work that's pulled from the Product Backlog.

With the completion of Sprint Planning, the team needs to make sure they keep track of their completed work, evaluate the team's progress against their goals for the Sprint, and identify and remove any impediments that are causing problems. The team discusses these three elements as a review of the Sprint's progress during their daily Scrum meetings.

Daily Scrums

The development team meets daily to plan their work for the next 24 hours. Teams hold their daily Scrums in the same location, at the same time every day, and are timeboxed limited to 15 minutes. Each member of the team always answers the following three questions:

The development team members must understand that they cannot just work on anything that interests them. They must stay focused on work that supports the Sprint Goals that have been agreed to by the development team. While the team members work against specific tasks from the Sprint Backlog, they must remain cognizant and focused on how they will meet the definition of Done most expediently.

The daily Scrum is a perfect example of an event that provides visibility to the work of the project in terms of the project's goals, and the ability to inspect and adapt when things appear to be going awry. Also, the information provided in meetings may indicate that additional discussion and planning is required. The affected team members will meet separately so that the other team members can get back to their work. Non-value-added meetings is another form of waste to avoid.

The Scrum Master may facilitate daily Scrum meetings, but they cannot dictate the team development priorities. Instead, the Scrum Master's primary role is to help the team stay focused on the Daily Scrum agenda. The Scrum Masters also helps ensure the team stays within the 15-minute timebox duration limit. The team must take any lengthy discussions or work on any impediments that are getting in the way of the team's ability to complete its work offline. For example, if the team needs access to a domain expert to understand the requirements of a feature, the Scrum Master would help organize and schedule that meeting or call.

In the interest of transparency, Scrum meetings are open to other attendees, such as the Product Owners, executive sponsors, customers, and other stakeholders. However, beyond listening, they cannot participate in the daily Scrum meetings, and the Scrum Master must make sure that they do not interrupt the meetings.

The team must provide complete transparency regarding the progress of their work and any impediments on an ongoing basis. These daily Scrum meetings help ensure ongoing transparency by providing snapshots of information on work progression over short time intervals during the Sprint.

However, at the end of each Sprint, the team needs to demonstrate their work and receive feedback on how well the new increments of product functionality support the identified requirements, as well as review the identified items and priorities established within the product backlog. That is the purpose of the Sprint Review meetings that occur at the end of each Sprint.

Sprint Reviews

At the end of each iterative Sprint cycle, the development team reviews their work to demonstrate completion of the new increment in conformance with their definitions of done. As a rule of thumb, the Sprint Review meeting is timeboxed limited to 1 hour per 1-week Sprint duration. In other words, a 2-hour Sprint Review meeting is appropriate for a 2-week Sprint duration.

The meeting is open to all external stakeholders, such as customers and end-users, so that they can view the implementation of the new increment of functionality within the product. The Product Owner should invite only the stakeholders who have an interest in this or are impacted by the new increment of functionality.

This meeting is another example of a Scrum event that provides opportunities for transparency, as well as inspection and adaption. For example, customers and potential users have the opportunity to see a demo of the product, inspect it in terms of their current needs and priorities, and provide feedback that's vital to the product adaption process.

One phenomenon I have seen time and again is that when customers and end-users finally have an opportunity to look at products, invariably, they will gain new insights into how they can use the products. Or, they may have realized that they forgot to tell the Product Owner about another critical feature they require.

In the traditional model, unfortunately, these insights generally came during user acceptance testing or after the product had been released. In either case, those insights come far too late to impact current development activities. Those users may have to wait another year, assuming funding becomes available for a new development project, to see the implementation of the new enhancements they've now identified as a high priority.

The Sprint Review meeting is not limited to just reviews by customers and end-users. The entire Scrum process is open to discussion. During the Sprint Review, the Product Owner will discuss new product Product Backlog requirements and priorities and work with the team to assess how they fit with existing Product Backlog priorities. The Product Owner may also discuss projected target dates for deliveries of new increments of functionality.

As a group, the attendees of the Sprint Review can address business and market considerations that impact the product's definition and development. Those discussions may lead to a new refinement of the Product Backlog, which becomes an input to the Sprint Planning meeting for the next Sprint.

After the Sprint Review, the Scrum Teams turn their attention to discussing how they can improve their team's performance. That review occurs in a separate event called the Sprint Retrospective.

Sprint Retrospectives

Just after the Sprint Review, the development team meets to reflect on how they can improve their work, starting with the very next Sprint. The timeboxed duration for this meeting is roughly 2 to 3 hours in duration. The product development team describes the work they completed during the Sprint, what went well, what didn't go so well, and what they did to address the problems.

The Sprint Retrospective needs to occur before the Sprint Planning meeting for the next Sprint. Having the Sprint Retrospectives at the end of each Sprint ensures the information is still fresh in their memories, and also allows the teams to integrate their actions for improvements in the next Sprint.

The Scrum Master should facilitate this meeting as there is potential for tension among the team members. Everyone must remember to remain respectful as they discuss the parts of the last Sprint that did not go so well. The focus needs to be on assessing better ways to do things and not blaming people. The scope of the discussions in the Sprint Retrospective should span people, relationships, processes, and tools.

The development team should not limit their conversations to just the things that did not go so well. They should also discuss the things that went well. As the facilitator, the Scrum Master can make a list of the items discussed and work with the team to prioritize their impact. Once the prioritized list is in place, the development team can create an improvement plan for the next Sprint.

The empirical process control foundations of Scrum through transparency, inspection, and adaption, and push the team to seek improvements continuously. The Sprint Retrospective implements the discipline to ensure this process doesn't stop. Without this discipline, due to competing priorities, it's simply too easy to avoid making time to assess how things are going and look for ways to improve. Over time, the work of the team will devolve and go backward in terms of productivity and performance.

Process improvement ideas do not need to be limited to merely improving work performance. It's also essential for the team to assess what they can do to make the work more enjoyable and sustainable. Scrum Teams stay together over long extended periods, usually measured in years. The teams get better due to their time and experience working together, and it's therefore vital that the team finds ways to develop a supportive and work-friendly environment.

With that, we've reviewed Scrum's roles and responsibilities and the events that guide the work across a Sprint. Before we can move on to discussing the basic workflow of Scrum, we need to understand the information available within Scrum that provides transparency about the completed and planned value of work. Scrum-related information is maintained in three forms, referred to as Scrum Artifacts. These artifacts include the Product Backlog, the Sprint Backlog, and Increments.