Scrum: Everything You Need to Know About It!


If you are reading this paper, you clearly have an objective.

You want to learn how to manage your teams in an agile way so that they deliver faster and with higher quality. Meet Scrum!

Chapter 1

Why not use traditional methodologies?

We are not saying that traditional methodologies are all bad and don't work. They worked for a long time, and even today they are used a lot!

But traditional methods of project management are extremely plastered for today, having plans that are often too long and that after some time are not as relevant as they were thought to be.

When managing a team or project using traditional management methodologies, a long period of time is usually planned, and when the teams are going to carry out the plan, any adversity already makes the previous plan no longer correct. Furthermore, during the planned time, the customer’s needs may change (or it may be that you have not understood his real need), causing your deliveries to not generate the necessary value for him. Today’s companies need more agility and adaptability to stay on the market and prosper.

Thus, companies that were experiencing greater growth than normal in the market noticed that they needed a leaner and more agile way to manage their projects and teams. The new method to be used should provide employees with clarity about the necessary deliveries and be composed of smaller cycles, so that there would be more adaptability, transparency between managers and employees, in addition to enjoying learning in each cycle, making the next one always better than the previous ones.

Chapter 2

Let's say you are a project manager or a strategic manager of the company where you work and your projects have constant delays or deadline markings, and when they manage to finish the job, they take time to know if the new features or functions that have been implemented really have the effect. desired in the customers you want to be impacted by that.

You do everything as the book says, study the necessary prerequisites to accomplish the task, study the availability of members in your teams, make the estimates of the time and resources needed to implement the change, but for some reason, you always end up having delays and functionality is not always what customers really want.

It was precisely for these reasons that the Scrum methodology emerged, a methodology that was born in the early 90s and was popularized by Jeff Sutherland and Ken Schwaber, which combines concepts of Lean management and iterative development. The methodology emerged with the aim of making the management of software development projects, focusing on constant deliveries, focused on creating value for stakeholders and quick feedback cycles, but it is already used in all areas imaginable, such as education, civil construction and even government projects. The objective of this methodology is to increase the speed of deliveries, as well as to reduce wasted work and increase the perceived value of each delivery.

The methodology was disseminated to the general public through a book authored by Jeff Sutherland: “Scrum: The Art of Doing Double the Job in Half the Time“.

Chapter 3

How to use Scrum in your company

“OK, João, I already understood the benefits of Scrum, but how do I start using this methodology?”

The first tip we give is: don’t start by trying to apply the methodology to your entire company at once.

“But if the methodology is so good, why don’t I apply it to the entire company at once?”

I know it may seem controversial, but the answer to that question is experience.

When the process of transition from a traditional management model to Scrum begins, both teams and managers do not usually have experience working with this new model, and we do not want to lose productivity until they are adequate, do we?

So our tip, as experienced in this, is: start by implementing some principles, little by little, in a specific team that is willing to change the current work model to a more effective one and, after seeing the results, continue implementing other principles until that team and soon the entire company is carrying out the best practices of the Scrum methodology.

So the first step in using Scrum in your company is to study, learn from the mistakes and successes of others and to implement, in a controlled and natural way, the practices of this methodology.

Chapter 4

Necessary functions for the operation of Scrum

Product Owner (PO)

The function of the PO is to be the voice of the customer within the team. He is the one who ensures that the team’s efforts add value to the business. He is responsible for creating the tasks to be carried out, always focused on the customer’s needs, describing their acceptance criteria (for the team to know when the task is actually ready) and prioritizing them by which they will generate more value to customers in addition to be the only one who has the power to say whether the task generates the necessary value or not. He owns the Product, not the process.

Scrum Master

Another leadership role in Scrum is needed to direct the team in a way that does the job with Scrum best practices. The Scrum Master is a leader-server whose function is to assist the team so that they follow the best practices of Scrum, making work more relevant and agile!

“Easy, but what is a leader-server?” A servant leader is one that allows the team to have a system of mutual and continuous cooperation, in which the leader and the team have the same power of speech and influence in decisions, enabling the adoption of more efficient practices and policies.

“And how should the Scrum Master act to achieve this?” Valuing the team’s ideas and opinions by encouraging innovation and creativity, strengthening respect for differences and building trusting relationships. Having a high power of persuasion, through the power of communication and questioning. Recognizing the needs, in order to keep management in line with what really matters. Identifying and preparing other servant leaders within the team, in order to make it more independent and thinking about the individual in a complete way, not only professional, realizing and acting in the face of personal problems and needs.

Scrum Team

The Scrum Team is responsible for delivering the product. The team is typically composed of 3 to 9 people with multifunctional skills, so that they can perform the necessary tasks without the support of any member of another team, and that they do the operational work (analyze, design, develop, test communication techniques, documents, etc.). We recommend that the team has the freedom to self-manage (who knows the team’s needs better than the team itself?), but that they often work with some form of project or team management.

Chapter 5

About Scrum Cycles

As stated earlier, in order to apply the knowledge obtained in each cycle, we must have shorter feedback cycles than traditional methods (which can last for a few years, many times!).

The reason for shortening the cycles is similar to the occurrence of compound interest in the financial market: with each cycle, we learn more about what we should or should not do, making the next cycle even more productive and so it follows, in a curve of exponential learning.

So that we can carry out these smaller cycles and really learn from them, we use cycles, called Sprints, from 1 to 4 weeks (more mature teams and with less occurrence of unplanned tasks tend to have cycles closer to the upper limit, while less mature teams and / or with many occurrences of unplanned tasks tend to have smaller cycles) and during these cycles, we have some events used to consolidate the learning and to make sure that we are going on the path of achieving our main goals.

Chapter 6

Sprint events

In order to use the Scrum methodology most effectively, we hold some events during the cycles to learn from what has been done in the past and to improve ourselves for future cycles.

The events normally used in a Scrum cycle are:

    • Backlog Grooming;
    • Sprint Planning (Sprint Planning);
    • Sprint;
    • Daily Scrum (or Daily Meetup);
    • Sprint review;
    • Sprint Retrospective.

And comparison can be made with the PDCA Cycle (Deming Cycle) to better understand the objective of each event within a cycle of continuous improvement.

What is the PDCA Cycle

The PDCA Cycle, also called the Deming Cycle, in honor of its creator, W. Edwards Deming, is a representation of a cycle of continuous improvement, consisting of 4 steps: Plan, Do, Check and Act. In this cycle, the first step is to plan what will be done to make an improvement in some current problem, after that, you should execute what was planned, and when you finish the practical part, check what it worked, what went wrong and how it is possible to improve so that we can carry out an even more effective next cycle and generate an action plan to make the improvements happen. The goal when using this cycle is: get it wrong fast but fix your mistakes even faster.

Next, we will show where each Scrum event fits in each stage of the PDCA Cycle.

Backlog Grooming (Plan)

During this meeting, which necessarily includes the PO and the Scrum Master, which may include any member of the Scrum Team who is interested (not necessarily), is when we enrich the Backlog previously made.

At this meeting, we seek to divide tasks that are too large to be carried out in the duration of at most one Sprint, in addition to receiving and pondering ideas that any member has had in order to achieve the company’s results, for whether they are really relevant.

Sprint Planning (Plan)

With the Backlog set up, increased during the Grooming meeting and prioritized by the PO, we go to the first meeting that will need all the members present, Sprint Planning.

In this meeting conducted by the Scrum Master, the prioritization performed by the PO may be questioned if the team sees value in other tasks (remembering that as the person responsible for the Backlog is the PO, he has the final say on prioritization), he will be able to advocate with the objective to make the PO change the prioritization carried out previously.

After the prioritization is discussed, the team will proceed to estimate how much effort will be required to complete each Backlog task. At this point, one of the main differences between traditional management methods and agile methodologies, such as Scrum, emerges.

In traditional methodologies, project managers strive to try to define the amount of time that will be required for each task to be accomplished. But as Jeff Sutherland said earlier, when we estimate a task using the hours method, we usually make a four-fold error, either less or more. For example, if we estimate that a task will take 2 hours to complete, the most common is that the time is between 30 minutes and 8 hours in duration since we are not used to making such estimates naturally.

When estimating the duration of a task, we use the Story Points method, in which each member of the team must have access to a deck of cards with the Fibonacci sequence numbers (1, 2, 3, 5, 8, 13), choose a card that, in your understanding, considers equivalent to the amount of effort required to complete that task and after everyone has chosen, turn the card over.

If there is a difference of more than two letters, for example, one member voted that the task has a size of 2, and another voted that it has a size of 8 (3 letters of difference), each must explain the motivation that led him to choose the letter (one may find it more complicated because he did not remember a tool that helps, or the other may find the task less complex than it really is due to inexperience, etc.), and so a new round of voting takes place with the aim of team be more aligned and arrive in numbers closer.

After the round is completed, a simple average of all the Story Points numbers that were chosen is made and the next task is estimated.

Example: Matheus thought that the task had a complexity of 3, Ana voted for 5 and João voted for 3. Add the results (3 + 5 + 3 = 11) and divide by the number of meeting participants (11/3 = 3.67).

At the end of the meeting, the team will decide the number of tasks to be performed on that Sprint, signing an agreement with the Scrum Master. To define the number of tasks to be performed, the team can (and should) use prior knowledge about how many Story Points were achieved in the last Sprints.

Sprint (Do)

The Sprint is a time-boxed event, which means that it has a defined maximum time, which cannot be changed under any circumstances. As stated earlier, the duration of a Sprint typically ranges from 1 to 4 weeks.

In this step, the Scrum Team will carry out the operational work of carrying out and delivering the completed tasks so that the improvements made during the Sprint can be implemented.

Daily Scrum (Check, Act)

The Daily Scrum is an event of daily occurrence, being also a time-boxed event of maximum 15 minutes.

At this meeting, the team must communicate by answering 3 questions:

    • What did you do YESTERDAY to help the team complete the Sprint goal?
    • What are you going to do TODAY to help the team complete the Sprint goal?
    • Is there any IMPEDIMENT for the team to complete the Sprint objective?

The purpose of this meeting is to align the team so that each one knows what the others are doing and know where they are in the Sprint.

With this information, it is possible to be aware of some things, such as: “Will the tasks be completed on time?” and “Is there an opportunity to help team members overcome their obstacles?

Sprint Review (Check)

The Sprint Review is the first meeting to be held after the end of the Sprint and serves exactly to discover possible points to improve the process so that each Sprint has an improvement in productivity in our teams.

The Sprint Review meeting aims to validate the work done and provide feedback on the quality of deliveries, demonstrating in practice what has been done during the duration of the Sprint.

Bearing in mind that here only what was 100% accomplished (complying with the pre-established definitions of “ready”) is presented, because in this methodology, we usually say that half of the work done is worse than not having done anything since it was spent time in carrying out that task, but it did not generate any final value, so what happened was a waste.

It is at this meeting that your PO (Product Owner) will tell you if the tasks in the DONE column are in accordance with the quality standards necessary to generate value for the client or target audience, having the power to veto any changes made by the team.

Sprint Retrospective (Act)

At the last meeting of the Scrum cycle, we entered with the mentality that we may not have the power to change the processes carried out in the past, but we can change them in order to have a better future result.

Because we want to increase team productivity, we need feedback on what went well and contributed to the team’s agility during the Sprint, so that we can replicate these behaviors in the next Sprints, as well as what went wrong and impaired the team’s agility, so that we can make an action plan so that we don’t make the same mistakes.

It is important to remember that in this meeting we do not want to find culprits or champions, but beneficial and harmful processes. It is here that we are able to readjust a team’s course so that future deliveries are always greater than past deliveries.

The objective is, at the end of this meeting, to have an action plan set up to carry out the possible improvements revealed in it, in addition to good practices that the team must continue to follow so that quality and agility do not fall.

To help guide this meeting, you can use a 3-question model to find out where you can improve and what we should continue to do, they are:

    • What happened during that Sprint that hindered the team’s agility?
    • What happened during that Sprint that helped the team’s agility?
    • What made you happy during this Sprint?

Creation of Action Plans (Act)

At the end of each Sprint cycle, with the lessons learned about what went right and what went wrong, we must put together an action plan so that we can fix what has hindered the team from reaching the defined goals and so that we can continue to do which led the team to the most satisfactory results.

We recommend creating improvement tasks with the highest possible priority in your Backlog. When prioritizing these tasks, the first thing the team will do in the next cycle will be to improve it, accelerating growth and increasing the strength of continuous improvement cycles.

Chapter 7

Artifacts used in Scrum

To put Scrum into practice, we need some items, which we will call Artifacts for a better understanding of our readers.


This artifact is what will transform thoughts about what can generate value to your company’s customers or leads into tasks or user stories.

The function of filling the Backlog with tasks and user stories is mainly performed by the PO, creating tasks and objectively defining from which moment they can be considered as “ready”. But this does not prevent members of the Scrum Team from creating any tasks they imagine that can generate value for customers or leads, we even encourage this practice at Roads, where it is common to use a Brainstorming meeting with members to define themselves, and document everything that can generate value in any way to whom we want to reach.

