Scrum

Scrum: understand once and for all what it is, how it dramatically increases your results and why use it

By Roque Sales, CX & UX Manager at Zappts

Scrum is a framework for developing and maintaining complex products. The methodology was defined in the guide written by its creators, Ken Schwaber and Jeff Sutherland, and entitled Scrum Guide.

Within this framework, people can treat and resolve equally complex and adaptive problems, while productively and creatively delivering products in the best possible way and with the highest possible value. The tool for this is the performance of roles, events, and artifacts united and integrated by specific rules.

Scrum has been in use since the early 1990s and remains relevant to this day. This is because it was designed to be inherently lightweight and easy to understand, yet extremely difficult to master — like a game of poker.

To explain this in depth, it is necessary to understand the initial paradigm of the development industry and how and why it was changed. Let us start by learning more about development methodologies.

Development Methodologies

The Traditional Methodology

In the early days of the software development industry, the methodology used for project management consolidated into well-defined phases. They were:

• requirements gathering,
• requirements analysis for outlining the architecture,
• implementation via coding/programming,
• testing,
• product launch,
• and support/maintenance.

This methodology was later named Waterfall, because each phase is executed hierarchically, one after the other. A phase only begins when the previous one finishes.

Waterfall is planned in a meeting with the client. The way it is done does not allow for changes, since everything is established right at the beginning of the process. All requirements, product and project scopes, and consequently cost planning, are fixed. There is no risk analysis or greater client involvement until the final product is delivered.

Because it is such a phase-based process, it ends up being time-consuming and rigid. This delay prevents clients from getting deliverables developed at the speed they need.

In the long run, this results in systems that are already launched on outdated technologies or lacking specific functionalities to address the initially proposed problem, which may have changed during the system’s development.

Furthermore, each team member is responsible for a part of the project and does not communicate frequently, with little regard for each person’s “skills.” To counteract these problems and reduce the bureaucracy involved, agile methodologies emerged.

Agile Methodologies

In agile methodologies (often abbreviated to Agile), the team discusses and collaboratively designs the delivery of the final product.

Tasks are distributed according to each member’s technical knowledge and performance. This ensures the viability of the plan by taking into account the particularities of the individuals involved.

Project implementation is done in a cyclical and iterative manner. A project is composed of several cycles. Its effectiveness in addressing the problems and pain points proposed by the client is always considered. It often undergoes adaptations at the end of each cycle according to demands that arise.

This means that agile methods are flexible and provide constant deliveries to the client, always taking their feedback into account. In contrast to the traditional software development method.

The synergy of the development team is essential for Agility to work. This synergy, in this case, is not restricted to the team alone. It must extend to all individuals and departments involved in the project, so that the development team can maintain its focus and high performance.

When identifying management or communication failures, the team must use all available agents in the organization to neutralize them. Thus becoming self-sufficient in their risk management, processes, and results.

Examples and Characteristics of Agile Methodologies

The concept of agile methodology was based on Lean Manufacturing. Lean is a manufacturing model used by Toyota after World War II. But it was only formalized in 2001, through the Agile Manifesto.

Common Similarities Across All Agile Methodologies

Some of the most widely used agile methodologies in companies today are Scrum and Kanban. What they have in common, besides Agility, is a set of practices based on certain values, outlined in the Agile Manifesto as:

• Individuals and interactions over processes and tools. All people involved in the process should work together and daily, communicating in an open and constant manner. Everyone should always strive to maintain a sustainable work environment that provides support, motivation, and trust.
• Working software over comprehensive documentation. Working software made quickly and with quality is the primary measure of progress.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan. Evaluating project progress at each cycle and accepting requirements changes even at the end of development. This way the client can gain competitive advantages.
• Maximizing the amount of work not done by striving for technical excellence of team members and for simple and intuitive design and usability.
• Building, through daily coexistence, self-organizing teams. Team members reflect on ways to increase their productivity and effectiveness based on the results of each cycle. Thus, they adjust their behavior to optimize their synergy and increase their delivery frequency.

Differences Between Scrum and Kanban

