What is Scrum, what events, accountabilities, artefacts exist, what values is it based on and what are the benefits?
Scrum is a framework for the development and maintenance of complex products and services. Originally designed for software development, the framework has been used for many years in different areas and industries for product development and project management.
Scrum is based on empiricism (knowledge comes from experience and decision-making is based on observation) and lean thinking (waste is avoided and the focus is on the essential). Scrum is defined in the so-called Scrum Guide.
The Scrum Guide, which contains the rules for applying Scrum, lists five events – which in some publications are also called meetings, rituals, activities or ceremonies:
- Sprint Planning,
- Daily Scrum,
- Sprint Review and
- Sprint Retrospective.
It contains three accountabilities:
- Product Owner,
- Scrum Master and
And it names three artefacts:
- Product Backlog,
- Sprint Backlog and
- Product Increment
These events, accountabilities and artefacts and the interaction of these elements together form the core of the framework. The procedure itself is incremental and iterative. It follows the consideration that development projects are often too complex for exact planning and description, because many requirements and solutions are unclear at the beginning of the project. These ambiguities are eliminated by a step-by-step iteration.
Scrum addresses the collaborative development of complex products and services. The team, equipped with the necessary skills, organises or manages itself within fixed time frames, with a commitment to deliver finished functionality on a regular basis and as early as possible.
The heart of the framework is the so-called Sprint. It includes all other events.
- The Sprint Planning is the first event within the Sprint. In planning it is defined “why” the current Sprint has a value, “what” is transferred from the Product Backlog to the Sprint Backlog and “how” it is realised. The aim is to generate an Increment on the way to the Product Goal that delivers a value, is functional and should potentially be deliverable.
- In the course of the implementation there is a daily stand-up meeting for collaborative synchronisation.
- In the Sprint Review, the completed work is presented at the end of the Sprint and the further procedure is discussed.
- And in the Retrospective, the cooperation in the past Sprint is discussed with the aim of improving future cooperation.
And the process starts all over again.
A guiding principle of the framework 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 development process. When working with parallel teams, organisations should make sure that sprints are synchronised so that there is no unnecessary waiting time between teams.
Despite being open to new ideas, it is important to avoid changes within a Sprint that jeopardise the agreed Sprint Goal. The agreed sprint goal is a premise that must be achieved together, so that a potentially deliverable Increment is created that works and could be made available to customers. If individual User Stories are not implemented, the Sprint will not be extended, but the corresponding User Stories may be scheduled for one of the next Sprints. The adjustment of quality targets and acceptance criteria is not planned, but if the Sprint Goal becomes obsolete, the Product Owner can also cancel a Sprint.
At the beginning of a Sprint, the Sprint Planning takes place. It is a meeting to plan the requirements and work packages 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 “Why” and “What” is discussed, i.e. why is Sprint valuable and what should be implemented in the current Sprint. A Sprint Goal is agreed upon 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. To do this, they define tasks and often visualise them with a taskboard. At the end of phase 2, the Developers should be able to explain to the Product Owner and the Scrum Master how they want to work as a self-managing team to achieve the Sprint goal and create the expected increment.
The Daily Scrum is a daily standup meeting where Developers meet to synchronise and exchange information about progress, upcoming activities and potential problems. Participation in the meeting is obligatory for the Developers, in addition the Scrum Master should and the Product Owner could participate. In practice it has proven to be a good idea that each team member answers three questions – always with reference to the Sprint Goal:
- What have I done since yesterday to help the team reach the Sprint Goal?
- What do I do until tomorrow to help the team reach the Sprint Goal?
- What is preventing me or the team from reaching the Sprint Goal?
Redundancies are avoided by the exchange.
The Sprint Review is a meeting at the end of a Sprint to inspect the work done in relation to the set Sprint Goal and to discuss future adjustments. The Sprint Review is attended by the Scrum team and all employees involved. Selected stakeholders – individuals or groups with an interest in the Sprint results – e.g. users, managers, representatives from areas such as marketing, sales or IT – can also participate.
During the Sprint Review it becomes visible what was worked out in the Sprint and which user stories were implemented. Since only realised user stories and their implementation are presented live in the product, the progress of the development is directly visible to all participants. The participation of stakeholders enables them to provide 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 Srcum team meets to review the recent past – the past sprint – and thereby improve future teamwork. It is a meeting where processes, tools, skills, relationships, challenges and experiences are reflected. The feedback offers opportunities for the team as a whole as well as for each individual participant.
The objectives are to improve teamwork and thus to improve processes and content, and to determine measures, dos and don’ts, based on the knowledge gained together. In addition, the Retrospective offers space for open feedback within the team and for reviewing the agreed measures of the previous Retrospective. In practice, there are a large number of possibilities for holding the Retrospectives and it is 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 one of the three accountabilities in Scrum. He represents the ideas of the stakeholders, creates and maintains the Product Backlog, and works closely with the Developers. He is responsible for defining the Product Goal and in many organisations also for the success of the development. He actively influences the development process by formulating and prioritising backlog items (all of which, however, can also be captured by colleagues). In practice, he is often responsible for releases and release plans, maintains a capacity plan and manages risk. He thus combines product and project management tasks.
Despite his responsibility and his numerous tasks, he is not the superior of the Developers or the Scrum team. He should not interfere in technical solution discussions or the estimation of effort. In order for the Product Owner to be able to carry out his work well, he must be authorised by the management to make decisions regarding requirements and functional scope, for example. Furthermore, it is important that he is qualified both technically and communicatively and is always available.
The Scrum Master is responsible for the implementation of Scrum – as defined in the Scrum Guide. As a member of the Scrum Team he acts as a moderator, mediator, process facilitator, supporter and coach. Put simply, he helps both Developers and the Product Owner to achieve goals together by facilitating the work of colleagues and encouraging collaboration.
The Scrum Master tries to create a trusting, open working atmosphere and to live the values of the framework. In doing so, he not only works in the direction of the Scrum Team, but also in the direction of the stakeholders and the organisation. And if necessary he addresses unproductive behaviour or offers appropriate feedback.
The activities of the Scrum Master should not be confused with those of a project manager. He has no authority to give instructions and therefore no power of decision. In Scrum the Developers organise or manage themselves. Within the Retrospective he gets the opportunity to ask for feedback on his own activities.
Besides the Product Owner and the Scrum Master, the Scrum Guide 2020 defines another accountability: the Developers. In the previous version of the guide there was still talk of a development team.
Developers are those in the Scrum Team who have committed themselves in a Sprint to create every aspect of an Increment. In practice, this means that from now on not only software developers, but all those involved – e.g. managers in the line, UX designers or marketing staff who are actively involved in a Sprint – may feel addressed.
Since the Scrum Team should consist of 10 or less people, a maximum of 8 developers should be involved in a Scrum Team. Ideally they should work across functions and together have all the skills needed to create an Increment at the end of the Sprint. Regardless of the skills of the individual members, the framework does not define additional accountabilities, roles or titles for the team. Emphasis is placed on the shared responsibility to create a potentially deliverable increment. Basically, the developers manage themselves and neither Product Owner nor Scrum Master is superior to them.
A Backlog is a collection of things, especially incomplete work or matters that need to be done. Or simply put: A Backlog is a list of tasks or requests that need to be completed or realised.
A Product Backlog contains elements with which a Product Goal defined by the Product Owner will be achieved. The Product Goal ensures that “only” items are defined that contribute to the development goal. The Product Owner is responsible for the Product Backlog and the Product Goal. In the course of the continuous refinement and prioritisation of items, he uses the opinions of stakeholders and the expertise of the Developers. He communicates the Product Backlog Items, ensures transparency and understanding and enters Sprint Planning with a pre-selection of Items – also known as Selected Backlog.
Interestingly, the Scrum Guide always talks only about Product Backlog Items without naming them more precisely. User Stories, Epics, Features, Requirements etc. are not explicitly mentioned.
The Sprint Backlog is the plan for the current Sprint. It is agreed in the Sprint Planning and contains all Product Backlog Items, which are selected by the Developers for the current Sprint and implemented in the Sprint. In addition, the Sprint Backlog contains the Sprint Goal, to which the Developers jointly commit, and the tasks that are necessary to realise the items and achieve the goal.
After the Product Owner has explained the “why” of the Sprint and the most important items from his point of view, the Developers decide “what” is included in the Sprint and “how” it will be implemented. They are thus responsible for the Sprint, the Sprint Goal and the Sprint Backlog. Ideally, they select the items with the highest priorities, which the Product Owner has defined together with them and on behalf of the most important stakeholders in the course of the Backlog Refinement. The tasks for realising the individual items should not take more than one day, so that tasks can be completed every day. The progress within the Sprint can be visualised with taskboards or burn-down charts, for example.
A Product Increment comprises all Backlog Items completed during a Sprint and contains 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 meet the Definition of Done. In addition, the Increment must be “potentially shippable”, i.e. it must work, it must be tested, it must be ready to be put into operation, it should be documented and it should offer added value to the users.
In practice, not every completed Increment is made available to customers, as this could overwhelm many client 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 thousand users, this might create too much work. Here, marketing and sales are called upon to define a meaningful release strategy together with the Product Owner.
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 in working, yet clear rules and principles.
- Concentrated communication between the accountabilities.
- Short feedback cycles.
- Integration of stakeholders easily possible, e.g. in the Sprint Review or in the run-up to Sprint Planning.
- 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 and Scrum
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 the following guidelines and principles:
- 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.
Mindset and Values of Scrum
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 stand-ups, Sprint Plannings, Sprint Reviews, Retrospectives and, if necessary, scaling. 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.
For the process to work, however, organisations must not only learn how to apply the rules of the framework and delegate accountability to appropriate staff. It is necessary to develop an agile mindset and an open attitude, and to fill the values with life. Management must move away from a command and control style of leadership. The team must learn to deal with responsibility and to consciously take it. The Product Owner must understand that he is not the superior of the developer. And the Scrum Master must not see himself as the project manager. So it’s about
- Focus and
The team’s commitment to achieve the agreed Sprint Goal, the commitment to quality, learning and doing the best together is essential for collaboration and building an agile culture.
Courage is important for the success of the team, because it is about trying new things, admitting mistakes, asking for help when necessary, saying “no” to some demands and, if necessary, questioning the status quo. Of course, the Scrum Master – e.g. in the removal of Impediments – and the Product Owner – e.g. in dialogue with stakeholders who permanently and at short notice demand new things – must also be courageous.
Openness is the basis for a learning culture, for feedback and new ideas. Openness as a value enables sound decisions, increases efficiency and creates trust.
Despite openness for new ideas, it is important for the work in the team to focus on the realisation of the agreed Backlog Items, for example in the Sprint. Timeboxing, a Definition of Ready and a Definition of Done are useful tools for focus. The focus is supported by the Scrum Master, who tries to keep disturbing influences away from the Developers, and the Product Owner, who focuses on the “what” and not on the “how” in Sprint Planning.
Respect as a value is essential for cooperation between those involved. It is important to respect the ideas, views and achievements of others. Respect is a central building block for successful and productive development.
Only with a mindset that lives commitment, courage, openness, focus and respect as values, Scrum unfolds its greatest advantages.
Impulse to discuss:
Do you think the Scrum Guide defines too many or too few rules? And what would be the advantage if it defined more or less?
 Do you miss the “usual” graphical representation of the framework? We have deliberately omitted it, because we feel that the proportions are not correct. The stand-up meeting, for example, lasts a maximum of 15 minutes, but graphically often takes up 1/4 of the sprint length, which varies between 1-4 weeks. The increment is usually smaller than the sprint backlog, but should be larger, as it also contains the increments of the previous sprints. We have therefore decided to publish an alternative presentation.
Are you interested in Scrum books? Then we can recommend the following books:
- Roman Pichler: Scrum: Agiles Projektmanagement erfolgreich einsetzen, 184 pages, published by dpunkt.verlag (German only)
- Kenneth S. Rubin: Essential Scrum: A Practical Guide to the Most Popular Agile Process, 500 pages, published by Addison-Wesley Professional
- Jeff Sutherland: A Scrum Book: The Spirit of the Game, 528 Seiten, published by O’Reilly UK Ltd.
Are you interested in German podcasts about Scrum? Please take a look at Scrum meistern.
In our blog you can also find additional information about Scrum: