Index
We have often spoken about Agile methodology, focusing in particular on the Kanban framework, highlighting how it can improve workflow management and increase team efficiency. Today, however, we focus on another fundamental pillar of Agile methodologies: Scrum.
Scrum is one of the most widely used Agile methodologies globally, with 81% of Agile teams claiming to adopt it in some form. Its popularity continues to grow both among software development teams and in other industries due to its ability to improve productivity and customer satisfaction. According to recent statistics, about 86% of software teams use Agile methodologies, with Scrum being the predominant choice.
In this article, we will look at what Scrum is, its development and how it can be applied effectively in software development projects. We will discover how this framework, born more than twenty years ago, has evolved into numerous variants, always maintaining its fundamental principles of collaboration, self-organisation and adaptability.
What is Scrum?
Scrum can be traced back to the Japanese economists Hirotaka Nonaka and Ikujiro Takeuchi. In their 1986 article, ‘The New Product Development Game’, they describe what they call the ‘rugby approach’. Using a rugby analogy, they explain how successful product development teams work in close physical proximity, similar to the rugby scrum where players stand very close together. These teams operate as small, self-organised units, receiving only general direction from outside but having the freedom to decide how to achieve the common goal. This type of collaboration is aimed at maximising the success of projects.
Ten years later, Jeff Sutherland and Ken Schwaber further developed this approach into a framework for software development projects, naming it Scrum, in honour of Nonaka and Takeuchi's article. Since then, Scrum has evolved into more and more variants thanks to the contributions of numerous authors, consultants and experts who saw the framework's commercial potential. The adoption of Scrum has led to a wide range of interpretations and adaptations, while maintaining the core principles of collaboration, self-organisation and adaptability .
Scrum is based on specific roles, structured events and defined artefacts to facilitate agile development of complex projects. The three main roles are the scrum master, the product owner and the development team. The framework also includes events such as sprint planning, daily scrum, sprint review and sprint retrospective, which promote transparency, inspection and continuous adaptation. The main artefacts are the product backlog, the sprint backlog and the product increment, which help to manage and monitor work progress .
Roles in Scrum
There are three main roles in the Scrum methodology: the product owner, the scrum master and the development team.
Product owner: represents the interests of the customer. He is responsible for the commercial success of the product.
Scrum master: the term ‘servant leader’ is often used in English because he acts as rule keeper, moderator and coach and is responsible for the implementation of the Scrum rules.
Development team: the team represents the heart of Scrum and must organise itself in such a way as to achieve the respective sprint objective. It is responsible for the most important part of a Scrum project: product development.
Product owner:
The product owner embodies the interests of the customer and is responsible for maximising the value of the product. Such a role focuses on ‘what’ needs to be developed and implemented to ensure the commercial success of the product. The Product Owner's responsibilities include:
- Product backlog management: the Product Owner creates, maintains and sorts the product backlog, a dynamic and prioritised list of features, enhancements and fixes that the product is to contain. This backlog constantly reflects new requirements and user feedback.
- Prioritisation: the product owner prioritises backlog items so that the most important tasks are addressed first, ensuring that product development is aligned with market and stakeholder needs.
- Continuous involvement: actively participates throughout the development process, consulting with stakeholders to define product features and working closely with the development team during and after each sprint to ensure objectives are met.
Scrum master:
The Scrum Master is therefore a guardian of the rules within the process. He must ensure at all times, during development work, events and so on, that all participants comply with the rules according to the guidelines and that all events take place in the appropriate form. He acts as moderator and coach. In other words, the Scrum Master never acts as a project manager or project leader; his task is only to support the Scrum process. The goal is to enable the team to work according to the rules and to be efficient.
The Scrum Master is the guardian of the Scrum rules and acts as ‘servant leader’. His role is crucial in ensuring that the Scrum framework is correctly applied. The Scrum Master's main responsibilities include:
- Facilitation and moderation: he organises and facilitates all Scrum events, such as sprint planning, daily scrum, sprint review and sprint retrospective. He is responsible for ensuring that these events are conducted according to Scrum guidelines and that all team members understand their purpose.
- Coaching and support: helps the development team to follow Scrum practices and work efficiently. It provides support to resolve any impediments that might hinder the team's progress.
- Promotion of Scrum values: spreads the knowledge of Scrum within the organisation and ensures that everyone, both inside and outside the team, understands how to interact effectively with the Scrum team.
Development team
Developers are responsible for the ‘how’. How is the product developed and implemented? Developers have very particular characteristics that characterise the spirit of Scrum:
- Team size: developers form a team of three to nine members. Seven people are considered optimal. The Scrum Master and the Product Owner are not included in this calculation.
- Self-management: developers do not have project managers or sub-project managers. They manage themselves. The only specification the developers receive from the Product Owner is the type and priority of product features to be implemented in all sprints.
- Interdisciplinary: different competences and skills are available within the team.
- No role: the roles within the development team are all equal. Titles are therefore not relevant. However, this does not mean that there are no different task assignments within the individual developers.
- The team as a unit: although developers may organise tasks within the team with different competences, they always remain jointly responsible for the achievement of the objective of a sprint.
The main task of the development team is to build the increment of the product during the sprint. The developers focus on this objective, subordinating all other activities to this main priority.
Artifacts in Scrum
Scrum artifacts comprise three main components: the product backlog, the sprint backlog and the increment. These elements serve to ensure transparency and provide the necessary information for the scrum team to successfully implement the product.
Produkt backlog
A product backlog is an ordered list of all features, enhancements, and corrections that the product is to contain. Each item in this list is called a Product Backlog Item (PBI). This list is dynamic and constantly evolving, reflecting new requirements, user feedback, and changes in the market.
While the backlog is never complete, it lives throughout the development process and is constantly reviewed and adapted, representing the single source of requirements for any future changes to the product. Although it initially contains a preliminary version of the intended functionality, it changes as the product and its understanding develop.
Each PBI in the Product Backlog is detailed in such a way as to be understandable and manageable by the development team. The Product Backlog includes not only new functionalities, but also all backlog elements and user stories already developed
Sprint backlog
The sprint backlog is a subset of the product backlog, consisting of the elements selected to be developed during a specific sprint. It provides a clear view of what is to be realised in the current sprint and the progress towards the sprint goal.
Managing the sprint backlog is the sole responsibility of the developers, who may make changes and adjustments as required. for an element to be transferred to the sprint backlog, it must be sufficiently detailed to allow the development team to work on it effectively. in addition, it must be considered feasible within the duration of the sprint.
A sprint backlog includes a detailed plan on how the team will achieve the sprint objective and deliver the expected increment. This plan is specific and must be so detailed that it can also be used on a day-to-day basis.
Increment
An increment is the product in its most recent delivery state, including everything that has been implemented in the current sprint, together with the value of all previous increments. As such, it is essentially the most recent version of the product, incorporating all functionality developed up to that point.
Developers are responsible for creating the increment and ensuring that it conforms to the team's definition of ‘done’. Once completed, the increment must be handed over to the product owner, who decides whether or not to release it.
An important requirement for the increment is that it be in a potentially releasable state. This means that it must be ready to be put into production or to be used, regardless of the product owner's final decision. Such quality control does not only take place at the end of the sprint, but also during the course of the sprint, ensuring that the increment is always maintained in a releasable state.
Events in Scrum
Scrum defines five core events for project management. These events structure the work of the team and are designed to promote transparency, inspection and continuous adaptation. Although no other events are planned beyond these, it is important to emphasise that communication can and should take place outside of these specific moments.
Sprint
A sprint is the heart of the Scrum framework. It is a fixed period (one to four weeks) during which work is done to achieve the set goals. Within the Sprint, key events include sprint planning, daily scrum, product development, sprint review and Sprint retrospective. The sprint itself is not an isolated event, but a container that encompasses all the other events. The product owner, scrum master, developers and stakeholders participate in the sprint.
During a sprint, no changes are made that could compromise the objective. The quality of the work must not be undermined and any changes to the scope must be negotiated between the product owner and the development team if they are useful for learning. The main objective is to complete the work planned in the Sprint backlog, with the team having clearly defined roles and responsibilities.
Sprint Planning
Sprint planning is the initial meeting of each Sprint, aimed at planning the work for the next Sprint. The whole Scrum team participates in this event: the product owner, the scrum master and the developers. The duration of the planning varies, but for a four-week sprint, it can last up to eight hours. If the sprint is shorter, the planning will also be proportionally shorter.
The scrum master is responsible for ensuring that the planning of the sprint takes place and that all members of the scrum team understand the objective of the event. The scrum master is also responsible for ensuring that the sprint planning remains within the agreed time frame in terms of duration.
Daily Scrum
The daily scrum is a short daily meeting, usually lasting a maximum of 15 minutes. It is always held at the same time and place to reduce organisational complexity. During this meeting, the development team synchronises activities and plans the work for the next 24 hours. Each team member answers three main questions:
- What did I do yesterday to help the team achieve the sprint goal?
- What will I do today to help the team reach the sprint goal?
- Are there obstacles preventing the team from reaching the sprint goal?
Sprint Review
The sprint review is held at the end of each sprint to inspect the product increment and adjust the product backlog if necessary. Here, the completed work is shown to the stakeholders, who provide feedback and suggestions. The entire Scrum team and key stakeholders participate in the review, which can last up to four hours for a four-week sprint.
The main objective is to gather feedback and promote collaboration.
Sprint Retrospective
The sprint retrospective is the last event of a Sprint, focusing on continuous process improvement. At this meeting, the team reflects on how the Sprint went and identifies areas for improvement in the future. The point is not to evaluate the product, but to improve the team's processes and interactions. The retrospective takes place after the sprint review and before the next sprint planning, with a maximum duration of three hours for a four-week sprint.
The scrum master is responsible for organising the event and facilitates it, ensuring that everyone understands the purpose and actively participates.
Benefits of using Scrum
More flexibility in design
Because Scrum rules are simple and well-defined, they allow rapid adoption by individuals and teams. This makes it easier to continuously adapt working methods in response to changing requirements, making the process highly agile thanks to adaptive planning. Scrum thus takes the form of a continuous improvement process.
Regular checks for rapid identification of problems
Scrum includes daily meetings and reviews at the end of each sprint, allowing teams to constantly monitor progress and address challenges through effective communication channels. This approach allows problems that emerge to be identified and resolved quickly.
Clear responsibilities, transparency and self-organisation
In Scrum, the roles and responsibilities of each team member are well defined, thus facilitating collaboration and project execution. Thanks to regular agreements and backlogs, there is a high level of transparency. Each team member has the freedom to decide for themselves how and when to complete their tasks, promoting self-organisation of the team and reducing the administrative and documentation burden.
Collaboration: increased team spirit in the project
Scrum promotes collaboration and communication within the team through regular feedback loops and common goals. Being aware of the tasks and challenges faced by each member makes it possible to support each other, strengthening the sense of belonging and teamwork.
Conclusion
As an agile project management tool, the Scrum method offers a flexible and efficient way of managing projects. It promotes teamwork, communication and consultation, and provides each team member with clear responsibilities and tasks to fulfil.
