How is Scrum?

In this part, we’ll walk together through the timeline of a team’s work when developing a product with Scrum. However, before I begin, I’d like to emphasize that I do not intend to be prescriptive or to show all possible alternatives. The idea here is to provide a generic example of what can happen when we use the framework for a team’s work, citing its accountabilities, events, artifacts and commitments, plus a few more elements suggested as options.

Overview

The development of a product is initiated to meet a business opportunity, problem, need or goal represented by the Product Goal, whether for a specific customer (either internal or external), a group of customers or the market.

The following are part of the Scrum Team: Scrum Master, who is a servant-leader or facilitator; Product Owner, responsible for product decisions to maximize the generated value; and Developers, who conduct the work of building the product itself.

Before any implementation work actually begins, it is common to make some basic definitions and preparations, seeking only the minimum necessary to get the work started. It is usually at this point that an initial version of the list of items to be implemented, called the Product Backlog, is created.

Product development work with Scrum occurs through a succession of cycles, in each of which the Developers produce done parts of the product that can be delivered to their users, incrementing and modifying what has been produced until then. These cycles are called Sprints. Product development with Scrum is done Sprint after Sprint. Thus, at the end of one Sprint, the next begins immediately, with no breaks between them. To create pace and discipline, Sprints always have the same length – which is, at most, one month each. The preference is always for shorter lengths, in order to lead to frequent convergence on something done and to obtain feedback.

Each Sprint begins with a Sprint Planning meeting, in which the Product Owner and Developers define a value goal for that Sprint, the Sprint Goal. From the items with the highest order in the Product Backlog they plan the work to be implemented within the Sprint itself to realize this goal, thereby creating a Sprint Backlog. The Scrum Master can facilitate the meeting, as needed.

After this meeting the Developers begin the actual implementation work, which includes everything needed to implement done parts of the product. Done means the work has been performed according to the Definition of Done and, ideally, the resulting done Increment or Increments can be delivered. On each workday, the team holds a short meeting called the Daily Scrum to organize themselves about what they will be doing during the day until the next Daily Scrum.

On the last day of the Sprint, a Sprint Review meeting is held so that the Scrum Team can get feedback from customers and other stakeholders on what was produced during the Sprint. This feedback feeds the Product Backlog with what can be done in future Sprints. After that the Scrum Team holds a Sprint Retrospective meeting aimed at continuously improving its way of working. On the next business day, a new Sprint begins.

Introduction

The Scrum Team is a small group of people responsible for all activities related to a product’s development. The Scrum Team is self-managed and therefore defines what will be done, who will do what, how and when, and always aligned with the context of the organization and the Scrum framework. The Scrum Team is cross-functional, which means its members have all the knowledge and skills necessary to develop the product from end to end. In this way external dependencies are ideally eliminated, thereby increasing the team’s ability to generate value for the product’s users.

Scrum Team The Scrum Team consists of: Product Owner, Scrum Master and a number of Developers.

The Developers conduct the work of developing the product itself, adding, adjusting and modifying the features and behaviors of that product and achieving the value goals agreed with the Product Owner.

The Scrum Master facilitates the work and is a leader who serves the Scrum Team on a day-to-day basis, teaching its members to be accountable for their work, grow in autonomy and self-manage. He works with both the Developers and the Product Owner, in addition to facilitating their interactions. He is present and acts as a facilitator at Scrum events, when needed.

To conduct this work, the Scrum Master must have strong soft skills – that is, behavioral and personal skills. The Scrum Master also teaches Scrum to the Scrum Team and any other people in the organization that he may deem necessary. He is responsible for ensuring that the impediments the Scrum Team might find in its work are removed, acting whenever necessary as a change agent in the organization. These impediments can put the Scrum Team at risk of not realizing the goals, and must be removed as soon as possible.

The Product Owner is responsible for maximizing the value resulting from the work with Scrum. She is unique to the product and to the team that will develop it. She works directly with the customers – that is, those who request or contract the development of the product –, and with any other stakeholders that can contribute to the understanding and definition of the product throughout its development. The group of stakeholders also includes the users of the product themselves, who will receive done parts of the product throughout the work and offer feedback on them, enabling the collection of usage metrics.

To guide the product development work, the Product Owner creates or aligns with a Product Goal defined for the product to be developed. The Product Goal, commonly referred to as the “product vision”, represents the central purpose or motivation for the product development work and must be understood by all stakeholders, generating an alignment between them. The Product Owner communicates and maintains alignment to the Product Goal throughout the product’s development.

Based on the Product Goal, the Product Owner can optionally create a plan of how, at that moment, she expects the product to evolve over time, called the roadmap of the product. This is usually expressed by a timeline with the business goals expected for defined moments in the future, established as milestones of this roadmap. This roadmap, when used, is frequently updated to reflect the most current understanding of the possible product evolution. However, the artifact product roadmap is not a part of Scrum.

The Product Backlog is an ordered, incomplete and dynamic list of items that represent what the Product Owner, at any given time, believes will be produced. It serves as the input for any and all work done by the Developers in the development cycles. The Product Goal is the main commitment of the Product Backlog and part of it – that is, the Scrum Team works on the Product Backlog in order to realize the Product Goal.

The Product Owner is solely responsible for managing the Product Backlog and whose work includes defining the product little by little, updating this list throughout the product’s development and ordering it so that, in each cycle, what is most important to maximize value is implemented. The Product Owner performs this work or may delegate some of it to others, although is always himself accountable for its results.

The items at the top of the Product Backlog are the most important at that time to maximize value and for that reason have more detail, enough to allow them to be implemented first. The items further down have gradually less detail and will evolve when and if their time comes.

The Product Backlog can be long, ranging from small, well-detailed items to large, vague items. But it can also be short and contain only the number of items needed for the most immediate work (this is my preferred version, as it avoids clinging to what has already been defined). Whatever the case, the Product Backlog will evolve throughout the development of the product and will be frequently modified by adding, subtracting, detailing, dividing, reordering and modifying its items.

To guide the work, we prefer to use the users’ perspectives for each of the Product Backlog items, based on the User Stories. A User Story brings a simple and concise representation of a Product Backlog item. The idea is that for each of these items represented by User Stories, the Developers, Product Owner and, perhaps, customers and other stakeholders will discuss and detail the feature or behavior to be implemented in the product. Notwithstanding, the User Story, while a good practice, is not part of the Scrum framework. It is up to the Scrum Team to define the best way to represent the Product Backlog items.

The Definition of Done is a formal understanding shared between the Developers and Product Owner about what activities or conditions are necessary for any item in the Product Backlog to be considered done when implemented, and thus become part of the product. The Definition of Done is the same for all Product Backlog items throughout the product’s development, but can evolve over time as needed.

All the Scrum meetings – Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective – have a defined maximum duration, called a timebox. The development cycle (or Sprint) has a fixed duration. It is important in order to avoid waste, limiting the time for which a specific goal must be carried out, as well as helping to create a pace or regularity in the execution of the work.

We can see the complete Scrum cycle in the following figure (SCHWABER; BEEDLE, 2002; SCHWABER, 2004).

Beginning of development work

Development of the product is conducted incrementally in Sprints, the iterations or development cycles in Scrum. Before the first Sprint there may be some brief initial preparation work, always within what is strictly sufficient and necessary. Defining the Product Goal, creating an initial Product Backlog, the Definition of Done and forming or choosing the Scrum Team are common examples of these activities.

However, this and any other groundwork is preferably done progressively over the first Sprints, in which usable value will still be generated.

It may be necessary, for example, to make basic structural decisions for the product in order to reduce the risks of late decisions that could invalidate what has already been produced. It may also be necessary to create or adapt an infrastructure that will support the product’s development. The idea behind these activities is to generate only what is minimally necessary and sufficient to reduce risks, but without stifling product development or generating large amounts of waste.

