How to Implement Scrum in Your Company: Step by Step

Introduction about Implement Scrum

About Scrum Popularity

That Implement Scrum is a fever amongst practically all Startups and several companies in traditional branches, we all know. But if you still want to implement Scrum in your company or are having problems with the change to it, this article is for you!



Let's say that 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 that 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. The cause of these problems is probably not the responsibility of your teams, who do not deliver on time, their cause most likely is the method used to manage their work. So, you decide to implement Scrum. And that is why, in the early 1990s, Scrum was created.

This methodology was created by joining some concepts of Lean and iterative development, with the intention that, each Sprint (a period of time fixed between 1 to 4 weeks, normally) was delivered value and tested the new tools or features and it is currently used in about 60% of projects that use agile development methodologies.

“Ok, I understand what implementing Scrum is and I want to do it in my company, how do I do it?”

Simple, follow this guide and you, step by step, will be implementing this methodology in your teams, one by one, until you have a completely agile company!

Chapter 1

Don't start trying to apply across the company at once!

This step may seem controversial, since if everyone says that Scrum is a great methodology to work with, why not implement Scrum directly in all sectors of my company?The answer 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 the 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 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 is carrying out the good practices of the Scrum methodology.

Chapter 2

Define a Product Owner (PO) for your team

You do not need to hire someone new to your team to be your Product Owner, with the thought of starting everything with a test, the most experienced member in the field (not necessarily the oldest) may be the PO.


The function of the PO is to be the voice of the customer within the team. He will be responsible for creating the tasks to be carried out, 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 and he is the only one who has the power to tell whether the task generates the necessary value or not. He owns the Product, not the process.

For a good PO, we look for a person who has greater contact with interested parties, thus getting a bigger idea or that generates value for them, in addition to having an improved communication skill, for all members who understand or who is delivery of each task.

Chapter 3

Define a Scrum Master for your team

Okay, you already have your team and your PO, but who is going to direct the team to do the work with the best practices to implement Scrum?


That’s where the figure of the Scrum Master comes in, a leader-server who has the role of helping the team to follow the best practices of Scrum, making the 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.

Chapter 4

Create a Backlog with all the tasks that can generate value

Now, with all the functions determined, it's time to start thinking about what the team can do that would bring value to the company's customers or leads.


In the future, this will be a function mainly performed by the PO, creating tasks and defining objectively from which moment they can be considered as “ready”. But initially, mainly due to the inexperience of the PO in his new role, it is common to use a Brainstorming meeting with the members to define, and document, everything that can generate value in some way to whom we want to reach.

At this point, you don’t need to focus on what order the tasks should be performed, just try to extract everything that is possible within the creativity and knowledge of the team and the PO on generating value.

Chapter 5

Sort the Backlog in order of value

Okay, at this point we already have the functions of each member determined and a list of tasks to do, now what?


Within the Scrum framework, the priority of carrying out tasks should be carried out thinking: “What will generate the most value/impact for whom I am trying to reach?”. As in the previous point, in the future, this function will be mainly of the PO, but as here we are still showing how to implement Scrum and sometimes you may not have so much experience with it, at first we can (and should) use the knowledge of the entire team in order to define which activities will generate the most impact in order to achieve the team’s objectives.

Chapter 6

Define the duration of a sprint

"Easy, what is a Sprint?". A Sprint is a time-boxed event (of predetermined and immutable duration) in which the team will perform the tasks of the Backlog and deliver them for the approval of the PO according to the definitions of “ready” that was defined during the creation of this Backlog.


A Sprint usually lasts from 1 to 4 weeks, and this time is determined by thinking: “How long will we be able to generate real value to our targets (customers, leads, etc.)?”. Usually, shorter Sprints are used for teams with greater uncertainty and with a higher occurrence of unplanned tasks, such as customer calls and other situations that need to be solved and that cannot be left until later.

For example, a Customer Success team, which frequently receives calls from customers, is a team with more uncertainty than a Marketing team, therefore, it usually has Sprints with a shorter duration.

