When people talk about Scrum, we often hear about Agile. Although they complement each other, Agile is not a methodology but a philosophy.
The Agile approach is about setting values and principles that the entire company should follow, whereas Scrum is a practical tool that puts into practice the Agile philosophy.
If you need to improve your processes to thrive in a fast-paced environment, stay with us and keep reading!
Rugby and teamwork
Scrum is an agile framework that helps manage projects and organize work demands while assisting teams to be more efficient and continuously improve their products.
Hirotaka Takeuchi and Ikujiro Nonaka used the term ‘Scrum’ for the first time in a famous article published by Harvard Business Review in 1986.
The authors made an analogy with the Rugby game to emphasize the importance of teamwork — where the ball is passed to each team member as it moves or advances.
The pillars of empiricism
Scrum is based on an empirical process, where knowledge is only possible through experience. This way, the learning process takes place by observing reality.
To work with Scrum and put empiricism into practice, everyone should be transparent in their actions and tasks. This clarity allows the team to inspect the process and the progress toward the established goals.
If the team notices that something could be improved upon inspection, they should adapt accordingly. It’s all about continuous improvement.
As you can observe, empiricism involves three pillars that set the ground for the Scrum framework:
How can you benefit from Scrum?
Since we live in a fast-paced and fiercely competitive environment, companies must always be ahead of their competitors to stay relevant.
This way, anything that can bring speed and flexibility to internal processes adds value to the development of new products.
And that’s what Scrum proposes: it allows a faster workflow without losing focus on the customer, as the method is concerned with delivering value to users on an ongoing basis.
In addition, values and beliefs are naturally ingrained in us, and it can be hard to change the way we think. But, changing the way we work is quicker to change and more approachable.
Thus, Scrum serves as a starting point for teams to become agile in the future.
Below are a few additional benefits to the Scrum method:
- Decreases the time-to-market, that is, the timeframe between an idea and the launch of a product/service;
- Increases delivery predictability;
- Improves responsiveness to the customer;
- Adaptation to change: allows you to change direction by changing priorities;
- Enhances the quality of your product/service;
- Helps manage and mitigate risks;
- Decreases costs;
- Increases employee engagement and satisfaction.
Hands-on: Applying Scrum
The Scrum framework is a continuous improvement system, which means you can adjust processes and needs based on information gained during development.
A Scrum team has 3 defined roles, 5 events, and 3 artifacts that they will collect along the way. Together, they provide the framework to keep your process transparent by continuously inspecting and adapting it.
Before we detail the roles, events, and artifacts prescribed in Scrum, here’s an overview of the whole cycle:
- Define roles: you will need a Product Owner, a Scrum Master, and of course, team members.
- Create the Product Backlog: the Backlog is a list of everything the project needs, in order of importance. The Product Owner is primarily responsible for this task.
- Plan the Sprint: choose which tasks from the Backlog should be completed and who will be responsible for them.
- Execution: team members (development team) work on their tasks, and everyone checks each other’s progress in the Daily Scrum. This meeting shouldn’t take more than 15 minutes.
- Review work: at the end of each Sprint, the team evaluates and presents a possible Increment.
- Review the process: during the retrospective meeting, the team reviews their process and check what could be improved for the next Sprint.
- Repeat: choose more tasks from the Product Backlog and repeat the process.
The three roles
Scrum has three specific roles:
- Product Owner: speaks for the user and has the final word on the project needs;
- Scrum Master: helps maintain the principles of the Scrum framework;
- Developers/Team Members: responsible for execution.
Product Owners are responsible for the Product Backlog and act as user representatives before the team, always advocating for the user.
A good PO clarifies the most important aspects to be delivered, such as defining product requirements, content, delivery date, and prioritizing the needs according to the business.
They also decide whether something is ready to be delivered or not, so they are responsible for accepting or rejecting Increments.
It’s the responsibility of the Scrum Master to apply the framework and make sure everyone is following the values and practices of the method correctly.
You can see the Scrum Master as a facilitator of the project. They are the ones who facilitate daily meetings and lead the Sprint planning, review, and retrospective meetings.
The team members are responsible for the execution of tasks. That is, turning the Product Backlog into reality.
The team should have between 5 and 9 members: it shouldn’t be too small because a project needs diverse skills, but it shouldn’t be too large since this would slow communication.
Remember: the scrum goal is to have an agile, proactive, and organized team.
The three artifacts
There are 3 artifacts in Scrum:
- Product Backlog;
- Sprint Backlog;
1) Product Backlog
Product development involves complex steps, so when preparing the Product Backlog, the steps are ‘broken’ into smaller tasks listed according to their urgency.
The Product Backlog is a general listing of all the things that need to be done within a project, where the Product Owner is responsible for this list.
Product Owners are in charge of reordering and updating the Product Backlog based on feedback gained from users, the market, or team members.
2) Sprint Backlog
The sprint backlog is a set of assignments pulled from the Product Backlog that your team has committed to completing during a specific Sprint. The number of tasks should be compatible with the Sprint Duration.
These tasks are chosen during a Sprint Planning out of the Product Backlog general list.
3) Increment x Definition of Done
The result of a Sprint cycle is a possible release or ‘deliverable increment.’ The increment can be a new product, a feature improvement, or a technical problem correction.
Think of an app or software that you use; you probably receive notifications about updates from time to time. This update can either be a new feature or simply bugs corrections.
During a Sprint Review, the increment is presented and planned, and your increment will only be releasable if the team considers it as done.
Remember: the Definition of Done (DOD) is a combination of criteria pre-established by the team, in which a product increment is only considered Done when all requirements are met.
Therefore, the DOD should be frequently reviewed as criteria or processes may change.
The five events
A Sprint refers to a complete cycle of the Scrum method and lasts from 1 to 4 weeks. At the end of each cycle, a new one starts immediately.
It’s essential to consider the relationship between the time available to complete a project and its difficulty level to define the duration of a sprint.
Within a Sprints cycle, there are five stages, called Events or Ceremonies, they are:
- Sprint Planning;
- Sprint Execution;
- Daily Scrum;
- Sprint Review;
- Sprint Retrospective.
1) Sprint Planning
During a Sprint Planning, the Product Owner and the team get together to analyze the Product Backlog and, according to priorities, choose the items that can be completed during the next Sprint.
In addition, the development team gives an estimate of how long each member needs to complete their respective tasks.
Since Sprints last from 1 to 4 weeks, the planning stage should last between 2 and 8 hours, not more than that.
The goal is to have a Deliverable Increment at the end of each Sprint.
2) Sprint Execution
After planning, the development team starts working on their tasks.
In alignment with Scrum values, no one has to tell team members how or in what order they should work on tasks from the sprint backlog.
The team plans autonomously, setting their own priorities as they see fit.
3) Daily Scrum
This is a daily meeting that takes place during the execution phase and lasts for a maximum of 15 minutes as is intended to be quick and practical.
During the meeting, each member must answer three questions:
- What was done yesterday?
- What will be done today?
- Is there something preventing the progress of a task?
If there is a problem, the Scrum Master should deal with it separately in another meeting with the members necessary to resolve the issue.
4) Sprint Review
The Sprint Review should not last longer than 4 hours (1 hour for each Sprint week), and the goal is to inspect the Sprint results.
Based on the increment presentation, the Product Owner must validate it or not.
If the Increment or any completed item is not approved, the respective tasks must go back to the Product Backlog to be improved.
According to Scrum.org, the team can take several actions during this meeting; here, we list a few:
- Team members present which Product Backlog items have been ‘Done’ and answer questions about the Increment;
- The developer team exposes issues that occurred during the Sprint and how they handled those obstacles;
- Review of how the market may have changed and what is the most important thing to do next;
- Review of schedule, budget, and product capability;
- The Product Backlog can be adjusted to meet new opportunities.
5) Sprint Retrospective
In the Sprint Retrospective, the meeting shouldn’t last more than 3 hours, and the objective is to evaluate the team’s performance and plan how they can improve the quality and effectiveness of the process.
During the Sprint Retrospective, the team should reflect and debate on:
- Highlights of the process.
- What didn’t work well?
- What should we commit to improving in the next sprint cycle?
This way, the team inspects how efficiently their processes, tools, and Definition of Done were during the last Sprint.
If you want your team to benefit the most out of this framework, make sure that all members involved are sticking to these five values:
- Commitment: the team must commit to achieving their goals by supporting each other;
- Focus: the main focus is working during the Sprint to make the best possible progress towards the objectives;
- Openness: the team and stakeholders are open about the work and potential challenges.
- Respect: team members respect each other, trusting that everyone is capable and independent to carry out their tasks.
- Courage: they have the courage to do the right thing and work on problems that need improvement.
So, when implementing the Scrum method and making decisions throughout the project, keep in mind that your actions should always reinforce these values, not diminish them.
When the values of Scrum are lived out, the key pillars of transparency, inspection, and adaptation are put to the test, helping to create a work environment based on trust.