Beware of lengthy definitions of architectures, requirements or user journeys without implementing or delivering functional parts of the product! In agile product development, we deliver value as early and often as possible, producing just enough of what is needed each time.

As for defining the Scrum Team, we expect an organization that uses Scrum to try to work with stable teams. In this sense, when deciding who will participate in the development of a new product, the best question to ask is no longer “which people do we need to execute this work?”, but rather “which of our teams has the most adequate knowledge and skills to develop this product?” In other words, instead of forming a new Scrum Team for each new development, we seek to choose the best Scrum Team for the work in question.

In cases where it is necessary to form a new Scrum Team or modify an existing one, the process may vary from one organization to another. Among the different possibilities, there may be a department responsible for selecting the team members, or one might begin with a Product Owner, a Scrum Master, or one or more initial Developers who will then choose the remaining team members. If needed, an existing Scrum Master may play a role in the process, but there is no universal rule regarding this.

Sprint Planning

A Sprint starts with the Sprint Planning meeting, in which the Developers and Product Owner plan the work to be executed in the Sprint itself. Developers select a set of items from the top of the Product Backlog (as ordered by the Product Owner) that they deem capable of implementing for the length of the Sprint, and establish together with the Product Owner a goal to be carried out based on the implementation of these items, called the Sprint Goal. The selected items are only a forecast of what will be implemented.

When planning, the Developers can use the average amount of work they were able to jointly develop over the last few Sprints to decide how many items will be included in the plan for the Sprint about to begin. This average of the amount of work done per Sprint is called the Velocity. For the first Sprint, however, the Developers still don’t have this history of work already done and will have to judge how much they believe is reasonable to include in the Sprint.

Although the official Scrum guide establishes that Product Backlog items are sized by the Developers (SCHWABER; SUTHERLAND, 2020), no formal type of estimation is prescribed by the framework. However, Story Point is a unit of relative effort estimation widely used by Developers to facilitate the planning of their work.

In addition to selecting items and defining a goal, which they do together with the Product Owner, the Developers also create a plan for how what has been selected will be implemented. This plan is partially defined at the Sprint Planning meeting and continues to be defined and implemented throughout the Sprint. The plan is usually expressed by a set of tasks for each item, to be accomplished during the Sprint. These tasks are generally the actions or work activities that the Developers identify as necessary to implement for each selected item. The Definition of Done is used to guide the definition of this plan in order to ensure that what is implemented in the Sprint will be deliverable.

The set formed by the selected items, their respective plan and the Sprint Goal is called the Sprint Backlog, and is usually represented in the form of a task board (see the figure below). The Sprint Backlog only exists within its respective Sprint. The Sprint Goal is the commitment of the Sprint Backlog – that is, the Developers work on the Sprint Backlog to realize the Sprint Goal.

Implementation

After the Sprint Planning meeting, the Developers start the actual implementation work on the Sprint Backlog items. They started to define how the work will be conducted during the Sprint Planning meeting. Now they are responsible for organizing themselves to do this work and for monitoring how they are realizing the Sprint Goal.

They start working on the first item in the Sprint Backlog, which is the most important item for the Sprint Goal. Different Developers perform the different tasks that are required, communicating and collaborating throughout the process. Gradually they migrate to the next items in the Sprint Backlog, always focused on completing them according to their order.

Stop starting and start finishing The Developers work together according to the established order, completing the higher-order items first and descending to the lower-order items until the Sprint deadline expires. If they are not able to complete everything they planned, they leave the lower-order items out, but ensure that the higher-order ones are done. If they had been working on several items at the same time, the greatest risk would be that they would reach the end of the Sprint with most or all of the items almost done, but not done, and therefore not deliverable.

