Many Scrum teams handle the Scrum Events rather out of habit or even mechanically. These events are often insufficiently prepared or poorly executed. There are many reasons for this, from inexperience, to lack of knowledge, to unwillingness. Often it is also unclear what the deeper meaning behind the events is, what input they need and what concrete outputs they should deliver. This article describes the inputs and outputs of the five Scrum Events. Find out what is needed for each event, what it should deliver and what value it adds to your team.
Introduction and Motivation
When I start working as a Scrum Master in a new Scrum team, I almost always notice one thing. The team knows which Scrum Events exist, but they are not executed according to their meaning. In some cases, some of the events are not even executed because the team is not clear what added value the event has or should have.
This may certainly be due to the fact that Scrum is now one of the most widespread frameworks in software development. That there are three roles, three pillars, three artifacts, five values and five events is incredibly easy to understand. It becomes more difficult when understanding the Scrum meta-level. What are these things for, how do they mesh and complement each other, and how do you get them to work properly in practice? As the 2017 Scrum Guide told us, Scrum is “easy to understand” but “difficult to master.”
This article is intended to provide an overview of Scrum Events and, in particular, to shed light on what inputs and outputs are associated with them. What things does a team need to consider as inputs to its Scrum Events, and what added value or output do these events bring to the team. A Scrum team can only be successful if it understands that it is absolutely necessary not to lose focus on these.
The Scrum Guide
Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.
With the publication of the Scrum Guide 2020, the Sprint itself was named the fifth Scrum Event. The sprint is a container for all activities and work that are necessary to achieve the product goal, including the four other Scrum events, the refinement, the actual development activities or, for example, the coordination with stakeholders.
Inputs for a Sprint are always the Product Backlog, a vision from the Product Owner regarding a potential Sprint Goal, the available skills and capacity of the team for the Sprint, and the Product Increment created as a result of the last Sprint.
Outputs of a Sprint are the newly created Product Increment as well as another iteration of the Product Backlog. This was refined and expanded by the team during the Sprint, or otherwise adapted. Thus, it represents the current view of the team on the requirements of the product.
According to the Scrum Guide 2020, “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.” Therefore, the team is supposed to answer the following three questions. “Why is this Sprint valuable?“, “What can be done in this Sprint?” and “How will the chosen work get done?“
In other, more simple words, the Scrum team is supposed to create a plan for the next Sprint. Therefore, is has to define a goal that shall be reached, the activities that have to be done to do so, and a plan how those activities shall be performed.
Inputs to the Sprint Planning therefore are the Product Backlog as it stands, the capabilities and capacities of the team in the next Sprint and the Product Owners vision for a meaningful and valuable Sprint Goal.
The Product Backlog is the source of requirements from which the Sprint Backlog can be selected. The Product Owners idea or vision for the Sprint is the guideline for the selection of those tasks. The capacity and capabilities serve as constraints for the amount of work that can be selected, as well as for the type of work that can be selected. E.g., database implementation should only be planned when developers with corresponding expertise are available in the next Sprint.
Outputs of the Sprint Planning are the Sprint Goal, the Sprint Backlog, and the plan on how this work is supposed to be performed and delivered. In more simple words, the outputs are the goal that shall be reached, the todo list of things that have to be done to do so, and an idea of “who does what, and in which order do we do it?”.
The Daily Scrum is the daily Scrum event of the developers in the Scrum Team. The goal of the Daily Scrum is to inspect the Sprint Backlog and review progress against the Sprint Goal. If necessary, it is then necessary to adjust which next steps the team will take to achieve this goal.
Inputs of the Daily Scrum are therefore the current status of the Sprint Backlog and the Sprint Goal. The Sprint Backlog must not only be updated on a daily basis, but must also reflect the status quo at the beginning of the Daily Scrum. Furthermore, the awareness of the team’s current plan on how to achieve the Sprint Goal is needed as input. Only if the status quo, the goal to be achieved and the path leading there are clear to the team, the path can be adapted accordingly.
Output of the Daily Scrum is a plan for the next 24 hours, the next working day. The team is clear in what form it will proceed to achieve the sprint goal. This includes the removal of impediments, the collaboration of the developers with techniques like pair programming and the distribution of the different tasks in the team.
“The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.”
During the Sprint Review, the team inspects what actually has been done, and more important, what hasn’t been done. This can lead to valuable input for the Sprint Retrospective. The work that has not been done is moved back to the Product Backlog. Stakeholder feedback can lead to new priorities, and thus, the order of the Product Backlog may change. Furthermore, the team inspects if it is still on “the right track”, and if it is delivering valuable work regarding the Product Goal.
Inputs to the Sprint Review are therefore, the Sprint Backlog and Sprint Goal, as well as the Product Increment and the Product Goal.
Outputs of the Sprint Review are a revised version of the Product Backlog, valuable stakeholder feedback, and observations which can be discussed in the Sprint Retrospective.
The Sprint Retrospective concludes the sprint and is the opportunity for the Scrum team to review itself, its processes, its development techniques, and everything else related to the team. The goal is to find ways to increase effectiveness and efficiency.
Inputs for the sprint retrospective are positive and negative aspects of the last sprint. Although improvements are likely to be made for negative aspects, it is important not to forget the good things that happened in the last few weeks. Additionally, the Sprint Review may have provided input for the Sprint Retrospective if the Sprint was not successful or stakeholder feedback was discussed regarding the quality of the product increments.
Outputs of the Sprint Retrospective are action items that are then recorded in the Product Backlog. According to the Scrum Guide 2017, at least one of these process improvements should be planned in the upcoming Sprint. The Scrum Guide 2020 tells us to work through these items as soon as possible, even if it doesn’t have to be directly in the next Sprint.
A Beginners Guide to Sprint Retrospectives
What About Refinement?
Well, technically, Refinement is not a Scrum event. However, many teams hold their refinements as meetings, and every meeting is supposed to have an input or agenda, and of course is supposed to deliver some value to the company. Hence, it is supposed to produce an output. Is described by the Scrum Guide as “the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.“
During refinements, the Product Backlog is enriched with additional information. This may be through addition of information to already existing requirements, gaining clarity through discussions, splitting requirements, or writing new requirements into the backlog. This way, the Product Backlog evolves during every refinement and requirements get ready to be planned in one of the upcoming Sprints. Thus, Input and Output of refinement activities are different versions/iterations of the Product Backlog.
Hopefully your team is already familiar with the inputs and outputs of Scrum events. If you didn’t find any new information in this article, then congratulations, your Scrum knowledge isn’t that bad. If your team is also actively keeping track of these inputs and outputs, all the better. You are well on your way to being a successful Scrum team. If you found any new information in this article, I’m glad you learned something. Just make sure you remember these inputs and outputs of Scrum events the next time you attend one. Keep reminding yourself and your team what these events are for and that you can only be successful if you are aware and don’t lose focus.