Scrum: How does it work and what can it do?

Scrum is the most popular and well-known agile method. The lion’s share of all agile-managed projects is managed according to Scrum. The rest mostly uses at least aspects of the framework.

Scrum reduces complexity and helps teams work more efficiently and achieve better results. By working iteratively, the team revises and omptimizes the product sprint by sprint. As a certified Scrum master or product owner, you have the opportunity to successfully manage exciting projects and help your team deliver great results.

 

But what actually is Scrum?

 

Scrum is simple…

Scrum consists of very few rules and therefore is very simple. Specifically, it consists of only three roles, five events and three artifacts. This simplicity is one of the main reasons for the major success of Scrum. After all, people often try to manage the complexity of recent time and the current environment by using correspondingly complex approaches and methods. The recent Scrum Guide published by Jeff Sutherland and Ken Schwaber (and updated in 2020) describes the framework in just 14 pages.

Scrum is agile…

No other methodology, no other approach, no other technique has been as successful in Agile projects as Scrum. Almost 90 percent of all agile projects teams manage using Scrum. To speak of market leadership would be an understatement. Especially since one can assume that the few percent who claim that they do not use Scrum use Scrum at least in part. For example, a daily stand up has become the standard in virtually all agile projects.

Scrum is hierarchy-less…

Scrum returns a large part of the “power” to the team. There is no longer a project manager as we know it. The assumption underlying this is that the teams themselves have sufficient motivation and enough knowledge to organize themselves. They know best how to achieve a goal. And they do so without a detailed project plan and without anyone telling them exactly what to do and when. There is no hierarchy gap in a SCRUM project team, just clearly defined roles. Everyone respects each other as equals and knows exactly what the others roles are.

Scrum is efficient…

Scrum gets by with as little administration as possible. Usually there is so much energy going into project planning, budget management and status reports instead of the actual management of the project. All of this effort is almost completely eliminated with Scrum. Scrum is more pragmatic and efficient than other methods. Communication no longer takes place in the form of long e-mails, mail chains and PowerPoint presentations, but directly face to face. No media breaks, from person to person. People discuss potential issues directly with the person concerned.

Scrum works…

Often the scrum founders, Jeff Sutherland and Ken Schwaber, describe Scrum with very striking statements such as “How you can achieve twice as much in half the time with Scrum”. These statements are certainly somewhat exaggerated. Nevertheless, one can admit without envy that the methodology of Scrum is very effective and efficient due to its characteristics and therefore simply works. Otherwise, it would not be possible for Scrum to be so successful and to have become more and more widespread worldwide over the past 20 years.

 

Scrum: The Basics

Scrum: The term

The term Scrum comes from two Japanese economists Nonaka and Takeuchi. In their article “The New Product Development Game”, published in 1986, they write about what they call the “Rugby Approach”. This makes use of an analogy from rugby. They assume that one of the most extraordinary success factors of very successful product development teams is the spatial proximity of the team during the development work. Just as in the scrum originating from rugby, which is called Scrum and in which many players stand close together. Because these teams also work as small and self-organized units. They only get a rough direction from the outside. In the implementation, however, it is up to them how they achieve their common goal.

More than ten years later the founders of Scrum, Jeff Sutherland and Ken Schwaber then developed the rugby approach to a framework for software development projects. They named this framework with an appropriate reference to the article by Nonaka and Takeuchi: Scrum. Since the beginnings of Scrum go back more than 20 years and Scrum has become more and more successful. Also more and more Scrum variants have developed.

Scrum: Empirical Process Control

The scientific basis of Scrum is the theory of empirical “process control”. The Empirical theory states that knowledge is based on experience. And that people make decisions based on the basis of this existing knowledge. Scrum ensures through its iterative and incremental approach that there is the possibility for review and adjustment at regular and short intervals.

In this way, experience is regularly transferred into knowledge. You can then use this knowledge to make decisions again and again. The more experience, the more knowledge, and the better decisions can be made. This approach allows risks to be minimized, identified at an early stage and also counteracted.

 

The 3 pillars of Scrum