What differentiates them, however, is:

• Scrum is about self-management and how developers interact and what they do when they are not writing code.
• Kanban is about avoiding waste of resources and optimizing production. This is achieved by limiting the workload of each developer. A visualization of the resource flow in the production line is created with post-it notes on a board.

Kanban is continuous and Scrum is iterative. Scrum has closed cycles with defined goals that repeat, while Kanban is more suitable for teams that have unplanned work on hand. For example, support issues and emergency feature requests — since it does not have cycles.

Now, after this introductory content, let us address Scrum. We will define what it is, show where it came from, and break down all of its roles, events, artifacts, and rules.

So, What Is Scrum?

Origin of the Term Scrum

The name came from rugby. In the sport, there is a movement called Scrum. It occurs when players from both teams form a circle around the ball, pressing their heads together and measuring forces to grab it.

The Scrum is considered a demonstration of the team’s strength and unity in reaching their goal.

That is why the agile methodology discussed here adopted this same name.

Difference Between Scrum and Agile

It is common to have the impression that these terms are the same. However, Agile is a set of methods and practices based on the values expressed in the Agile Manifesto.

Scrum, on the other hand, is not a process or a technique for building products. It is a methodological framework (or framework) that is incremental and is used to implement Agile development. You can employ various processes or techniques for this.

Scrum makes clear the effectiveness of product management and development practices in the companies where it is implemented, so that they can improve those practices.

The framework consists of Scrum teams associated with roles, performed by team members during events, with the help of artifacts.

As described in the Scrum Guide, each component within the framework serves a specific purpose and is essential for the use and success of Scrum. The rules integrate the events, roles, and artifacts, managing the relationships and interactions between them.

Where Did Scrum Come From?

The Creator of Scrum

Jeff Sutherland worked as a military officer in the United States Army for 11 years. After that period, he decided to study Medicine at the University of Colorado. He ended up getting involved with data collection and systems development.

During the 1990s, Sutherland noticed a recurring problem in his new area of interest. Companies that demanded software projects with a tight schedule and incompatible budget. He decided to find a solution for this problem.

Scrum’s Great Differentiator

Through research, Sutherland eventually came across Lean Manufacturing as used at Toyota and other Japanese companies. With the help of Ken Schwaber, he created the Scrum methodology based on this manufacturing system.

After Scrum’s effectiveness was proven through a series of successes, this new methodology quickly became popular in the product development industry.

Scrum represents the shift from an algorithmic view of projects to a heuristic one. People and self-management are the key to solving problems. They are prioritized into individual tasks and delegated to the team members best prepared for each one.

The Scrum Team

Scrum Teams are self-organizing and cross-functional. Being self-organizing means that team members choose the best way to carry out their work, rather than being directed by people outside the team. Being cross-functional means that a team has all the competencies necessary to do the work without relying on external agents.

The Scrum team model was designed to optimize flexibility, creativity, and productivity. A team usually has three to ten members. When ten people cannot handle the work, the team is split in two. New members are added to each new team, along with the original members.

Depending on the size of the project and the number of teams, it is advisable to apply Scrum of Scrums, which we will address later. Team members perform specific roles.

Product Owner: The Product Owner

This person’s role is to represent the interests of the end user, serving as the bridge between the technical team — represented by the Scrum Master — and the other stakeholders. The PO will always be balancing the demands of these two parties.

This member has the authority to say what will be part of the final product or not. Typically, they are a key user of the system, or a user with good understanding of the requirements and what they and other users need.

Does the Product Owner Need to Know How to Program?

They can be someone with a technical background (someone who was a front-end developer or a UX designer, for example) or not (a business analyst, the company’s CEO, or the client themselves).

Although listed as part of the Scrum team, the Product Owner is not an integral element of it.

Their presence and availability to the team are constant, but they are not part of the development process. What they do is more related to business strategies and value delivery. Their function is much more “political” than technical.

The Product Owner is responsible for the Product Backlog, which is a list of tasks describing the features needed for the final product, ordered by priority. The person who determines the degree of priority of each task is the Product Owner, based on business value and the expected ROI of each task.