Chapter 7

Estimate the size of tasks

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 the author of the book “Scrum: the art of doing twice the work in half the time”, Jeff Sutherland says, when we estimate a task using hours, we usually make a mistake of 4 times, down or down 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 implement Scrum, we prefer to use two different methods, Story Points or T-Shirt Sizes

Story Points

When estimating the duration of a task using the Story Points method, each team member must have access to a deck of cards with the Fibonacci sequence numbers (1, 2, 3, 5, 8, 13), choose a card that, in his understanding, considers it 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 has not remembered a tool that helps, or the other may find the task less complex than it really is due to team be more aligned and arrive in numbers closer.

After the round is completed, a simple average is made of all Story Point numbers that have been chosen.

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).

T-Shirt Sizes

This is the way we most recommend it to be used for teams that are starting their journey with Scrum, as it is simpler to understand and reach a consensus.

By this method, we will use shirt sizes (XS, S, M, L, XL, XXL), with each member having a deck of these sizes and voting, in the same way, on the complexity that considers that task (less complex tasks are XS, while super complex tasks are XXL).

As in the previous example, if there is a difference of more than 2 letters between members, an explanation must be made by the members who voted for the most divergent sizes, in order to reach a closer consensus.

After performing the round, we will use the Fibonacci sequence numbers to represent each shirt size (XS = 1; S = 2; M = 3; L = 5; XL = 8; XXL = 13) and perform an average to know how many points that “worth” task.

Example: Matheus thought the task had a complexity M, Ana voted for L and João voted for M. These Sizes T-shirts are transformed into numbers, the results are added (3 + 5 + 3 = 11) and divided by the number of meeting participants (11/3 = 3.67).

Important: If there is unanimous consent that a task is XXL, this task must be broken into smaller ones that are possible to be reached during a Sprint.

Chapter 8

Plan your first Sprint

In this step, we aim to determine the number of Story Points that the team will be able to “consume” during the Sprint time, in addition to making the “Ready” Definitions clear to all who will participate in the Sprint.


As for a first Sprint, we don’t have data on the team’s performance before, we recommend a different approach for it. Do not set the number of tasks or Story Points as an objective, but to complete as many of them as possible. By performing the first Sprint in this way, we will have a basis for the next Sprints of how much that team is capable of producing, and we will do our best to increase these numbers in the subsequent Sprints.

If the team has a much higher speed than expected, there may be a need to estimate the size of tasks that have not been estimated before. If you see that the team will exceed the number of tasks that have been estimated, hold a new meeting (shorter this time) to estimate some more tasks.

Chapter 9

Track your first Sprint

It is not enough to have defined the functions, prioritize tasks, estimate their size and effectively start your first Sprint to say that you are using Scrum. Being an agile management framework, we must accompany the team to help wherever we can, and we do this mainly through an event called Daily Scrum.


Daily Scrum

The Daily Scrum consists of a meeting with a defined maximum time of 15 minutes, in which each member of the team must answer 3 simple 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, to 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?

Chapter 10

Sprint Review

Getting here, we have already gone through the definition of functions, prioritization, and calculation of task estimates and an entire Sprint! “But what do we do now? Do we repeat it indefinitely? ”. No, we must improve the process so that with each Sprint, we have an improvement in productivity in our teams, and the first step for this is to conduct a Sprint Review meeting with the team at the end of the Sprint.


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.

Remembering that only what was 100% accomplished (complying with the definitions of “done”) is presented here, because in this methodology, we say that half of the work done is worse than not having done anything since time was spent in doing 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 needed to generate value for the customer or target audience, having the power to veto any changes made by the team.

Chapter 11

Sprint Retrospective

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 the team’s 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.

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?

Based on the responses obtained in the Sprint Review and the Sprint Retrospective, an Action Plan must be created so that we can resolve the problems that have arisen and replicate the actions that worked, thus achieving the desired continuous improvement.