Transparency

Open communication and knowledge sharing knowledge is the basis for transparency. In addition, the entire procedure or process in an agile project should be transparent for all participants. This includes in particular the terms used in a project. Everyone should understand the same thing by the terms used. A typical example in a project is that there is a uniform understanding of “done” – that is, when something is completed. What exact criteria are used to determine that something is done.

Inspection

Inspection means that teams regularly check all procedures and work results.. In a scrum-project this means that the team checks the artifacts at regular intervals to see whether they and their design are suitable for achieving the respective sprint goal. However, this event called review must not take place so often that it hinders the actual project work. It must always remain efficient. The reviews must take place in such a way that they also add value to the project work.

Adaptation

Adaptation means adapting to the framework conditions in order to become faster and better and to achieve the goal efficiently. If it is determined during a review that the procedure or the work results exceed an unacceptable limit, adjustments must be made. These adjustments must be decided as quickly as possible, without unnecessary delay, in order to prevent unnecessary further deviations.

 

“Agile means getting information at the source” – Arie van Bennekum

The five values of Scrum

The five values of Scrum ensure that teams live the three pillars of Scrum.

Courage

Scrum team members have the courage to do the right things and work on the challenges and problems in the project.

Focus

Everyone focuses on the work of the current sprint and on the goals of the SCRUM team.

Commitment

Everyone commits to personally support and achieve the goals of the Scrum team.

Respect

Scrum team members respect and empower each other to be competent and independent individuals.

Openness

The Scrum team and its stakeholders agree to be open about the work and the challenges that come with it.

Scrum’s “rules”

Roles

Roles regulate the tasks of each team member, depending on which role they belong to according to the roles defined by Scrum. Each role has specific tasks, rights and duties.

Artifacts

These are certain tools and techniques that make the application of Scrum successful and are necessary to make the project flow efficiently.

Events

Events in Scrum regulate the form, frequency and content of communication between the roles and members in the project.

The Scrum Process

The Scrum process starts when people need a certain product or service. The team collects the requirements for the product in a so-called Product Backlog. The Product Backlog is thus the summary of all product features that the final product should include. After the product backlog is complete, sprint planning begins. Here, we plan which product features should be implemented in the upcoming sprint. This subset of product features is then transferred into a Sprint Backlog. The Sprint Backlog thus includes all product features that are to be implemented in the coming Sprint. These are the sprint goals, so to speak.

Then the Sprint begins. The Sprint is the actual phase of product development. During product development, the Scrum team then exchanges ideas on a daily basis as part of the Daily. At the end of the sprint, the result should be new product features for the product increment. A product increment is a finished part of the overall product. After the Sprint there is the possibility of checking and adjusting in the form of a Sprint Review. Here, the product that is being developed is reviewed and adjusted if necessary. On the one hand, this gives all those who were not themselves involved in the development process the opportunity to obtain information about the current development status, such as the stakeholders. All those who were directly involved in the development thus receive feedback on the extent to which their work in the last sprint has brought them closer to the product characteristics of the overall product.

The Scrum Events

Events according to Scrum always take place in person. They take place on a regular basis in order to be able to continuously review and adjust. All events have a fixed timebox.

Characteristics of Events

Events according to Scrum have very special characteristics that make events according to Scrum “typical” Scrum. These can be described as follows.

Regularity

To ensure the iterative character of Scrum, the events take place regularly. There is a fixed frequency in which the events take place. This frequency is not changed or adjusted. It is consistently followed throughout the entire project. The location of each event should also always be the same. This regularity and the clear definition of frequency and location ensure the flow and efficiency of the Scrum process.

Timebox

A fixed time frame is specified for each event. This means that a timebox is defined in advance for each event. This is adhered to in any case. When the time window has expired, the event is finished. There is no extension of the event. Topics that are still open are then discussed in the next event or postponed to the next event. In addition, according to SCRUM, the events always take place at the same time, i.e. in relation to the time and day of the week. This reduces the coordination effort required for event organization. Postponement of events or repeated redefinition of the time of events is deliberately not provided for.

The five events of SCRUM

According to Scrum, there are exactly five events that take place (regularly) within the scope of a project. No other events are allowed. It is important to note, however, that this does not mean that there can be no communication outside of the Scrum events. Only the type and number of events themselves is clearly specified. The two founders of SCRUM Ken Schwaber and Jeff Sutherland emphasize that every variation and addition to the “core” of Scrum defined by them reduces the success and efficiency of the method.

The Sprint

The goal of the sprint is to achieve the respective objectives or the respective goal that the developers has set for the respective sprint. Specifically, the product features to be implemented during the Sprint are recorded in the Sprint Backlog. The Sprint itself is not an independent event, but rather the bracket around several events that take place within the Sprint. In this respect, there is no concrete form of how the Sprint itself takes place. The events that take place within the Sprint are: Sprint Planning, Daily Scrum, the Development Work, the Sprint Review and the Retrospective. Participants within the Sprint are the Product Owner, the Scrum Master, the Developers and the Stakeholders.

The Sprint itself is not moderated, since it represents a bracket or container around several events, as already mentioned. In this respect, there is also no agenda of the event itself. No changes are made during the sprint that jeopardize the sprint goal. The requirement for the quality of the work may not be changed. The scope of the sprint may be negotiated between the product owner and the developers if it serves learning. The agenda of the sprint is more or less the processing of the sprint backlog. Within the sprint, the roles involved have the tasks, competencies and responsibilities that they are also basically assigned according to their role definition. The result of the sprint is the processing of the product features planned for the sprint according to the product backlog.

How long does a Sprint last?

The duration of a Sprint varies. A sprint can go from a few days to a month. The maximum duration of a Sprint is four weeks or one month. It is important that the sprints always have the same duration. The background to this is that it has been proven that the performance of sprint teams is highest when the duration is the same in each case. Basically, it can be said that sprints should always be as short as possible. When a sprint is over, the next sprint already begins. There is therefore virtually no break between the individual sprints. Each sprint is immediately followed by the next sprint.

How many sprints take place within a Scrum project can vary. Ultimately, sprints take place as long as the product or service being developed exists. The structure within a sprint is also always the same. A Sprint always starts with Sprint Planning as the first event.

Sprint Planning

The goal of Sprint Planning is to plan the upcoming Sprint. The Sprint Planning takes place in the form of a presence event, which is always the very first event of a Sprint. Sprint Planning takes place once per Sprint. Every Sprint begins with it.

The entire Scrum team takes part in Sprint Planning, i.e. the Product Owner, the Scrum Master and the developers. Sprint Planning lasts a maximum of eight hours for a sprint of four weeks. If the sprint lasts less than four weeks, the duration of the sprint planning also adjusts proportionally and is shorter.

The Scrum Master is responsible for ensuring that Sprint Planning takes place and that all members of the Scrum team understand what the goal of the event is. He is also responsible for ensuring that the Sprint Planning stays within the agreed time window in terms of duration. Sprint Planning is divided into two parts.

The Daily SCRUM

After the Spring Planning has been completed, the developers start its work. In concrete terms, this means that they work on the tasks defined in Sprint Planning in a self-organized manner. It is important here that the developers work through the tasks one after the other and ideally works together and simultaneously on the same backlog item. During this development work, the Scrum team physically meets once every day on which work is being done for the Daily Scrum.

This always takes place at the same time in the same place. The reason for this is to reduce the organizational work of event planning and complexity. The duration of the Daily Scrum is limited to a maximum of 15 minutes. The goal of the Daily Scrum is that the developers coordinate and synchronize.

How does the Daily Scrum work?

In each Daily Scrum, the development work for the next 24 hours is planned. The work of the last 24 hours is always made transparent first and an outlook on the tasks of the next 24 hours is given. The developers check the progress of the last 24 hours with regard to the sprint goal. In addition, they analyze how the progress is related to the backlog items that are in the sprint backlog. The main goal of the Daily Scrum is to maximize the probability that the developers will achieve the Sprint goal.