On each day of product development work, the Developers meet for the Daily Scrum meeting for a maximum of 15 minutes, always at the same time and in the same place. The purpose of this inspection and adaptation meeting is to ensure transparency among them about their work and to informally plan the next work day based on what has been achieved since the previous day. Performing the meeting next to the task board is therefore a good practice.

The Daily Scrum meeting is an excellent time for the team to update, when adopted, the Sprint Burndown Chart, a tool that Developers can use to monitor their Sprint progress. This graph has the Sprint work days on the horizontal axis and the amount of planned work remaining on the vertical axis, which can be measured by the number of remaining tasks or by some kind of estimate made of the tasks or the Sprint Backlog items. Developers plot the amount of work remaining on the current day on the chart (see the figure below). The Sprint Burndown Chart is also not specifically prescribed by the framework, although it has been in the past.

It is common for Developers to face challenges in their day-to-day work. Whenever they encounter something that prevents them from doing their work and thus threatens the Sprint Goal, they notify the Scrum Master, who immediately starts work to manage removal of that impediment.

An accessible and present Product Owner throughout the Sprint allows Developers to obtain answers for any business questions that may naturally arise regarding the items being worked on. At the same time, the Product Owner seeks to maintain frequent contact with customers, users and other stakeholders, in addition to assessing the product’s usage metrics, in order to understand their real needs or most important business goals, collect feedback from them and update the Product Backlog accordingly, whenever deemed necessary.

Sometimes, one or more items at the top of the Product Backlog arrive at the Sprint Planning meeting with too many uncertainties, not enough detail or granularity that is too coarse. With items like this there is a significant risk that the meeting will be long, without being productive or effective. It may be important, therefore, that these items arrive at the meeting prepared enough so that Developers can plan their implementation. Product Backlog Refinement is the work of preparing Product Backlog items, which may include slicing them into smaller items, adding and modifying details, estimating and reordering them so they are fit to be implemented by the Developers in a Sprint.

This refinement work is generally conducted by the Developers in conjunction with the Product Owner. They decide together how they will collaborate to prepare the items for implementation. The Product Backlog Refinement can be performed at the Sprint Planning meeting. However many teams choose to do this over the course of the previous Sprint in order to prepare enough items for the next Sprint. This interaction can be done in one or more scheduled sessions or whenever the Developers deem it necessary. In a more mature scenario, the Product Owner may delegate to Developers the responsibility to conduct refinement sessions directly with the customers, users and other stakeholders.

It may be interesting for the Scrum Team to use a Definition of Ready that can guide the Product Backlog Refinement to be carried out when preparing the items that will be considered for implementation in the next Sprint. The Definition of Ready establishes clear criteria regarding the minimum necessary state in which any Product Backlog item must be in order to enter the plan of what will be implemented during the Sprint – the Sprint Backlog. It is common for the Definition of Ready to require items to be small enough and specify the details of the feature or behavior to be added to the product, in addition to other context-specific criteria. The Definition of Ready is always the same for all Product Backlog items, although it may evolve over time.

By using the Definition of Ready, the Developers and Product Owner assume joint accountability for arriving at the next Sprint Planning meeting with enough items from the top of the Product Backlog that are ready, according to that definition. In this sense, the Definition of Ready can be seen as another Product Backlog commitment.

Nevertheless, the Definition of Ready is not strictly part of the Scrum framework, although the concept of having items ready to be worked on is.

Sprint Closing

At the end of the Sprint, the Developers will have generated at least one Increment of the product from the work done in the Sprint.

Each Increment is made up of one or more done items from the Sprint Backlog (according to the Definition of Done) that potentially represent visible and useful value to the customers and users of the product. By nature, the Increment is done, so the Definition of Done is the commitment of any and all Increments generated by the Developers. And because it is done, the Increment is deliverable, which means that no additional work is required before the Increment can be delivered. The timing for delivering one or more Increments, however, is a decision of the Product Owner.

If, during the Sprint, the Sprint Goal has lost its relevance, the Product Owner may decide to cancel the Sprint, anticipating its closing. However this is an exceptional situation and should rarely occur.

On the last day of the Sprint, the Product Owner and Developers meet for two consecutive inspection and adaptation meetings, both facilitated by the Scrum Master. In the first meeting – the Sprint Review –, the Scrum Team inspects and adapts the product, while in the second, Sprint Retrospective meeting, the Scrum Team inspects and adapts its way of working.

Customers and other relevant people who can provide feedback on the Increment or Increments that were produced during the Sprint are invited to the Sprint Review meeting. During this meeting, those guests will interact with the result of the work done in the Sprint, in order to offer their feedback to the Developers and the Product Owner. Only items that are done according to the Definition of Done become part of an Increment and are presented in the Sprint Review. This meeting provides an important opportunity to anticipate part of the feedback that will only come with the actual use of what has been implemented after its release, and thus reduce the risks in product development.

The feedback obtained from customers and other relevant people present at the Sprint Review meeting is used by the Product Owner as raw material for changes to the Product Backlog. That is, to provide elements for the Developers to modify the product being developed in order to better meet the customers and users’ needs.

After the Sprint Review meeting, the Scrum Team members hold a Sprint Retrospective meeting, with the aim of becoming more effective as a team. In this continuous improvement meeting they identify what went well during the current Sprint – and for that reason can be maintained in the next Sprint – and what can be improved, looking for practical ways and outlining any action plans needed to make these improvements. There are numerous techniques for holding Sprint Retrospective meetings, all aimed at improving how the Scrum Team does its work.

Once the Sprint Retrospective meeting is over, the Sprint is closed. A new Sprint then starts immediately after the previous one ends, on the next business day.

Releases

Once an Increment or the sum of Increments of the product represents sufficient value, it is important that it reaches users as quickly as possible.

Through frequent deliveries, the Scrum Team can get feedback and metrics on the product’s usage, thereby developing a product that will be used and bring value. With each value release to the end user, the Scrum Team generates business value to its customers.

The release strategy to be used is defined by the Product Owner, who decides when or how often the releases will be made and who will receive them. Under the best case scenario, frequent releases to the end user would be made, but it may be more feasible for intermediate users to receive and use the product more frequently in order to provide feedback and metrics.

A Release Planning meeting can optionally be held to plan the next release. This meeting, which is not part of Scrum, may occur sometime before work starts on the corresponding release, probably during the previous Sprint or, for the first release, before the first Sprint.

During this Release Planning meeting, if held, the Product Owner and Developers can establish a release plan, which usually contains a release date (at least approximate), a business goal to be carried out – which we can call the Release Goal – and a set of items selected from the top of the Product Backlog to realize this goal. This meeting, however, does not replace the Sprint Planning meetings that are held for each of the Sprints corresponding to the release.

Progress towards the release date, and therefore how the Release Goal is being carried out, can be inspected from Sprint to Sprint. A tool widely used for this purpose is the Release Burndown Chart. This chart has, on the X axis, the final moment of the Sprints corresponding to the release and, on the Y axis, the amount of planned work remaining, which can be measured by the number of Product Backlog items remaining among those planned for the release or by estimates made on the items, for example.

Should he choose to use it, the Product Owner marks on the graph the amount of work remaining until the end of each Sprint, at which time the release plan is reviewed. Other tools, such as the Release Burnup Chart, which shows the accumulated work already done and the total work projected at any given time, can be used instead.

The Release Planning Meeting, Release Goal, Release Burndown Chart, and Release Burnup Chart are not part of Scrum.

End of product development

Product development can either be continuous – that is, a scenario in which the Scrum Team will keep evolving and maintaining the product indefinitely – or it can have a predetermined duration. In either case, the development of a product can be terminated for several reasons, depending on the context: the product is no longer used, the work duration stipulated in the contract has expired, sufficient value has already been delivered to the customers and users of the product, the budget for the work ran out or the contract was cancelled, among others.