Today it’s Scrum’s turn! You’ve already read about agile methodologies in general, you’ve delved into the Kanban methodology, and now you’re going to get a better understanding of how Scrum, this famous task planning and management framework, works!
What is it and how did it come about?
The history of Scrum began in 1986 with the article “The New Product Development Game”, published in the Harvard Business Review and written by Hirotaka Takeuchi and Ikujiro Nonaka. In it, the authors explain how the process of developing and producing products is carried out by multidisciplinary teams working together from start to finish.
Inspired by the article, in 1993 Jeff Sutherland and his team at Easel Corporation created the Scrum process, which was presented by Jeff himself and Ken Schwaber in 1995 at the OOPSLA Conference.
Scrum is a term used in Rugby and refers to the act of restarting the game when there is a foul or when the ball goes out of play. With this, you can already see a little of the logic of this methodology: the importance of closely monitoring each stage of the process and thus, the moment an error is identified, turning your efforts to correcting it.
In this sense, in Scrum, the project is divided into small cycles (iterations) of activities, called Sprints. Each Sprint corresponds to a predetermined time interval in which the tasks must be carried out by the team. This structure makes it possible to constantly monitor the project, making room for frequent feedback and changes in planning.
In order for everything to work and for the project to be delivered with the quality and in the short time proposed by Scrum, the team must be aware of all the activities and tasks. In this way, the work must be collaborative and well visualized by everyone. Transparency is a super-important point in this methodology.
Scrum has many peculiarities, which is why it’s interesting to analyze how it actually works, examining each stage of its cycle and the terms used.
How does it work?
To begin with, let’s remember how the team is divided:
- Product owner: is responsible for creating the product backlog, i.e. the set of functionalities of the product being developed. They take care of the technical side, acting as a mediator between the client and the team.
- Scrum master: is responsible for ensuring that Scrum is being applied correctly (reinforcing its values, principles and practices), for removing obstacles during the process and for organizing meetings. He acts as a facilitator.
- Development/Scrum team: the team, which is multidisciplinary and self-organized, is responsible for developing and testing the product. Everyone works together and the team usually consists of 6 to 10 people.
Knowing this, we can move on to the process. The first step is analysis and planning by the Product Owner. As we’ve just said, he’s going to make the Product Backlog, with what should be prioritized during the project.
The project is then divided into Sprints, each of which usually lasts between 2 and 4 weeks. There is a meeting between the team so that everyone can visualize and understand the tasks and how the process will be carried out. Then, with the tasks listed in the Product Backlog, it is decided what will be done in each Sprint, and then these activities are moved from the Product Backlog to the Sprint Backlog.
Four types of meetings are held throughout the process: the Sprint Planning Meeting, the Daily Scrum, the Sprint Review Meeting and the Sprint Retrospective.
1. Sprint Planning Meeting
This is the meeting that takes place before each Sprint. With everyone involved in the team present, the tasks from the Product Backlog that must be prioritized are defined, and these will generate the Sprint Backlog. This is done by the Product Owner who, together with the Scrum Team, outlines the objectives for that Sprint.
Afterwards, the Scrum Team decides amongst itself how much of what has been planned the group feels capable of doing. At that point, they commit to carrying out those tasks.
2. Daily Scrum
The Daily Scrum is a quick and objective daily meeting so that the team can discuss the activities carried out, what needs to be done that day and any impediments that may have arisen. It will then be clear what the priorities are for the day. These meetings serve to disseminate information about the status of the project.
As for impediments, it will be the Scrum Master’s responsibility to resolve them as soon as possible.
3. Sprint Review Meeting
At the end of each Sprint, the Sprint Review Meeting is held. Here, the participants discuss what has been done during the cycle and assess whether the objectives have been met. The ideal is to have managed to execute the entire Sprint Backlog, but the main thing is to know if the overall objective has been achieved.
This meeting should be attended by the Product Owner, the Scrum Master, the Scrum Team, management, customers and everyone involved in creating the project. In addition to what has already happened, they also discuss what the next tasks should be. The meeting should last no more than 4 hours and is more informal.
4. Sprint Retrospective
The Sprint Retrospective takes place immediately after the Sprint Review Meeting. Here, the purpose is to understand how the process is going in order to improve and evolve. The following questions are answered:
What’s working?
What can be improved?
How can these changes be applied?
This ensures greater productivity and quality for the project. This event is more formal and should last a maximum of 3 hours.
After all the meetings, the cycle is completely finished, and this is repeated until the project is completed, with the final handover to the client.
It is worth mentioning that it is common to use aBurndown Chart, which helps to monitor the project’s progress at the end of each Sprint. This is a chart that shows the relationship between the work that still needs to be done (vertical axis) and the time left to do it (horizontal axis).
Benefits
1. Adaptability
With Scrum, the team can understand what gives good results and choose how to proceed with their project. Insisting on initial planning to the detriment of quality is definitely the opposite of what the Scrum philosophy preaches: the idea is to always be on the lookout for what works, bearing in mind that each team works best in its own way. Being open to change is part of the process!
2. Continuous improvement
Through constant feedback and meetings, the tendency is for the project to evolve with each change made. The result is continuous improvement of the product and process. The more you make room for mistakes to be pointed out during the project, the easier it is to please the client and deliver an improved product.
3. Transparency
The whole team needs to see what’s going on. Only then will the work be truly collaborative. The members must be aware of the details: what stage the process is at, how they can be useful, the evolution of the team and what the strengths and weaknesses are so far.
4. Time reduction
By using Scrum, you can get an idea of the average time spent on each activity. With the adaptations, the consequence is also to reduce the time it takes to carry out the tasks, as the process is constantly being improved. In addition, as the client has access to the product before final delivery, they will be able to see and evaluate the functionalities more quickly.
5. Lack of titles
Some research has already analyzed the relationship between the designation of titles and performance at work. It was concluded that when there are no predetermined titles, people work better. As there is no defined division of the team and everyone is considered part of it (the Scrum Team), the environment is much more collaborative and open to everyone taking responsibility.
You’ve seen that Scrum promotes close monitoring of the project with a detailed record of the progress of tasks, bringing more agility, quality and efficiency. It can even be combined with the Kanban board to make the work even more visual.
So what are you waiting for to improve your projects using this methodology? No wonder it’s so popular! That’s why it’s worth venturing out and applying Scrum to your work routine.
