What is Scrum, what events, roles, artifacts exist and what are the advantages?
Scrum is an agile framework for the development and maintenance of complex products and services. Originally designed for software development, Scrum is now used in many areas and industries for product development and project management.
The Scrum Guide, which contains the rules for using Scrum, defines five events – also known as rituals, activities or events:
- Sprint Planning,
- Daily Scrum,
- Sprint Review and
It contains three roles:
- Product Owner,
- Scrum Master und
- development team.
And it names three artefacts:
- Product Backlog,
- Sprint Backlog and
- Product Increment
These events, roles and artefacts are the core of Scrum.
The approach of Scrum is empirical, incremental and iterative. It assumes that many development projects are too complex for an exact planning and description, since many requirements and solutions are unclear at the beginning of the project. These ambiguities are eliminated by a step-by-step approach and the development of potentially deliverable increments.
Scrum addresses the collaborative development of complex products and services. The team, equipped with the necessary competencies, organises itself within fixed timeboxes, committing itself to delivering finished functionality regularly and as early as possible.
The heart of Scrum is the Sprint. It includes the Sprint Planning, in which it is agreed “what” “how” is implemented. In the course of the implementation there is a daily meeting called Daily Scrum. It serves the synchronisation among each other. In the Sprint Review, the work done is evaluated and an increment is generated that must be functional and potentially deliverable. In the Retrospective the cooperation in the past Sprint will be discussed with the aim to improve the future cooperation. And the process starts all over again.
Advantages of Scrum
Because predictions and the creation of realistic plans are often difficult when developing software and systems, Scrum turns the approach around: knowledge comes from experience and experience comes from the course of a development. In combination with the iterative approach, the commitment of the team to the sprint goal and the early detection of obstacles (the so-called impediments), the predictability increases and the development risk decreases.
In summary, Scrum offers the following advantages:
- Simple set of roles, activities and artefacts; easy to understand and use.
- High flexibility when working with Scrum.
- Concentrated communication between Scrum roles.
- Immediate feedback between roles in the course of activities and from stakeholders.
- Transparency of work steps and intermediate results.
- The ability to identify and correct deviations.
- The ability to adjust the existing process in the current project.
The Agile Manifesto
In 2001, 17 authors, including Ken Schwaber and Jeff Sutherland, the inventors of Scrum, and Ken Beck, one of the three founders of Extreme Programming, formulated the Agile Manifesto. It defines guidelines and principles that are applied in Scrum:
- Individuals and interactions are more important than processes and tools.
- Functioning software is more important than comprehensive documentation.
- Cooperation with customers is more important than contract negotiation.
- Responding to change is more important than sticking to plans.
These guiding principles – often declared as values or understood as value pairs – always contain two sides. The left side (e.g. “individuals and interactions”) is more valuable than the right side (e.g. “processes and tools”). Of course, the right side must not move too far into the background; e.g. not all functions of a software can be comprehended without documentation. When developing solutions, it is therefore important to ensure that the value pairs are balanced.
In a way, the Agile Manifesto describes a code of conduct to reflect the actions of a development and to align them to defined principles. Building on this, Scrum provides a framework to organise and execute the work jointly.
A guiding principle of Scrum is the development of products in short cycles or increments. These short cycles are called sprints. They are the heart of Scrum. It is important that sprints have a consistent duration throughout the entire development process. When working with parallel teams, organisations should ensure that sprints run synchronously so that there is no unnecessary waiting time between teams. Despite all openness for new things, it is important to avoid changes within a sprint that endanger the agreed sprint goal. The agreed sprint goal is a premise that must be achieved together, so that a potentially shippable increment and thus a solution is created that works and could be made available to customers. If individual user stories are not implemented, the sprint is not extended, but the corresponding user stories are scheduled for one of the next sprints if necessary. The adjustment of quality targets and acceptance criteria is not planned, but if the sprint goal becomes obsolete, the product owner can cancel a sprint.
At the start of a sprint, a sprint planning takes place. It is a meeting to plan the requirements and work packages that are to be implemented in the current sprint. Participation is mandatory for the developers. The meeting is organised by the Product Owner, moderated by the Scrum Master. The Sprint Planning is divided into two phases: In Sprint Planning 1, the “what” is discussed, i.e. what is to be implemented in the next sprint. A sprint goal is agreed and the developers commit themselves to implement the agreed requirements in the next sprint. In Sprint Planning 2, the developers agree on the “how”, i.e. how the team will implement the requirements. For this purpose tasks are defined and visualised with a taskboard. At the end of Phase 2, the team should be able to explain to the Product Owner and the Scrum Master how they will work as a self-organising team to achieve the sprint goal and create the expected increment.
The Daily Scrum is a daily stand-up meeting where the development team meets to share progress, upcoming activities, and potential problems with each other. Participation in the meeting is mandatory for the development team, in addition the Scrum Master and the Product Owner should participate. At the Daily Scrum, each team member should answer three questions, always related to the sprint goal:
- What have I been doing since yesterday to help the development team achieve the sprint goal?
- What will I do until tomorrow to help the development team achieve the sprint goal?
- What is preventing me or the development team from reaching the sprint goal?
Through the exchange, the team synchronises with each other and redundancies are avoided.
The Sprint Review is a meeting at the end of a sprint to assess and approve the work done in relation to the set sprint goal. The Sprint Review is attended by the entire development team – the developers, the Scrum Master and the Product Owner. Also selected stakeholders – persons or groups with an interest in the sprint results – e.g. users, managers, representatives from areas such as marketing, sales or IT can participate.
The Sprint Review reveals what was created in the Sprint and which user stories were released. Since only completed user stories and their implementation may be presented live in the product, the progress of the development is directly visible for all participants. Through the participation of stakeholders, they can express direct feedback and thus criticism, praise and suggestions for improvement, which may be planned by the product owner for the next sprint.
A Retrospective is a regular meeting where the development team meets to review the recent past – the past sprint – and thereby improve future team collaboration. It is a meeting where processes, tools, skills, relationships, challenges and experiences are reflected. Feedback offers opportunities for the team as a whole as well as for each individual participant.
The goals are the improvement of teamwork and thus the improvement of processes and contents, as well as the definition of measures, dos and don’ts, based on the jointly gained insights. In addition, the retrospective offers space for open feedback in the team and for reviewing the agreed measures of the previous Retrospective. In practice, there are a large number of possibilities to hold the remaining Retrospectives and it is also advisable to adjust the procedure from time to time in order to keep the interest in the exchange among each other high.
The Product Owner is, along with the Scrum Master and the development team, one of the three central roles in Scrum. He represents the ideas of the stakeholders, creates and maintains the product backlog, and works closely with the development team. He defines the project goal and is responsible for the success of the development. He manages development through the formulation and prioritisation of epics, features, requirements and user stories (all of which can be captured by colleagues). He is responsible for releases and release plans, maintains a capacity plan and manages risk. He combines product and project management tasks.
Despite his responsibilities and numerous tasks, he is not the supervisor of the development team. He should not interfere in technical solution discussions or the estimation of efforts. For the product owner to perform his role well, he must be empowered by management to make decisions regarding requirements and functionality. In addition, it is important that he is qualified both technically and communicatively and that he is always available.
The Scrum Master is responsible for the adherence to the Scrum process and its implementation in the company. He moderates the Scrum meetings, ensures compliance with the agreed timebox, records and removes impediments, and protects the team from unauthorized interference during development. He promotes communication between the development team and the product owner, keeping an eye on various artefacts such as the product and sprint backlog, burndown charts, taskboards and user story mapping.
Within the scope of the retrospective he tries to improve the cooperation in and with the team as well as the lived processes. There he also has the opportunity to ask for feedback on his own work. In his role a Scrum Master is coach, moderator and mediator at the same time. His role should not be confused with that of a project manager, because the development team organises itself and communicates directly with the product owner. A double function as product owner or team member should be avoided in any case.
A Scrum development team consists of 3 to 9 people. Ideally, development teams should be cross-functional so they collectively possess all necessary skills to create an increment at the end of the sprint. Most importantly, the team must be able to design or optimise architectures and develop and test software.
Regardless of the skills of each member, Scrum does not define additional roles or titles for team members. Thus Scrum emphasises the joint responsibility of the team to deliver a potentially deliverable increment. Basically, Scrum development teams are self-organising. Neither the Product Owner nor the Scrum Master are in charge of the team. This makes communication during the various Scrum events all the more important.
The management of information in backlogs is very popular in Scrum. A backlog is a collection of things, especially incomplete work or things that need to be done. Or to put it simply, a backlog is a list of tasks or requirements that need to be completed.
Although Scrum defines the use of product backlog and sprint backlog (besides product increment) as artefacts, the handling of backlogs in companies is organised differently. Release backlogs and team backlogs are common. In Sprint Planning 1, the product owner defines his Selected Backlog as a wish list – the agreed user stories then move to the Sprint Backlog or are referenced accordingly. In an impediment backlog, the Scrum Master maintains the obstacles that were communicated in the course of the Daily Scrums. In addition, developers and employees can also maintain personal backlogs. In general, the maintenance and prioritisation of backlog items is an important and continuous task.
As described in the Scrum Guide, an increment is the sum of all backlog items completed during a sprint and the value of the increments of all previous sprints. At the end of a sprint, the new increment must be “Done”, i.e. it must be in a usable state and correspond to the Definition of Done of the development team. In addition, the increment must be “potentially shippable”, i.e. it must work, it must be tested, it must be operational, it should be documented and provide added value to the user.
In practice, not every completed increment is made available to customers, as this could overburden many customers and their organisations. With an app that automatically updates itself in the background on a mobile phone, one delivery per month is quite conceivable; with an application that is operated company-wide with several 100 users, this would possibly generate too much effort. Here marketing and sales are required to define a meaningful release strategy.
Mindset and Values
The number of oganisations using Scrum is growing continuously. Companies hope for more flexibility, faster development cycles or lower costs. Sprints, communication between product owners and stakeholders, and joint sprint planning often increase flexibility. But this flexibility is not free of charge. Scrum requires regular communication between the parties involved in the form of Daily Scrums, Sprint Plannings, Sprint Reviews, Retrospectives and, if necessary, Scrum of Scrums. In addition, there is the expense of maintaining backlogs, defining work packages, estimating efforts and documenting progress. In other words: Scrum is not an short cut to corporate success. Technical challenges remain, but they can probably be better assessed in the course of a development with new knowledge than at the beginning of a project. This reduces the risk of false project plans and promises.
In order for the procedure to work, organisations must not only learn to apply the rules of Scrum and to fill the Scrum roles with suitable employees. It is necessary to develop an agile mindset and fill the Scrum values with life. Management must move away from a command and control leadership style. The team must learn to deal with responsibility and make conscious use of it. The product owner must understand that he is not the superior of the development team. And the Scrum Master must not see himself as a project manager. So it’s about
- Focus and
Only with a mindset that lives these values does Scrum unfold its greatest advantages.
We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We provide you with an agile project team consisting of very good software architects and software developers who implement your requirements in short iterations in close coordination with you. Our approach is based on the agile methods Scrum and Kanban and combines them with the technical practices of Extreme Programming (XP).