For this, they must have a clear and deep understanding of the product vision, have autonomy to make decisions, and be communicative enough to convey them clearly to the rest of the team.

Scrum Master: The Process Owner

The Scrum Master’s role is to ensure that Scrum values and rules are followed daily by the rest of the team. They are responsible for deciding the length of software development cycles. In Scrum, these cycles are called Sprints. Each Sprint can last from one to four weeks.

Furthermore, they are the intermediary between the development team and the Product Owner. The Scrum Master serves as “relief” so that the Product Owner can focus on business strategies and value delivery with the other stakeholders. Meanwhile, the Scrum Master works directly with the development team and manages the Sprint Backlog.

Why Process Owner?

The Scrum Master may be informally called the Process Owner because they are the member who balances the internal and external relationships of the Scrum team. They work directly with the Product Owner and the development team, but can also interact with other departments of the company or with other stakeholders, for example.

This is because the Scrum Master’s other responsibility, beyond the Sprint Backlog, is to shield the developers. They filter which information reaches the “devs” and avoid interference in the Sprint, always working to resolve any impediment to the team’s progress.

During the Sprint, this member acts as mentor and manager of the developers, talking with them constantly to resolve possible impediments. “My computer is broken and that’s why I can’t code,” “I don’t have enough knowledge in this technology to execute this task,” “the colleague sitting next to me is annoying me,” “I get interrupted too many times during the day,” among other technical or personal obstacles, for example.

The SM always keeps the Sprint Backlog updated to analyze individual and collective performance. Furthermore, they see which tasks are completed and in how much time, thus predicting and ordering which tasks will have to be deferred to the next Sprint.

The estimate of work that cannot be deferred to the next Sprint is calculated every day and placed on a chart called a Sprint Burndown Chart (or just Burndown Chart — Burn Down Chart, in a loose translation).

Mentor and Facilitator for Developers

Being a mentor to the developers, the SM needs to keep them motivated and ensure that Sprint tasks are being executed correctly. They do this by taking into account the requests of the PO and the other stakeholders.

However, the SM’s authority and autonomy are smaller than the PO’s, since their scope of action is restricted to the development team.

The shielding measures they can take end up depending on the collaboration of agents outside the Scrum team. Therefore, it is important that the SM is a good negotiator and knows how to talk to stakeholders in a friendly manner.

Does the Scrum Master Need to Know How to Program?

The Scrum Master’s technical background in software is optional, as is the Product Owner’s. However, it is useful that they understand at least the basics of development concepts and the technologies applied to their team’s project. This will give them more confidence in ensuring the quality of deliverables.

The Scrum Master is not responsible for executing Sprint tasks, but must ensure that this execution is done in the best possible way within the team’s capabilities, limitations, and agreements.

Developers

When talking about a Scrum Team, the first members to be mentioned are usually the software developers.

In the development team, it is necessary that members are allocated in such a way that any software problem can be solved by them entirely, without external help.

There is not necessarily a division of members by individually performed roles. Such as designer, front end, back end, architect, test analyst…

In Scrum, all members work together to deliver at the end of a Sprint what was promised at the beginning. Therefore, everyone ends up being fullstack to a greater or lesser degree.

Scrum is based on reflecting on past performance with transparency and commitment. All team members know what each person is doing and how each task is progressing. Everyone commits to changing whatever is necessary to improve the team’s performance.

It is important that the team remains agile, integrated, and communicative. Being part of a synergistic team naturally helps all members stay motivated and committed to creating a more efficient process.

Scrum Artifacts

Scrum Artifacts are information radiators that represent work or value. They provide transparency by giving opportunities for inspection and adaptation of the development process.

They are specifically designed to maximize information transparency, so that all stakeholders have the same understanding of each artifact’s content.

The mandatory Scrum artifacts are only the Product Backlog, the Sprint Backlog, and the Product Increment. However, beyond these, there are also optional artifacts whose use is decided by the team. The artifacts, both mandatory and optional, are:

Product Backlog: The Wish List