After having a sufficient number of tasks or user stories, it is necessary to prioritize these tasks by the value generated to the interested parties. In order to have a prioritized Backlog, one must think: “What will generate more value/impact for those I am trying to reach?”. As in the previous point, this function is mainly of the PO, but if any member of the Scrum Team thinks differently from the PO, that member can (and should) bring his point to the discussion, in order to contribute to a prioritization more correct and focused on the target audience you want to reach.

Scrum Board

The Scrum Board is a Kanban-style board with 4 areas and is used to guide the team and monitor the status of each task.

The table is divided into 4 columns, which are:

    • To Do
      • All tasks that were chosen to be carried out during the duration of the Sprint. This column can also be called the Sprint Backlog.
    • Doing
      • Here are the tasks that each member of the Scrum Team is currently performing. It is worth remembering that recent research at Stanford has shown that doing so-called multitasking results in a loss of productivity, contrary to what was previously thought. With this knowledge, it is recommended that each member perform only one task at a time and only start the next one as soon as they finish the current one.
    • Check
      • As soon as a member finishes a task, it is passed to that column to go through a process of checking it. The PO will assess whether the task meets the pre-established requirements for the task to be considered ready and whether the quality is within expectations. If the task is actually considered done, it moves on to the next column, but if it is not considered done, the PO will explain the reasons that led him to consider the task as not done and it will return to the previous column, to be corrected.
    • Done
      • In the last column are the tasks completed and checked by the PO. These tasks are ready to be launched to the market (or have already been launched, depending on the type of task).

The image below shows an example of a Scrum Board in practice, with its columns and tasks. Each task is represented by a card.

Burndown chart

How do we know the status of a Sprint, whether it is ahead, behind, or on schedule, even before it ends?

To access this information, we use a simple graph, called a Burndown Graph. To make this graph, we use the amount of Story Points on the Y-axis and the days that pass on the X-axis.

From there, we draw a straight line, dividing the total number of points planned for that Sprint by the total number of days. That is the line that will guide us to know if the state of the Sprint.

The other line that we will analyze is the line that will show the amount of Story Points remaining in each day over time. If this line is above the baseline, it means that the team has not completed tasks at the rate expected in Sprint planning, so it is late. If this line is below the baseline, it means that the team has completed more tasks than was initially planned, which shows us that the team is ahead of that Sprint. The last case is when the lines coincide, and this shows us that the team is within the planned expectations.

Chapter 8

Advantages of using Scrum

Summarizing some reasons that will take your company to another level when using the Scrum methodology, we have:

  • Scrum Team members are much more motivated due to their interest in delivering the Sprint on time;
  • With the elimination of wasted time and resources, it is possible to achieve more expressive results, increasing the team’s productivity.
  • Within the organization, the project can be observed by everyone. While in other methodologies this possibility did not exist;
  • As the activities are done in a fragmented way and subdivided into short periods of work, it is possible to detect problems early on and thus make the necessary corrections quickly. This reduces project risks and avoids rework;
  • With all project steps defined and divided into sprints, it is easier to view project progress in a clear and transparent way.

Chapter 9

Some successful cases of the Scrum methodology

Find out how big companies have transformed their ways of working with Scrum:

Rede Globo

Rede Globo has been applying the Scrum methodology on its website,, since mid-2007. During the implementation process, many problems arose and needed to be resolved.

One of the difficulties was the lack of definition of priorities and the period of adaptation of the methodology to the needs of the company.

However, the responsible team was also very successful with the initiative, having no doubt that agile processes, such as the Scrum methodology, are essential for the optimization of software development.


Reduce the time spent on software development while managing team size: these are some of the reasons for Yahoo! have bet on the Scrum methodology.

In this Internet giant, they plan, create and test different products and services during a certain period of days, in order to improve and boost more and more the technology used by them and offered to the public.


At Google, several sectors are betting on agile methods of software development, such as Scrum, creating and testing services and products. Each team chooses the technology the method that can best be applied to solve problems.

One of the projects in which the Scrum methodology was used was in the development of Adwords and we can see the results: from 2015 to the end of 2019, Google Adwords revenues grew from US$ 67 billion to more than US$ 134 billion in the year, a growth 100% in 4 years!

I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.