Introduction to Scrum

The Scrum method is a framework for agile project management. Even if Scrum has its origins in software development, the method is increasingly enjoying great popularity in non-software projects.

This article offers a compact introduction to the Scrum method. In doing so, we concentrate primarily on the aspects of the Scrum model that are important for project management in the context of non-software projects in traditional project and organizational structures.

Scrum definition, history and principles

Scrum is a term from rugby and means "scrummage". Jeff Sutherland and Ken Schwaber developed the Scrum method and presented it to the public for the first time at a conference in 1995. The two Scrum fathers were also significantly involved in the formulation of the [agile manifest] (/en/agiles-manifest/) in 2001. Since then, the Scrum method has been continuously developed and has contributed significantly to today's understanding of [agile working methods] (/en/agile-working-methods/).

Scrum definition

If you want to answer the question "What is Scrum" in a nutshell, then I offer you the following definition:

Scrum is a formal set of rules for teamwork. The Scrum model defines roles, meetings and various artifacts that support teams to work according to agile principles.

The Scrum method is not a dogmatic project management method, but a framework that offers a team and stakeholders involved guard rails and points of orientation. The Scrum Framework is constantly being further developed by [www.scrum.org] (https://www.scrum.org/) and is documented in the current Scrum Guide.

The Scrum model focuses on the definition of roles, meetings and artifacts, which you can find in the following overview.

The main principles of the Scrum method

For the Scrum model to be effective, it needs a certain context. Without an understanding of these essential principles, the risk is too great that employees will behave like in a Scrum team, but the Scrum method will not have any effect. The principles are values and norms of behavior, which make it possible for the Scrum model to be effective at all.

Vision: This means that every Scrum Team follows a long-term goal that serves as an overarching point of reference.
Value orientation: Scrum teams measure their results on the value achieved for customers and companies.
Transparency: This means that goals, decisions and upcoming tasks are freely accessible and known to all those involved and stakeholders.
Focus: A consistent prioritization of the tasks to be done ensures a high focus.
Role clarity: All people involved in the project have a clear role.
Autonomy: This means that the implementing team is independently and autonomously committed to the tasks to be completed without being assigned work packages and orders
Process compliance: The Scrum process is non-negotiable. Because the process gives a team security, reduces overhead costs through a high level of standardization and at the same time contributes to a high level of transparency.
Feedback: The Scrum process is non-negotiable. Because the process gives a team security, reduces overhead costs through a high level of standardization and at the same time contributes to a high level of transparency.

Scrum Team

Product Owner (PO) - 1 person

The product owner (PO) has the important task of harmonizing the interests of the company (business value) and the users/customers value and maximizing the value of the product or project. The PO also formulates and communicates a long-term vision for the project. In order for this to succeed, the PO needs a thorough understanding of customer needs and the strategic framework from the company's point of view.

The most important tool of the product owner is the backlog and the prioritization of the topics it contains. In this way, the PO ensures that the team is working on the right tasks and that everyone in the team uses their time profitably in the interests of the company. In addition, the product owner formulates a sprint goal for each sprint.

Development Team - 3 to 8 people

The development or project team works autonomously and self-organized on the implementation of the agreed tasks. To do this, the team commits itself to the tasks to be completed in a sprint. This means that no work packages are assigned. Instead, the team decides during the planning which of the prioritized tasks can be completed as part of the sprint. An important prerequisite for teams to be self-effective and able to commit is that development or project teams are interdisciplinary. This means that all the necessary skills and abilities are available in the team to solve the agreed tasks and achieve the goals of the sprint.

Scrum Master - 1 person

The Scrum Master is the coach of the team and the product owner. Its most important task is to enable the team and the product owner to do their job in the best possible way. He removes obstacles, contributes to efficient implementation and supports the team in adhering to the Scrum process. In addition, the Scrum Master protects the team from unwanted influence. He also coaches the stakeholders involved and ensures that agile principles are lived by everyone involved.

Scrum process - sprints and scrum meetings

The Scrum process consists of a recurring series of sprints. Each sprint is characterized by clearly defined meetings, the intention, duration and goals of which are clearly defined.

Sprint
Planning
Daily
Review
Retrospective

In the following we will go into more detail about the respective activities and meetings of the Scrum process. You should take into account that the Scrum Framework is based on the ideal condition that teams work full-time on the implementation of a project.

The sprint - the heart of the Scrum process

The sprint is the highest central ordering principle in the Scrum Framework. A sprint is a fixed time interval in which the team works on completing the agreed tasks and achieving the sprint goal. Sprints give each other a hand. That is, the end of one sprint is the beginning of the next sprint. The duration of a sprint is typically 1-4 weeks and is determined depending on the product / project. When determining the sprint duration at the beginning of a project, you should consider the following framework conditions:

The sprint duration is fixed, i.e. all sprints have the same duration. This applies until you find out that a different sprint duration would be more appropriate for your project. Then you change the sprint duration and stick with it. Sprints last max. four weeks . The relatively short cycle of four weeks is due to the insight that the longer a cycle is, the lower the quality of the planning. This knowledge is also known as Cone of uncertainty.

What does the PO does during the sprint?

Since the product owner does not work directly on the implementation of the project or product, the question arises what the PO actually does during the sprint. The PO has the important task of maintaining and prioritizing the backlog and thus preparing the next sprint. To this end, he also coordinates with the team in refinement meetings so that tasks in the next planning are already thought through and not completely new. In addition, he is available to the team during the implementation for queries or re-prioritizes tasks if new findings arise in the course of implementation that disrupt the original planning.

Cancellation of a sprint

If the originally formulated sprint goal is no longer relevant or no longer promises any value, the team can decide to cancel the sprint. Alternatively, the team uses the prioritized backlog in consultation with the PO.

Scrum Meetings

The Scrum Framework has defined fixed meetings so that working in sprints does not become a senseless sequence of time intervals. This means that the Scrum Meetings are the second important principle of order and give the sprint a structure.

Each sprint starts with Planning, ends with a presentation of the work results achieved ([Review] (#Review)) and the question of how the cooperation continues can be improved (Retrospective). To prepare for planning, so-called Refinements take place and during the sprint team members synchronize daily (Dailys). The duration of the individual meetings is relative to the length of the sprint.

In the following I will outline the Scrum Meetings, their intention and the ideal typical duration based on a team that works full-time in a 4-week sprint on the implementation of the project. These recommendations are based on the official Scrum Guide.

Sprint Planning - Start of the sprint, 8 hours

Every sprint starts with a joint planning in which the entire Scrum Team (PO, project team, Scrum Master) takes part. During the planning, upcoming tasks are discussed and the expected effort is estimated. With the estimate of the expected effort, the PO is enabled to make a decision on the prioritization on the basis of the expected benefits and costs. The implementing team commits itself to the tasks, takes over the prioritized tasks in its sprint backlog and the PO finally formulates a sprint goal. In a four-week sprint, 8 hours are set for planning.

Daily - daily, 15 minutes

The daily is a daily synchronization of the implementing team. Since the duration is limited to 15 minutes, it often takes place standing. That is why it is sometimes also called "Stand Up". Standing and the tight timebox have a very simple background. Because instead of being epic, every team member is invited to give a short update in order to synchronize with their colleagues. Where am I now, do I need help, do I have any other questions? Should there be a need for further discussion, further discussions will take place after the daily instead of bothering the entire team with it during the day. The daily is a meeting of the project team that takes place every day at the same time in the same place. This means that the Scrum Master and the Product Owner only take part optionally.

Review or demos - end of the sprint, 4 hours

At the end of the sprint, the project or product team presents the work results of the sprint. In addition to the product owner, interested stakeholders and possibly also selected customers are invited to the review. On the one hand, the review offers the project or product team a stage for what it has achieved in the previous sprint. On the other hand, stakeholders and invited persons are given the opportunity to give feedback and ask questions in order to influence future planning. However, the decision as to which of these is prioritized and how is the sole responsibility of the Product Owner. This means that the review is not an acceptance and also expressly cannot be compared with a steering committee. Because here is an autonomous team that has done its best on the basis of joint planning with the product owner. Unfinished work packages and tasks go straight to the next planning.

Retrospective - end of the sprint, 3 hours

Finally, the sprint ends with a retrospective of the Scrum Team. For this purpose, the project team, the product owner and the scrum master meet to reflect on the cooperation and to make agreements for future sprints based on these insights. This means that the retrospective is exclusively about the work process, not about content or work results. The Scrum Master moderates the retro e.g. according to the following example.

Welcome ("Set the stage")
Gather information and impressions ("Gather data")
What went well? (Keep)
What should we hire? (Drop)
What could we try? (Try)
Condense insights ("Generate insights")
Formulate ToDos for the following sprint ("Decide what to do")
Closing - Who do I want to say thank you to?

Retrospectives are particularly effective when participants bring with them the desire for constant improvement and a healthy dose of self-reflection. In the Japanese Lean philosophy, this attitude is based on the principles Kaizen and Hansei very well described. The retrospective closes with specific agreements that will be implemented in the next sprint and may also have their own entry in the sprint backlog.

The only meeting that does not follow a defined structure are refinement meetings. The goal of refinements is that the product owner and the implementing team talk in advance about the scope and outcome of upcoming tasks to plan. This gives the PO the opportunity to sharpen his requirements and the team members involved the chance to think about requirements. The basic idea is that the implementing team does not find out about a requirement for the first time during planning. This prior synchronization and a common refinement of the tasks are especially important for very complex and extensive tasks in order to ensure the efficient implementation of the planning. So if you find that you are not getting to the point or coming to a good conclusion during planning, then insufficient refinement could be a possible cause.

Summary of the Scrum Meetings

This high standardization of the Scrum meetings contributes to a high efficiency and very good meeting culture. Every meeting has a defined goal, a clear place in the sprint and a fixed timebox. This will reduce the organizational overhead to an absolute minimum.

The following overview gives you a summary of the Scrum Meetings for a Sprint of 4 weeks.

Event	target	Duration	Participants
Sprint Planning	Discussion of the upcoming tasks, preparation of the sprint backlog, definition of the sprint goal	1 time at the start of the sprint, max. 8 hours (with a 4 week sprint)	All product owners, product or project teams, Scrum Masters
Daily	Synchronization of the team members, what am I planning today, where do I need help, etc.	Daily, max 15 minutes	Product or project team Optional: PO, Scrum Master
Sprint Review	The project team presents work results, PO and stakeholders give feedback.	4h	All In addition: Stakeholders, if applicable customers
Sprint retrospective	Optimization of cooperation, adaptation of the definition of done	3h	All optional: Stakeholders to provide impetus
Product Backlog Refinement	Clarification and estimation of the backlog items	2-4 hours per week	Product owner, product or project team, optional: Scrum Master

Scrum artifacts and tools

In addition to roles and activities, the Scrum artifacts and tools are the third central component of the Scrum framework. In the following I will briefly explain the following Scrum artifacts.

Product Backlog
Product Backlog Items (User Stories)
Sprint Backlog
Definition of Ready
Definition of Done
Product Increment
Planning Poker and Estimates

Product Backlog

The backlog is the sum of all pending tasks; an appropriate German translation would be e.g. "Topic memory". In other words, in the backlog you will find all the tasks and ideas that you as the PO believe will create value for the project or product. These can also be tasks that may only have to be done for formal requirements. The Product Backlog is e.g. maintained and prioritized in a Kanban Board. The product owner works with a backlog that is prioritized at all times. In other words, if the team has planned conservatively and is finished significantly earlier with the tasks agreed for the sprint, the team can refer to the prioritized backlog at any time. Ideally, the product backlog can also be viewed online for the team and the stakeholders involved.

Product Backlog Items (User Stories)

Individual entries and tasks within the backlog are "Product Backlog Items". These can be small, very specific ToDos, extensions of existing performance features, new features or even new epics. You always speak of an epic when new performance features have an "epic" breadth or depth and can no longer be implemented within a single sprint. These epics are then broken down into editable Product Backlogs Items.

Each product backlog item contains the expected customer benefit, possibly the added value for the company and measurement parameters for assessing the effectiveness of the measures or features. In addition, the backlog contains an entry or acceptance criteria that are necessary for the fulfillment of the task. Even if there is no official format for product backlog items, User Stories have established themselves as the de facto standard.

Sprint Backlog

The sprint backlog contains all tasks that are being processed by the team in the current sprint. While the backlog is under the authority of the PO, the sprint backlog belongs solely to the implementing team. The sprint backlog is a result of the sprint planning. Because here the PO and the project team decide together which backlog items will be processed in the coming sprint.

Backlog, Sprint Backlog and Sprint Planning in one Kanban Board

Definition of Ready

The Definition of Ready (DoR) reflects the team's understanding of the degree of maturity a task in the backlog is allowed to fulfill in order to be processed at all. For example, the expected benefit or measured variables for assessing effectiveness can be part of the definition of ready. If a task does not meet the definition of ready, the PO is required to further develop the product backlog item. Like the Definition of Ready (DoR), the Definition of Done (DoD) is subject to constant adaptation and critical review. The team can e.g. As part of the retrospective, decide to adapt the Definition of Done (DoD) or the Definition of Ready (DoR).

Definition of Ready (DoR) and Definition of Done (DoD) are important artifacts of the Scrum method

Definition of Done

The Definition of Done (DoD) is an agreement and the team's shared understanding of when work is done. That means, general acceptance criteria for the successful completion of a task in the form of general requirements and quality criteria. For example, a team could agree that work results must be accessible and discussed for everyone so that a task is really "done". Accordingly, a task in your Kanban board can only be moved to "Done" if it meets the conditions of the "Definition of Done".

Product Increment

If you read or listen to the Scrum Guide, the term "Product Increment" is sure to catch your eye. The product increment describes the work results achieved during a sprint. So the "delta" to the work status before the last sprint or the new performance aspects that the team completed in this sprint.

Story Points Estimation

During the sprint planning, the implementing team estimates the effort of individual tasks. In this way, the team gives the PO important feedback about the expected effort of the implementation. The PO can therefore directly compare its expected benefit and effort, better prioritize its backlog and the tasks that are important for the sprint. The value that a task receives is also called "story points" based on user stories. If you add up the story points of all tasks in the sprint, you get a measure of the team's performance. This gives you an orientation that will help you plan better in the long term.

Planning Poker

"Planning Poker" has established itself as a method for estimating. Each team member receives a set of cards that each contain a value from the Fibonacci series (1, 2, 3, 5, 8, 13, 21 ...). After presenting a task, all team members play their card at the same time. This is to prevent team members from influencing each other too much. With the card played, each team member estimates the expected relative effort. This is not an absolute estimate of the effort, but the expected effort in relation to a reference task. Because the information associated with the estimate is more important than the absolute effort. If the estimates differ too widely, the team seems to have a different understanding of the scope of a task. That is, planning poker and guessing encourage constructive discussion, raise important questions, and help the team gain a better understanding of the task at hand.

Conclusion

The Scrum method as the father of agile project management

Meanwhile, the Scrum model has over 25 years of maturity and constant adaptation behind it. This makes Scrum a de facto standard for the agile implementation of non-software projects, especially in connection with Kanban. As I understand it, the essential principles and ideas of the Scrum method are much more important than a Scrum Guide-compliant implementation of the Scrum framework. Because even a self-confident and autonomous PO, a self-organized team, clear rules of the game and meeting structures will quickly lead most project organizations in rather hierarchical companies to the limits of their current culture.