The Product Backlog — Product Reserve, in a loose translation — represents a listing of features desired by the client. In agreement between the Product Owner and the client, they need to be developed with the highest urgency.

The items listed in this backlog are prioritized, deferred, or discarded by business value by the Product Owner, and can be technical tasks or not.

The Product Backlog does not need to be complete from the start of the project. In the beginning, developers can work only with what is simplest or most obvious to the planned system. Then, as Sprints are completed and the software is incremented, more things can be added to the backlog.

Thus, through negotiation between stakeholders and continuous analysis of delivered features, this backlog can grow and change, always taking into account what is learned about the product and about the user’s journey.

Sprint Backlog: The Tasks for This Cycle

During Sprint Planning, which we will address in the Scrum Events section, the PO prioritizes the Product Backlog items and describes them to the SM and the team.

The team then determines which of the described items it can complete during the next Sprint. This is how the Sprint Backlog is born, which is nothing more than a list of tasks or to-do items.

These to-do items are divided among the team members by the Scrum Master, according to the team’s perception of each member’s skills and the time that will be spent to complete them.

Scope changes to Sprint Backlog items after the Sprint has started should be avoided as much as possible. They disrupt the Sprint’s progress and take the team’s focus away from the work. If something needs to be modified, the Scrum Master must negotiate with the developers and the Product Owner about how and what to change and what the reasons are for this change.

User Stories

So far, we have referred to backlog items as tasks, but not all Scrum teams speak this way. Some prefer to talk about User Stories.

“Task” is a generic word for backlog items and can be used alone or in conjunction with “Stories.”

The human brain works better when it hears stories. We have greater understanding and empathy when an interlocutor conveys the reasons behind their choices and describes their trajectory. In this context, the interlocutor is the system’s user.

Thus, in summary, User Stories are simple and short descriptions of a feature to be implemented in the software.

They are told from the user’s point of view, pointing out the reason why they want the software to be capable of that function. Usually, Stories are written in this pattern:

“As a USER, I want FEATURE so that REASON.”

For example: “As a stock manager, I want to be able to add or remove products from the stock registry, so that there is greater control over the sales flow.”

User Stories are usually written on cards or on post-it notes. They can be placed on walls, whiteboards, or tables to facilitate planning and discussion. This arrangement can also be done in digital tools, such as Trello.

This helps with the visualization of features. The focus shifts from writing about features to active and collective discussion about them. Thus, the team is exercising Scrum principles of communication and transparency.

How to Detail User Stories?

If necessary, details can be added to Stories in two ways:

• breaking a more complex Story into smaller, simpler ones,
• or adding acceptance criteria to the card that describes it.

In the first scenario, it is already assumed that the newly created Stories contain added details.

In the second scenario, the acceptance criteria are just an obstacle placed there to ensure greater care in the development of that feature. It is natural that all of them are met as a consequence of that care.

Anyone on the Scrum team can write User Stories. It is up to the Product Owner to accept them in the priority queue that is the Product Backlog. Throughout the project’s lifecycle, it is expected that all team members will end up writing a Story at some point.

The identity of the User Story author is irrelevant. What really matters is who will discuss it and work on it throughout the project.

Similarly, it is not mandatory that all backlog items be written in the Story format. Sometimes it is much easier, faster, and more intuitive to simply write keywords, write use cases, or draw simple diagrams or layouts. Scrum describes what needs to be done, but there is no rule on how to do it.

Story Points: The Unit of Measurement for Progress

A Story Point is an abstract measure of the effort required to implement a User Story. Just like User Stories, the use of Story Points and Burndown Charts is optional.

In summary, it is a number that informs the team about the difficulty level of the Story. A level that is related to particularities, risks, and efforts involved in executing each specific Story.

In most cases, a Story Point uses one of the following scales:

• The Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21;
• Sizes analogous to T-shirt sizes: XS, S, M, L, XL;
• Or the simple sequence of 1 followed by multiples of 2: 2, 4, 8, 16.

Story Points represent high-level estimates and are usually done after Sprint Planning. The PO, the SM, and the development team make a rough estimate where they check if:

