What is Scrum?
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. The framework is defined in the so-called Scrum Guide. In its current version, published in November 2020, it names
- five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective),
- three accountabilities (Product Owner, Scrum Master and Developer) as well as
- three artefacts (Product Backlog, Sprint Backlog and Product Increment)
as central elements.
How does Scrum work?
Scrum addresses the collaborative development of complex products and services. It is based on empiricism (knowledge arises from experience and decisions are made on the basis of observations) and lean thinking (waste is avoided and the focus is on the essential). The approach is incremental and iterative. It follows the consideration that development projects are often too complex for exact planning and description, as many requirements and solutions are unclear at the beginning of the project. These ambiguities are eliminated by iterating step by step.
In Scum, the team – equipped with required competencies – organises itself within fixed time spans, committing to deliver finished functionality regularly 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.
The Scrum Guide defines five events, which in some publications are also called meetings, rituals, activities or ceremonies:
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 current Scrum Guide defines so-called accountabilities instead of roles. The idea behind this is that every person who actively participates in a development or a project takes responsibility for specific areas, the implementation of tasks, the adherence to commitments, the culture of cooperation or
the results! And since this takes place in close cooperation, Scrum as a name also makes sense; the term comes from the sport of rugby and describes a situation in which a phase of the game is restarted on command.
Three accountabilities are defined:²
The Product Owner
- 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 a member of the 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 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.
The Scrum Guide defines three artefacts:
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.
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:
- Commitment 100% 100%
- Courage 100% 100%
- Openness 100% 100%
- Focus 100% 100%
- Respect 100% 100%
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.
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.
Scrum in practice
How does Scrum work in practice? You can find some answers and perspectives in our blog:
- What should be considered when introducing and using Scrum?
- What happens when organisations use Scrum but not as described in the Guide?
- Why does Scrum fail in organisations?
- How does Scrum change the pace in organisations?
- What influence do principles have on agile working?
- How does team building work in Scrum?
- Is Scrum also suitable as a learning framework?
We are sure you can think of more questions. Please contact us and we will try to answer your questions or publish corresponding articles.
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?
 Scrum as a framework was first introduced in 1995 at the OOPSLA conference in Austin, Texas by Jeffrey Victor “Jeff” Sutherland and Ken Schwaber. However, Scrum as a term was mentioned as early as 1986 in a paper by Ikujirō Nonaka and Hirotaka Takeuchi; the two recognised that in the development of complex products, the best results are achieved when small, self-organised teams set themselves goals.
 Here you can find more information on the topic of accountability versus role. If you read the term Scrum role in publications, then you know that it must be a somewhat older text, because since November 2020 it is no longer used in the description of the framework.
Here you will find information on the agile manifesto. It describes a code of conduct to reflect the actions of a development and align them with defined principles. Based on this, Scrum provides a framework for organising and completing work collaboratively.
The SCRUM method is written about in numerous publications. But Scrum is NOT an acronym and also NOT a method. It is a framework that names events, accountabilities and artefacts, but does not describe, for example, how a product, software or service should be developed.
Many organisations use the framework in project management. However, it is not enough to rename iterations into sprints and individual roles, because that is tantamount to label fraud.
Are you interested in German podcasts about the framework? Please check out Scrum meistern.
Here you find a German Video about agile project management with Scrum.
And here you will find additional information from our Smartpedia section: