What is Scrum?

Table of Contents: DefinitionRules of the GameAdvantagesQuestions from PracticeDownloadNotes

Smartpedia: Scrum is a framework with events, accountabilities and artefacts for the iterative development of complex products and services.

Scrum – a flexible framework for complex projects and developments

Scrum is a framework for the step-by-step planning and realisation of products and services. It helps companies when developments at the beginning of a project are too complex for exact planning, requirements or priorities change, customers need quick added value or risks have to be minimised.

Originally conceived for software development¹, Scrum has been used for many years in project management and product development in various fields and industries.

  • It defines an incremental, iterative procedure with events, accountabilities and artefacts, and
  • is based on empiricism (knowledge arises from experience and decisions are made on the basis of observation) and
  • Lean Thinking (waste is avoided and the focus is on the essential).


Scrum - a framework with events, accountabilites and artefacts

How does Scrum work?

The framework and its “rules of the game” are defined in the Scrum Guide. In its current version, published in November 2020, the guide lists

  • five events,
  • three accountabilities and
  • three artefacts.

The events include

The heart of the framework is the so-called Sprint. It includes all other events. It is an iteration of constant duration with similar actions.

Sprint Planning is the first event within the sprint. In Planning, it is determined “why” the current Sprint has a value, “what” is transferred from the Product Backlog to the Sprint Backlog and “how” it is realised. For each Sprint, the participants agree on a concrete Sprint Goal.

The Daily Scrum is a daily event for synchronisation, to check progress and, if necessary, to agree on adjustments. The Sprint Review is a meeting at the end of a sprint to present the development results and determine future adjustments. And the retrospective is a meeting to reflect on processes and procedures, tools, skills, relationships, teamwork, general and specific challenges and experiences.

Three accountabilities are defined:

In Scrum, the team – equipped with the required competences – organises itself within fixed periods of time – the timeboxes – committing to deliver finished functionality regularly and as early as possible.

Instead of roles, the guide speaks of so-called accountabilities.² 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 and 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.

In addition to the events and accountabilities, there are three artefacts:

The artefacts represent tasks or items and their realisation.

A Product Backlog contains elements with which a Product Goal defined by the Product Owner is achieved. The Sprint Backlog is the plan for the current Sprint and contains all Product Backlog items that are selected by the Developers for the current Sprint and implemented in the Sprint. The aim is to create an Increment on the way to the Product Goal that delivers a value, is functional and potentially deliverable, and thus corresponds to an agreed Definition of Done.

And so the sequence of events, the interaction of accountabilities and the work with the Artefacts starts all over again. The end of a Sprint marks the beginning of the next Sprint.

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.


Questions in the context of Scrum

Here you will find some questions and answers in the context of the framework:

Is Scrum an abbreviation or an acronym?

Scrum is not an abbreviation or an acronym. (The spelling SCRUM is therefore also incorrect.) The term originates from the sport of rugby, and refers to a “scrum”, also a game situation, in which a phase of the game is restarted on command. Hirotaka Takeuchi and Ikujirō Nonaka first used the term in 1986 in Product Development: The New New Product Development Game, writing:

“In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. Just as important, the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.”

What are the 5 Scrum values?

The following Scrum values exist:

  • Commitment
  • Courage
  • Openness
  • Focus
  • Respect

The commitment of the team to achieve the agreed sprint goal, the commitment to quality, learning and doing the best together is essential to working together 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 needed, saying “no” to some demands and challenging the status quo if necessary.

Openness is the basis for a learning culture, for feedback and new ideas. Openness as a value enables informed decisions, increases efficiency and builds trust.

Focus helps the team to concentrate on the important things – for example, with tools such as timeboxing, definition of ready or definition of done. In addition, the Scrum Mast tries to keep disruptive influences away from the developers and the product owner does not influence how developers realise user stories, for example.

Respect as a value is essential for the cooperation between the participants. The ideas, views and achievements of others must be respected. Respect is a central building block for successful and productive development.

Here you can find more information on how the values interact in concrete application.

How does Scrum change the speed of development?

The book Scrum – The Art of Doing Twice the Work in Half the Time is often cited when talking about speed. Twice the work in half the time? Sounds good, doesn’t it? Moreover, since terms like sprint are borrowed from athletics and velocity is another word for speed, it is little surprise that agile methods are often sold on a speed advantage. André Claaßen therefore speaks of an agile speed lie. And Stefan Wolpers calls for “The Art of Doing Twice the #Value in Half the Time“.

And is Scrum faster than alternative approaches? If it is possible to work calmly and continuously with each other at a constant speed, to integrate feedback at an early stage and thus consistently avoid undesirable developments, then rework, adjustments or time-consuming bug fixes are avoided, and this also increases the overall speed of development.

What are the challenges of introducing Scrum?

The Scrum Guide is short and clear, the framework easy to understand – are there any challenges at all with the introduction or application?

Yes, quite a few:

  • Does the new procedure fit the organisation and the projects at all?
  • How can the approach be established if it is imposed “from above”?
  • How do career paths change when there are only three responsibilities?
  • How does the individual visibility of individual employees change when the team becomes the focus?
  • How does individual goal setting change when teamwork becomes a central component?
  • How is customer feedback integrated into the approach?
  • How does the management of the organisation change with the help of key figures?
  • What happens if success is not achieved in the short term?
  • What role do tools actually play in the application?

This list can easily be extended. It’s a good thing that Heiko Bartlog has written a great series of articles on Agility? We tried it! Does not work! in which he takes up these and many other points and provides impulses on what organisations can do to get the best out of the framework.

How does team building succeed in Scrum?

equals and decide for themselves who is ideally entrusted with which task. Openness towards the competences of the other team members and open communication are writ large. The crux of the idea of self-organised teams, however, is the fact that processes that play a role in team formation are not considered or taken into account. If a team consists of hierarchically equal individuals who are supposed to develop their tasks themselves in interaction with the other members, the relevant team-building processes are particularly interesting.

Barbara Hilgert therefore recommends the five-phase model of the team-building process and Kai-Marian Pukall explains the need within teams to introduce roles and responsibilities.

Which role is most important in Scrum?

There is no hierarchy of roles; it is explicitly stated in the Scrum Guide:

“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required….

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint”.

Of course, individual tasks are assigned to the participants, but there is a joint responsibility for implementation and results. Ergo: No role is more important than another.

Which event is the most important?

Similar to the roles and accountabilities, there is no one event that is more important than the others. The sprint is considered the heart of Scrum, because all the others take place within this event:

  • Sprint Planning takes place at the beginning of the Sprint by discussing the why, the what and the how.
  • The Daily Scrum is the daily standup meeting where developers meet to synchronise and share progress, upcoming activities and potential problems.
  • The Sprint Review is an event at the end of a Sprint to inspect the completed work in relation to the set Sprint goal and to discuss future adjustments.
  • And the Retrospective takes place at the end of the Sprint to review the recent past – i.e. the past Sprint – and thereby improve future collaboration within the team.

All events have their meaning and purpose; each event would be missing if it did not take place. Ergo: There is no hierarchy of events.

Is a Scrumbut good or bad?

The abandonment of individual elements of the framework is called ScrumBut. The term goes back to “We use Scrum, but …”. There are Scrumbuts in roles, events and artefacts, they arise through ignorance or deliberate omission in the course of an adaptation.

When organisations start to adapt Scrum, they should have a deeper understanding of the framework. Such an understanding develops over time and through adherence to and application of the defined responsibilities, rules and rituals. Only then can an adaptation achieve its desired effect. An adaptation that merely disguises a problem and does not solve it does not make sense. If, for example, a product owner is not regularly available and therefore cannot participate in the necessary events, the focus should not be on improving the documentation of requirements, but on relieving the product owner. The lack of communication is the weak point, so a scrumbut probably won’t help much. It is therefore advisable to put adjustments to the test again and again in order to achieve the best possible effect in the long term.

In short, the question cannot be answered universally.

What is Ancient Scrum?

Ancient Scrum deals with the question of where the true origins of Scrum lie. According to this, Scrum was not invented by Jeff Sutherland and Ken Schwaber in 1995, nor were Hirotaka Takeuchi and Ikujiro Nonaka the inventors in 1986, although they were the first to use Scrum as a term for the development of new products.

According to Tobias Mayer, a British facilitator and author, Scrum was not invented, but rediscovered. In an article on the subject, he explains the beginnings of civilisation around eight thousand years ago and takes a look at the manufacture of tools and clothing as well as hunting and gathering. If we observe the processes of that time, we recognise Scrum:

  • Identifying a problem or demand,
  • creating a lightweight plan,
  • conducting experiments,
  • fail and iterate using feedback to improve,
  • finalising a usable result and finally
  • a reflection to consider what should be done differently next time.

This approach is Ancient Scrum and in many ways hardly differs from today’s approaches to developing software, systems, products or services.

Here you can find a text by Tobias Mayer on Ancient Scrum.

What is Zombie Scrum?

Zombie Scrum refers to a form of Scrum practice that looks like Scrum on the outside, but does not properly implement the actual spirit and principles of Scrum. It is often referred to as “zombie” because it looks like a lifeless, mechanical application of Scrum that does not deliver the desired result.

Zombie Scrum is characterised by the following features, among others:

  1. Zombie Scrum often only adopts the external structure of Scrum, without an understanding of the underlying values and principles.
  2. Self-organisation is a fundamental principle of Scrum. However, Zombie Scrum often lacks actual self-organisation and decisions are made externally or the team acts mechanically according to instructions instead of acting independently.
  3. Regular sprints and continuous improvement through retrospectives are important components of Scrum. In Zombie Scrum, these elements can be missing, resulting in the team not learning and not improving.
  4. Zombie Scrum teams can focus too much on rigid processes and rituals instead of focussing on the actual goal of value creation and customer satisfaction.
  5. Understanding and considering the needs of the customer are key aspects of Scrum. However, Zombie Scrum teams can focus too much on internal processes and lose sight of the customer.

The main problem with Zombie Scrum is that it does not fully realise the benefits of agility and Scrum. Instead of focusing on flexibility, adaptability and customer satisfaction, teams can become trapped in rigid processes that hinder innovation and continuous improvement. This can lead to inefficient ways of working, lower product quality and ultimately disappointed customers.

Here you can find more details about Zombie Scrum.

What is the significance of the Agile Manifesto for Scrum?

Agile software development with its prominent representatives such as Scrum or Extreme Programming is based on a foundation of values that were published in 2001 as the “Manifesto for Agile Software Development” – in short: Agile Manifesto.

It was written with the following claim: “We find better ways to develop software by doing it ourselves and helping others to do it. Through this activity we have come to appreciate these values:”

Apart from the fact that Scrum is nowadays basically used for the development of complex products or services (and thus not only for software development), the four values and 12 principles of the Agile Manifesto form the basis for the framework and therefore have great significance for its application in practice.

Kai-Marian Pukall has published an interesting article on Modern Agile Principles: Agile work made easy.

What Scrum (and agile) certifications exist?

There are many organisations that offer different certifications for Scrum and/or agile. The two best-known organisations are likely to be the Scrum Alliance and Scrum.org. Felix Stein has already compiled a whopping 240 agile certifications from 39 different organisations at the end of 2020. It is very likely that there are considerably more nowadays, as many organisations have realised that there is good money to be made from certifications.

However, it would be a mistake to assume that just having a certificate is enough to have a good command of the framework or the tasks and activities of the various responsibilities. In reality, it is similar to a driving licence: it entitles the holder to drive a vehicle, but he or she can only really drive a car well many years later and only if he or she drives, drives and drives very regularly.

Scrum Whitepaper as Download

Download the Scrum Whitepaper for free now.

Everything important about the framework at a glance.

  • Events
  • Accountabilities und Artefacts
  • Benefits
  • Values and Tips

Knowledge on 13 pages to take away.

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?


[1] the 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.

[2] 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 it is neither an acronym nor a method. It is a framework that names events, responsibilities and artefacts, but does not describe, for example, how a product, software or service is to be developed.

Are you interested in German podcasts about the framework? Please check out Scrum meistern.

And here you will find additional information from our Smartpedia section:

Smartpedia: What is LeSS - Large-Scale Scrum?

What is LeSS – Large-Scale Scrum?

Smartpedia: What is a Definition of Ready?

What is a Definition of Ready?

Smartpedia: What is a Project Organisation?

What is a Project Organisation?