• the planning was conducted efficiently;
• there is enough information to complete everything that was assigned for that Sprint; and
• if the User Stories were divided reasonably among the team members.

Estimates based on time measures such as hours or days, on the other hand, are low-level estimates. They represent the tangible effort (labor man-hour ratio) required to complete that User Story.

Are Story Points Measures of Time?

Actually, Story Points and man-hour measures have different purposes for different situations and should not be compared or used exclusively. The right approach is to avoid relating them so that the Sprint and the product launch are better executed.

The man-hour is not the same for all developers, but Story Points are. This allows people with different speeds and different skill levels to reach a consensus.

Assigning a certain number of Story Points to a User Story is more flexible than assigning a number of hours or days. Thus, the Story’s delivery window ends up being the same for all team members.

Each Story Point represents a normal distribution of time. For example: one Story Point may represent a range of 4 to 12 hours, two Story Points would be 10 to 20 hours, and so on.

This time distribution is unknown during estimation, because when using Story Points, it is not necessary to know how long it takes — only an approximate indication of how long it will take for something to be completed is needed. Planning Poker is used to assign Story Points.

Burndown Charts: An Overview of the Project

Monitoring project progress in Scrum is usually done with a chart called a Burndown Chart at the end of each Sprint.

There are several forms of Burndown Chart. The form used is determined by the Scrum Master in conversation with the developers.

The work that still remains can be shown in the team’s preferred unit, which is usually Story Points. Its purpose is to ensure that the project is on track to deliver the expected solution within the desired timeline.

The Burndown is not mandatory in any way. It is just a tool for visualizing progress in the project and the Sprint, and it is this progress that must be measured mandatorily. Ideally, the SM should measure this daily.

The team can choose whatever method it wants, including other types of charts or other metrics, as long as there is a consistent way to inspect the product’s progress.

Product Increment: Features or Deliverables

When the first Sprint of a project ends, the Scrum team needs — even in a rudimentary way — to solve the end user’s problem. This is where the concept of MVP (Minimum Viable Product — Minimum Viable Product, in a loose translation) comes from.

The MVP is widely used in the world of entrepreneurship and startups, since most of these small innovative companies emerge precisely with an MVP.

The great difference between Scrum and Waterfall lies in this concept, since the iterations are based on delivering product increments over time. This is contrary to the old paradigm where there was a single large delivery at the end of the project.

For a Sprint to end successfully, its objective must have been achieved. This objective is defined by the team and usually involves the delivery of at least one working software increment.

That is why “increment,” “deliverable,” and “feature” end up being interchangeable words in this context. The increment needs to be validated by the test analysts and the PO so that it is incorporated into the final product.

Scrum Events

Events are used in Scrum to create regularity and minimize the need for unscheduled meetings. All events are timeboxed, which means they have a minimum and maximum duration.

All events are linked to the Sprint, which is the main event, and they all repeat each time a Sprint ends and another begins. Hence the iterative nature of Scrum.

Before the Sprint starts, ideally in the first Sprint Planning of the project, its duration is fixed by the Scrum Master. It cannot be shortened or extended.

The remaining events also have timeboxes but may end earlier than planned if the proposed objective for each is achieved more quickly. This ensures that an appropriate amount of time is spent without allowing waste in the process. The Scrum Events are:

Sprint Planning: The Planning

Before starting a Sprint, the Product Owner presents the most prioritized items from the Product Backlog to the Scrum Master and the developers. The team selects the items that will be part of the Sprint Backlog.

After that, the SM and the PO leave the meeting so that the “dev” team can technically define how the Sprint Backlog items will be developed. This definition is aided by Planning Poker, which we will see later in the article. These are the two stages of Sprint Planning.

During the first stage, the Product Owner presents the Product Backlog items from a business perspective, showing the reasoning used to define which items have higher priority. The team can ask the PO questions and already envision possible technical solutions for each item, since these items will form the Sprint Backlog.

After the Sprint Backlog is formed, the complete Scrum team will define an objective for the Sprint, describing concisely what the team should focus on for this iteration.

During the second stage, the developers gather to plan the technical approach for each Sprint Backlog item. Each item is broken down into smaller tasks or converted into User Stories if necessary. The time to be spent on them is estimated. This estimate is usually done with Planning Poker.

The analysis of Sprint Planning effectiveness will take place in the Sprint Review.

It is important that team members remember any time off, vacation periods, holidays, trips, or any other scheduling detail that will occur during the Sprint and could affect its progress. This way, they can estimate with the greatest possible accuracy the amount of work that will be completed.

Planning Poker: The Game and Its Rules

Teams that use Story Points also tend to use an exercise similar to a game of poker. Playing cards are used to estimate the effort that will be spent on each task.

The development team will pick an item from the backlog and briefly discuss it. Each member thinks of a number of Story Points they consider appropriate for its execution. Everyone picks and shows the others a playing card with the number equivalent to their estimate.

If everyone agrees, the exercise ends here. If there is disagreement, each developer must understand the logic behind the different estimates.

The estimate should be a high-level activity. This means that disagreements should not be too drastic. If some members estimated 1 Story Point while others estimated 5, talk a bit more until those numbers get closer.

The team should have a consensus on the maximum number of Story Points, working hours, or whatever measure the members choose.

Sprint Retrospectives are the moment for the team to reflect on the accuracy and effectiveness of previous iterations of that project. This reflection includes the accuracy of their estimates.

How Accurate Do You Need to Be?

In a Planning Poker session, imagine that half the team estimated 3 Story Points and the other half estimated 5 Story Points for a Story.

It is easy to accept 4 Story Points as the estimate and move on to the next task, but the team must have enough synergy and maturity to understand that doing so is not productive. It only creates a false sense of accuracy. There is no need to be 100% accurate. What is needed is to be accurate enough to ensure the Sprint goes well and to plan everything in advance.

Furthermore, there may be a loss of transparency in the process if the easiest decision is made. This decision leads to reduced team communication. Perhaps 5 Story Points is a better estimate and you will never know unless you talk about it.

Sprint and Its States (To Do, Doing, Done)

A Sprint is a cycle with a beginning and end, with a duration pre-determined by the Scrum Master. The Sprint is the center of Scrum. All other events and artifacts revolve around it and its execution.

At the end of each Sprint, there is a new feature to be validated or blocked by the Product Owner. Then, implemented permanently or modified until it falls within the rules and business values proposed by the PO.

Sprint Duration

The SM needs to analyze the stability of the product and project scopes before defining Sprint duration. If one of them is very mutable and these changes are related to delivery time, it is more prudent for Sprints to be one or two weeks long. If the resources available to the scopes are more stable, Sprints of two to four weeks may work better.

As already mentioned in this article, it is not common or recommended that a project’s Sprints vary in size, as this causes instability and unpredictability in execution speed.

The Sprint ends when the duration time defined for it runs out or when the objective defined during Sprint Planning is achieved. For the Sprint to end successfully, there must be a delivery of a software increment.

During the Sprint, each task has a state. This state serves to indicate the status of its execution.

Sprint States

Something common, and similar to what is done in Kanban, is to divide Sprint tasks into columns on a physical or virtual board. Each column corresponds to the state of a card. This card moves through the columns as what is described on it is implemented. The most common states are:

• Backlog. Refers to the Product Backlog.
• Blocked. Contains tasks that cannot be moved to To Do due to some impediment.
• To Do. Refers to the Sprint Backlog.
• Doing or Work in Progress. Lists tasks that are currently being worked on, with the developer responsible for each card indicated.
• Verify. Where tasks that have been developed and need to be tested are located.
• Done. Tasks that have already been completed.

The mandatory states are only To Do, Doing, and Done.

For all stakeholders to be aligned on what it means to complete a task, there is a document called Definition of Done. It contains a generic description of the minimum steps required to complete deliverables.

This document is like a guarantee of increment quality. It can be modified over iterations, as it is reviewed in each Sprint Review.