The agenda of the event is set by the developers. There are no specific guidelines according to Scrum on how the Daily Scrum should be structured, as long as everything is aimed at ensuring that the sprint goal is achieved.

The Sprint Review

The Sprint Review always takes place at the end of the development work. It is used to present the most important results from the Sprint and to review and, if necessary, adjust them. In this way, the latest status of the product increment can be made transparent and the Product Backlog can be updated accordingly. The Sprint Review takes place in the form of a physical event. The product owner invites people to the event. The entire team is present at the Sprint Review. In addition, the stakeholders are also invited. This gives them an overview of the latest status of the development work and at the same time allows them to provide feedback to the developers.

The presentation of the results of the sprint essentially serves to enable feedback and promote collaboration. The sprint review lasts a maximum of four hours for a sprint that lasts four weeks. If the duration of the Sprint is shorter, then the Sprint Review should also be adjusted accordingly. The Scrum Master is responsible for ensuring that the event takes place and that everyone knows the reason for the event. In addition, the Scrum Master helps to ensure that everyone who participates in the event contributes to keeping the event within the specified time frame. The result of the Sprint Review is a revised Product Backlog. The Product Backlog can also be fundamentally adjusted if new opportunities arise.

The Sprint Retrospective

The goal of the Sprint Retrospective is to gather feedback to improve the development process organizationally and structurally. It is not about feedback related to the achieved work as in the Sprint Review, but about the way of working, how it was and what can be improved. In essence, it is about identifying potential for improvement in terms of people, interactions, process and tools.

The event always takes place after the Sprint Review and before the upcoming Sprint Planning. The event takes the form of a presence event. The entire team participates in the event, but not the stakeholders. This is because the Sprint Retrospective refers to an improvement of the development work, i.e. the way the developers including the rest of the team worked together. However, the focus of the stakeholders is on the outcome of this process, i.e. the product. The duration of the event is limited to a maximum of three hours for a sprint lasting four weeks. In the case of a shorter sprint, the sprint retrospective lasts correspondingly shorter.

The Scrum Master is responsible for organizing the event. In addition, he must ensure that all participants know the reason for the event. He participates in the event because he is responsible for ensuring that the rules are followed. The sprint retrospective is one of the most essential events in which the Scrum master can check compliance with the rules and possibly become active in a coaching capacity. He must also ensure that the event is productive and positive. In addition, he should encourage all participants to ensure that the event remains within the planned time frame.

The roles of the Scrum framework

Scrum has a very simple and clear definition of the different roles within the Scrum framework. For each of these roles, it is very clearly described what their tasks are and what their competencies and responsibilities are. It is important that each member of the Scrum team knows what their role is and what the expectations are for that role. This is necessary to successfully implement the framework. If the values according to Scrum apply to all members of the Scrum team on the one hand, the roles for each individual team member on the other hand define their tasks very specifically and individually per role.

The Scrum Team

The Scrum team works self-organized and interdisciplinary. Ultimately, according to Scrum, it is important that the Scrum team is highly motivated and can decide independently how to achieve the respective goal. It does its work without having to rely on people from outside the Scrum team. In addition, Scrum teams are interdisciplinary.

Interdisciplinary here means that the teams are mixed in terms of their skills and abilities. Often in non-scrum projects, teams form individual sub-projects according to function holders or specialist areas. An example of this is a sub-project for product strategy and a sub-project for IT implementation. In Scrum, these individual persons and topics are all combined into one team. There is no longer a separation into sub-projects. In the Scrum team, there is a clear definition of roles. Each team member knows exactly which role he or she is supposed to perform.

The SCRUM Stakeholders

The framework recognizes a total of three roles, these are referred to in their entirety as the team. All those who are not part of the team but have an interest in the development of the product or knowledge about the product, are called stakeholders. Stakeholders are therefore not part of the team itself. And yet they participate in the process in different ways. Typical stakeholders in projects are: Customers, Users, Managers.

The three roles of SCRUM

In its core Scrum knows only three roles: the product owner, the Scrum master and the developers. The main tasks of these roles are the following:

 

Product Owner: They represent the interests of the client or customer. They are responsible for the business success of the product.