It is mandatory that all stakeholders agree with the Definition of Done so that there is transparency and trust among them during the project.

Daily Scrum: The Daily Meetings

Every day, the team meets to discuss the progress of the current Sprint. The goal here is to promote continuous alignment among all team members and help the Scrum Master predict what can realistically be delivered at the end of the Sprint.

This daily meeting is called the Daily Scrum or simply Daily. It usually lasts about 15 minutes. It can be extended with specific team members depending on what is discussed and possible impediments that may arise.

Attendance from the full team is mandatory. For this event, it always includes the Scrum Master but not always the Product Owner. Participation from other stakeholders, such as managers from other departments or the client, is less common but may occur, though they will only be listeners.

The Daily should not go deep into technical discussions. Any issue that arises during it should be extended only with the members directly involved or affected by that issue. If necessary, what was discussed at this stage is summarized for members who were not involved.

The questions that should be answered by developers in the Daily, thus reporting their progress to the Scrum Master, are:

1. “What I did yesterday” or “what I did since the last Daily”;
2. “What I plan to do today” or “what I plan to do until the next Daily”; and
3. “There are the following impediments preventing me from completing my tasks” or “there are no impediments for my tasks.”

Based on the answers, the Scrum Master should work to eliminate the impediments. If there are none, they should work to ensure that what remains in this Sprint is completed with quality and on time.

Sprint Review: Reviewing the Cycle

After the Sprint ends, the team shows how the development of the deliverables went. Usually present at the Sprint Review are the Product Owner, the Scrum Master, and the client or the stakeholders who represent them. The focus of the meeting is to demonstrate the new features with as few bugs as possible and functioning relatively well. Ideally, the Review should not last longer than two hours.

The increments should be reviewed according to the Sprint objective agreed upon in Sprint Planning. The team should always strive to reach that objective.

Sprint Retrospective: Reflecting to Improve

The last Scrum Event is the Retrospective. The team analyzes the Sprint that just ended and discusses ways to improve their work processes for the next Sprint. There is discussion and presentation of difficulties and how the team thinks they can be avoided.

This is related to some factors. They are:

• the effort of each developer,
• the task division made in Sprint Planning,
• and the impediments pointed out in the Daily, as well as the SM’s decisions to resolve them.

The team decides how to proceed from there to improve their efficiency in the next Sprint. Team members should aim to increase their productivity without loss of quality.

Just like the Daily, the Retrospective also has an ideal duration. In this case, it is one hour, but those involved in a more complex issue can continue talking after the meeting.

One of the Retrospective techniques is start-stop-continue:

• “We should start doing…” (start)
• “We should stop doing…” (stop)
• “We should continue doing…” (continue)

Scrum of Scrums: The Solution for Large Projects

Scrum of Scrums or Meta Scrum is a scalability mechanism created at IDX Systems (now GE Healthcare).

It is defined by the Agile Alliance as “a technique for scaling Scrum to large groups (more than a dozen people), consisting of dividing the groups into agile teams of 5 to 10 members.”

Furthermore, it is defined by Jeff Sutherland as “responsible for ensuring that the software from all teams meets the Definition of Done at the end of the Sprint, or at releases during the Sprint.” When working at IDX, Jeff Sutherland and Ken Schwaber implemented it as a technique for scaling individual Scrum teams to the corporate level.

Managing a Scrum of Scrums

Coordination of the various teams is done in a Scrum of Scrums meeting. This meeting can be held daily, twice a week, or at minimum, once a week.

Each Scrum team has its representative. It can be the Scrum Master or another team member chosen by the other members. If the topic one of the teams wants to discuss is very technical, both the technically qualified team member and the Scrum Master may want to participate.

The Scrum of Scrums meeting is conducted very similarly to the Daily Scrum. Although it does not have a predetermined duration, it is common for it to last 15 minutes, just like Daily meetings in regular Scrums. In the Scrum of Scrums meeting, each “ambassador” from each Scrum team should answer:

1. What their team accomplished since the last meeting;
2. What problems occurred (if any) and how they negatively affected their team;
3. What their team wants to accomplish before the next meeting;
4. What actions by their team in future Sprints could interfere with the Sprints of other teams;
5. And if their team sees any interference coming from other teams.