Scrum Master: They are responsible for the implementation of the Scrum framework. They are kind of a rule keeper, facilitator and coach.

Developers: They are the ones that actually develop the product. They are responsible for organizing itself in such a way as to achieve the respective goal of the Sprint. The developers are the heart of Scrum framework. They are responsible for the most important part of a Scrum project: Developing the product.

The Product Owner

The product owner is responsible for the “what” of the product. What do the developers have to implement in order to maximize the value of the product? They have the following tasks, responsibilities and competencies:

Tasks of the Product Owner

The Product Owner is very actively involved throughout the process. At the beginning of the process, they have the task of coordinating with the stakeholders to agree on the features of the product to be developed. They also have to manage these product features in a structured manner in the form of a product backlog. Their essential tool is the product backlog. During the development work itself, they withdraw somewhat and leave the most important decisions to the developers.

After a sprint or at the end of the sprint, the Product Owner becomes more active again in the form of directing their attention to whether the most important product backlog items have been processed during the development work.

Specifically, they have the following tasks:

• Maximizing the value of the product by prioritizing the Product Backlog items

• Optimizing the value of the developers work

Product Owners can perform these tasks alone or delegate them to others. However, the Product Owner remains accountable. They have a vision for the product and are passionate about the product.

Competencies of the Product Owner

The Product Owner has the competence for the following topics:

• They have the authority, as the only one in the Scrum team to delegate tasks to the developers, in the form of requirements defined in the backlog.

• They act on behalf of the stakeholders, such as the customer or management, or represents their interests within the SCRUM process and have all the powers related to the product to make it successful.

• The product owner “owns” the product, so to speak. Ideally, they are also the one who have the budget necessary to develop the product.

• The Product Owner is the owner of the product backlog and determines the competence of the backlog items in the product backlog or prioritizes them.

Responsibility of the Product Owner

The Product Owner is responsible for the following topics:

• Responsibility for the financial success of the product

• Maximizing the value of the product in general and in each sprint

• Management and maintenance of the Product Backlog

• Entries in the product backlog must be clearly formulated.

• Entries in the product backlog should be sorted in such a way that goals and missions are optimally achieved.

• The entire organization must respect the product owner

• Decisions of the product owner must be visible in the content and sequence of the product backlog.

The Product Owner is a role in the Scrum team that may only be performed by a single person. The reason for this is that it is the only way to ensure that there is always a clear prioritization of the backlog items. In addition, this way there are always clear answers to questions from both the developers and the stakeholders. The product owner also has the responsibility to bundle the goals and requirements of the stakeholders and to represent them in the development work.

For this reason, the product owner has two faces, so to speak; one that faces the stakeholders: Here, it is a matter of continuously understanding, sorting and bundling the requirements of the stakeholders. And another face facing the developers: Here, his task is to organize the development work efficiently through clear specifications in the product backlog. And also to evaluate or accept development results according to clearly defined acceptance criteria.

The SCRUM Master

The Scrum Master is virtually responsible for everything that makes a Scrum project characteristic of a Scrum project: the Scrum rules. He ensures that everything during the sprint runs according to the Scrum rules.

Tasks of the Scrum Master

In SCRUM, there is no project leader or project manager equipped with leadership skills. However, the Scrum master has many tasks that would otherwise be assigned to a classic project manager. This is because he has to design the entire process and its communication and event structures according to the rules of Scrum. His role is that of a coach or moderator.

He has the task of enabling the other team members in the team to apply the rules of Scrum for the most efficient project work. He is also responsible for teaching everyone who is not part of the team how to interact successfully with the Scrum team. In addition, he or she assists everyone in designing these interactions to ensure maximum value from the Scrum team’s work.

Responsibility of the Scrum Master

The Scrum Master has responsibility for the following:

• Ensuring that all stakeholders understand SCRUM theory

• Practices, rules, and values

• He is an ambassador within the organization for everything related to Scrum.

Competencies of the SCRUM Master

The Scrum Master has the following topics as competencies:

• The Scrum Master has the competence to point out to all Scrum team members when they don’t apply the Scrum “rules” correctly.

• In addition, he has the competence to take measures at any time that are necessary to strengthen the understanding of the Scrum framwework in the team and thus also to improve their application.

Basic tasks of the Scrum Master

The Scrum Master is thus the rule-keeper within the process. He must ensure at all times during the development work, the events, etc. that all participants adhere to the framework according to the guideline and that all events take place in the appropriate form. He acts as a moderator and coach. This means that he does not act as a project manager or project leader at any time; his role is merely supportive in the Scrum process. His goal is to enable the team to work according to the rules and to be efficient.

The developers

The developer is responsible for the “how”: how is the product developed and implemented?

Characteristics of the developers

Developers have very specific characteristics that make up the spirit of SCRUM. These are described below.

Team size

Developers consist of a number of three to nine team members. Seven people are considered optimal. In the context of this calculation, you do not count the SCRUM Master and the Product Owner. They are members of the team, but not the developers.

Self-organizing

Developers do not have project managers or sub-project managers. They organize themselves. It is the responsibility of the organization or company to do everything it can to help developers organize and manage themselves. It provides all the competencies and resources necessary for this. The only specification that the developers get from the product owner is the type and priority of the product features that are to be implemented in all sprints. These are stored in the so-called product backlog. How the team achieves the product features of the Sprint Backlog and the goals of the Sprint is solely up to the developers.

Interdisciplinary

All development teams work interdisciplinarily. This means that different competencies and skills exist within the team.

No titles

There are no titles among the developers. The roles among them are all equal. Titles are thus not relevant. However, this does not mean that there are not different distributions of tasks within the team. However, this distribution of tasks is always defined by the respective task and is not manifested by the assignment of a title within the team.

The developers remain responsible as a team

The developers may organize tasks within the team with different competencies, but they always remain responsible as a whole for achieving the goal of a sprint. No one developer has more or less responsibility than another on the team. The team as a whole is always responsible for success.

Tasks of the developers

The main task of the developers is to build or develop the product properly. They are the only ones who work on the increment. All other tasks of the developers have to be subordinated to this main task and are only supportive to ensure this during the sprint.

It is important that the individual tasks are with the various developers. The developers themselves distribute the various tasks to the according person. Ideally, as many developers as possible work on a backlog item. It should be avoided that too many of them work on too many different backlog items in parallel. The principle of focusing and prioritizing processing one after the other therefore applies. Even if different tasks are distributed among different developers, responsibility remains with the entire team.

Responsibility of the developers

The developers are responsible for the following topics:

• Responsibility for the development of the current increment

• Prioritization of tasks of the developers

• Organization of the Daily Scrum (rooms etc.)

• Daily participation and involvement in the Daily Scrum

• Leading the Daily Scrum according to the Scrum guide

• Tracking of the progress in the Sprints including updating of the tools used for this purpose (e.g. Taskboard, SprintBurn-down Chart)

Competencies of the developers

The following topics belong to the competencies of the developers:

• Ownership of the Sprint. Only the developers can make changes to the Sprint Backlog. No one else in the Scrum team is allowed to do this.

• Decision-making authority on “how much”, i.e., quantity and scope within the scope of Sprint Planning.

Optimal team size of the developers

Optimal is between three and nine team members. With fewer than three team members, there is a risk of creating a skills gap.More than nine developers together have a very high coordination overhead. These calculations do not include the Scrum Master and Product Owner.  They are only part of the developers if they also participate in the processing of the backlog items. If possible, the developers should be the same people throughout the entire process. The reason for this is that a better learning curve can be represented within the framework of the process. In addition, what is learned can be better continued in the context of the interaction between the team members.

The artifacts

In Scrum there are three artifacts: the Product Backlog, the Sprint Backlog, and the Increment.

The Product Backlog

The Product Backlog is a listing of all the product features that the product should contain. The product features in the Product Backlog are called Product Backlog Items. They are arranged in a specific order of priority. It is the single source of all requirements for the product and all changes made to the product. The Product Backlog exists as long as the product exists. It also contains all backlog items or user stories that have already been processed.