The purpose of the Scrum of Scrums meeting is to ensure coordination and integration of results from the various teams, eliminating all impediments. To this end, there may be involvement of two or more teams working together for a time or renegotiating responsibilities.

This needs to be managed with a Product Backlog specific to the Scrum of Scrums and maintained by the Scrum Master elected as the head of this process. Or, alternatively, by a Project Manager who has the Scrum of Scrums Product Backlog as their main responsibility.

How to Organize the Scrum of Scrums

A Scrum of Scrums framework can be effective even in larger organizations with multiple teams. Or in projects with Scrums distributed across different locations. As long as its own meetings are conducted properly.

The emphasis should be on coordinating the various teams and resolving impediments. The goal is to ensure that individual teams meet their targets. Thus, the overall project goal for all teams will be achieved.

Waste of time, work, and resources is minimized by a team formed specifically to help the Scrum Master or Project Manager in charge of the Scrum of Scrums. Members are selected from each Scrum or are exclusive members.

This ensures the maintenance of transparency and good communication between all Scrum teams. Ken Schwaber called this Integration Scrum in his book The Enterprise and Scrum. Having at least one release every three months is the goal.

How to Implement Scrum in Your Company

Implementing Scrum has a lot to do with implementing Digital Transformation. Besides Scrum being a Digital Transformation tool, both processes directly depend on changes in organizational culture.

These changes can only occur effectively if they are done gradually and with great engagement from company leaders and employees. Leaders will always have to balance the pros and cons transparently in front of their teams, aiming to integrate all departments of the company.

Agile Methodologies for Organizations

What happens in organizational implementations of agile methods is not the use of Scrum itself, but rather modified frameworks.

They are also based on the principles of the Agile Manifesto, but with this cross-department integration already considered from their conception.

One example of these frameworks is SAFe, which addresses all layers of an organization. Dean Leffingwell, the creator of SAFe, defines it as “a framework for implementing agile practices at enterprise scale.”

Transitioning to Scrum

The transition from traditional to agile should be careful and very well aligned internally. Just like any other organizational culture change, due to the impact it will bring to employees.

Teams in each department should be multidisciplinary. Organizational silos should be reduced as much as possible so that synergy between departments is always prioritized.

This synergy and multidisciplinarity will help with Agility, since employees proficient in multiple fronts will be able to help each other and bring diverse perspectives to the company.

It is expected that some employees will show resistance to the transition process. This is where the primary role of department leaders comes in. They should align expectations transparently at all times and explain what improvements will be gained for each department with the implementation of Scrum — or any other agile methodology.

Scrum Success Stories

Scrum is one of the tools that can be part of Digital Transformation. For this reason, some of Scrum’s success stories were mentioned in our Digital Transformation article.

Two of the most iconic stories are those of GE Healthcare (formerly IDX Systems) and the FBI. The GE story was mentioned in the Scrum of Scrums section of this article. It is available translated in full here on our blog.

At Zappts, development teams are managed with Scrum. Each team is dedicated to each project, not receiving requests from parallel projects. This ensures agility and good progress of Sprints. The quality of the solutions we offer to clients is assured in this way.

---

Trackbacks/Pingbacks

• Managing Remote Squads | Zappts Blog – […] I mentioned, choosing an agile work model like the Scrum Framework gives us a range of tools, such as…
• Unveiling Serverless – Cloud Computing | Zappts Blog – […] following the content on our blog. We have articles on UX, Scrum, and many other topics in the field of […]
• Scrum vs. Kanban. And the Winner Is… | Zappts Blog – […] to learn more about what Scrum is, I recommend reading this article, available in our […]
• Management 3.0 – Zappts Blog – […] the Zappts blog to learn more about team management and also enjoy our content on Scrum, Transformation…
• Sprint Planning: How to Minimize the Risks Involved? – Zappts Blog – […] Want to learn more? Check out our publication Scrum: understand once and for all what it is, how it…