The Product Backlog is never complete; it lives throughout the entire development process and is constantly reviewed and adapted. The first version of the Product Backlog shows the requirements that are initially known to the best of the company’s knowledge. The Product Backlog changes over time as the product’s area of use and also the product itself change. The Product Backlog is therefore very dynamic. It is constantly changing to determine what the product requires to be adequate, competitive, and useful.

When a product exists, there is also a Product Backlog. So, in the long term, the Product Backlog contains all the features, functions, requirements, enhancements, changes that must be included or implemented in future versions of the product. Each of these entries in the Product Backlog are called Product Backlog Item. Each Product Backlog Item has several attributes: Description, Prioritization, Estimation, etc. In most cases, Product Backlog Items also contain a description of the acceptance criteria. This defines the “Done” in the context of acceptance by the Product Owner.

Who is responsible for the Product Backlog?

The Product Owner is responsible for the Product Backlog. He has the responsibility to create the Product Backlog and maintain it throughout the process. In particular, he is responsible for its content, its structure, the prioritization of the Backlog Items and its availability.

How to use the Product Backlog?

The Product Backlog is present throughout the entire Scrum process. It is the basis for the transparency of the product/increment at any time. The Product Backlog is the collection of several Backlog Items, which in their entirety ultimately encompasses all the functions that the product to be developed has to offer. In the first step, a Product Backlog Item is just the name of a requirement.

The Sprint Backlog

The goal of the Sprint Backlog is to make it transparent to the developers which Backlog Items are to be implemented during the Sprint and how. In addition, it provides information about the current status of the developers work at any point during the sprint and about which tasks still need to be completed in order to achieve the sprint goal. To ensure continuous improvement, it also contains at least one improvement action that was identified as important or of high priority during the last sprint retrospective. The Sprint Backlog is ultimately a subset of the Backlog Items from the Product Backlog. The selection of these Backlog Items from the Product Backlog for the Sprint Backlog takes place during Sprint Planning.

Who is responsible for the Sprint Backlog?

The responsibility for the Sprint Backlog lies solely with the developers. Only them can make adjustments and changes to the Sprint Backlog. The prerequisite for a Backlog Item to be transferred to the Sprint Backlog is firstly that it is sufficiently detailed. So detailed that the developers have all the information transparently that is necessary to work through the Backlog Item within the scope of the Sprint.

How to use the Sprint Backlog?

The Sprint Backlog contains a plan for how the increment will be delivered and thus how the Sprint goal will be achieved. Specifically, the Sprint Backlog contains a plan from the developers about what functionality will be the next product increment and about the development work required to move the functionality to a “Done”. This plan must be detailed enough to be used and leveraged in the Daily.

The Increment

The increment is the product in its most current delivery state including everything the developers implemented in the current sprint.

You also call the increment the product increment. It includes all product backlog items that were implemented during the past sprints. It also includes the value of all increments that were implemented in the previous sprints. The increment is virtually always the current product in its last release state. The increment represents an important component and share for achieving the project goal or product vision.

Who is responsible for the increment?

The developers are responsible for creating a deliverable increment at the end of each sprint. After its completion, the developers hand over the increment to the product owner. The product owner is responsible for deciding whether to release the increment or put it into operation. He can accept the product and still decide that he does not want to release it.

How to use the increment?

At the end of each sprint, the developers hand over their work to the Product Owner in the form of a deliverable increment. An important prerequisite for the handover is that the increment is ready for delivery. This includes that it meets the team’s “Definition of Done” on the one hand and is also in a potentially deliverable state. In a well-coordinated team, this check should not only be carried out when the increment is handed over to the Product Owner but also during the sprint. The increment must be release-ready. Regardless of whether the Product Owner considers it suitable or not.

Take the IFAAI Scrum Master and/or Product Owner certification now!

With the internationally recognized and respected IFAAI Scrum certification, you will manage projects at expert level. Prove your expertise with the IFAAI Scrum Master certificate and start agile!

Get you Scrum Certificate now!