What is Scrum

How does Scrum project management work

In today's agile software development environment, 85% of companies worldwide use Scrum. Scrum is an agile process model in project management with which the teams cooperate on an interdisciplinary basis. Self-organization is a top priority in the Scrum methodology because the interdisciplinarity and agility give you the opportunity to tackle challenges flexibly and yourself or in a team. Agility is mobility or flexibility of organizations, structures and processes as well as people. The Scrum methodology is characterized by the fact that the goal is specified by the management or client, but the teams have the freedom to design the path to the goal themselves within the specified period. The teams that use Scrum adapt to the temporal and technological changes.

On this figure two you can see the rough run of how the processes in Scrum are structured and shows the sequence of the Scrum method. This run runs through the entire transfer report.

Scrum artifacts

In comparison to other project management methods, there are three important terms in the Scrum methodology that are based on the scope of the product or service. In technical language, they are called artifacts.

Artifact 1: Product Increment (PI) A product increment, also called PI, is a finished piece of the total product. The end result of a sprint is part of the product increment. The functionality of the end product is expanded and optimized with each PI.

Artifact 2: Product Backlog In a product backlog there are new potential functionalities in the pipeline that can be planned for the next sprint. In technical jargon, these are called features.

Artifact 3: Based on the prioritized product backlog, features can be scheduled in the sprint, taking into account the development resource capacity.

Teams & roles

The Scrum development team consists of 3 team members. However, other stakeholders are involved in the project itself, which are described in more detail below. Product Owner (PO) The Product Owner is the person between the client and the development team. The requirements are received by the product owner and prioritized together with the client. Prioritization is one of the most important tasks because there must be no conflicting planning

The Product Owner is responsible for the following:

• for maximizing the value of the product and the work of the developers

• Prioritization of the backlog

• Overview of the releases and, if possible, implementation on the productively similar instance after each sprint

• Many stakeholders are involved in the project and the Product Owner is often in contact with them and tries to take into account all feedback that offers added value for the product

Scrum Master (SM)

Scrum Master is a person who is responsible for ensuring that the Scrum rules are adhered to. The teamwork and the organization of the meetings are coordinated and monitored by the Scrum Master. In addition, the Scrum Master has an overview of the developer's capacity planning so that there is no bottleneck.

Developer (Dev)

In the end, the developers deliver the product that meets the requirements of the product owner. You write the codes and end up testing your code. (Scaled Agile Framework and SAFe, 2020) When it comes to developers, a distinction is usually made depending on the technologies. Not every developer has the same potential to perform the same actions because there are different code languages available depending on the science required. There is a big difference between frontend and backend developers. Front-end developers are responsible for the front-end development. That means what the user gets to see at the end of the PI. The backend developer develops the structure of the logic in the rear part of the PI and clarifies the logic and its interfaces to the other systems in the company.

Designer (UX)

In the Scrum methodology, the designer is not explained in detail or in part. But the user experience designers play an important role. They provide designs and prototypes that enable developers to understand the user flow (e.g. user journeys) in order to more easily understand the requirements. So that the designs can be developed, the product owner works closely with the designer before sprint planning. The designs are created based on the client's requirements.

Solution architect

The solution architect is responsible for defining the general technical and architectural vision and for ensuring that the system or solution being developed is suitable for the intended purpose. The solution architect plays an important role in designing the solution for a joint project and is involved in developing solutions, checking the hypotheses and creating continuous delivery channels.


There is a client for all projects. The client instructs the product owner to create or provide a product or service. Next, the product owner works out the detailed requirements together with the client. The requirements are received and documented by the product owner. So that the importance and urgency of the requirements can be classified, the requirements should be grouped according to must or can criteria.


The users will ultimately use the increment provided. In principle, they can bring good requirements because they already know the processes from the client. It is therefore of great advantage if the users are involved in the project at an early stage so that the project team is challenged and the product or service adopts a certain quality standard.


The manager is responsible for the overall picture of the project. He supports the Scrum Team in mastering the challenges and relieving the team. In addition, investment issues can be clarified by the manager.

product manager

In the agile Scrum method, the product manager is responsible for achieving the company's or the client's goals. You must be familiar with the product and consider the following aspects when expanding your team. All impressions of the user must be taken into account, in addition to having an overview at all times of the status of development and the goal in the foreground. The product manager works closely with the product owner, because the goals must be validated by the product manager before the PI. The procedure or roadmap of the projects is also determined in coordination with the product owner.

Release Train Engineer (RTE)

The use of a release train engineer depends on the size of the project. If the project consists of several teams, it makes perfect sense to use a release train engineer. (Safe Scaled Agile, 2020) Accountability Release Train Engineer

• Creation and communication of the annual calendar of iterations and product increments (PI) • Support with the PI planning event

• Assisting in PI planning readiness by promoting a continuous exploration process that drives the synthesis of a vision, a course of action or roadmap and backlogs, as well as pre- and post-PI planning sessions

• Summarize the team's PI goals into PI program goals (the RTE) and publish those goals for visibility and transparency

• Let something escalate and follow the challenges.

• Support in tracking cross-project risks and dependencies

• Management and optimization of the value flow

Definition of feature

Depending on the needs of the client, the requirements must be recorded in the additional feature. A feature is a unit of work that is divided into various user stories. With the user stories, the focus is on the end user. Each feature represents the overall task. (Atlassian Agile Coach) This is what an overall task could look like: Customers can order mobile phones in a new online shop. The user story can be a feature and the title could be named as follows: Mobile phone order. However, this mobile phone ordering function also has more requirements. This title of the feature alone would not be sufficient for the developers because some open points have not yet been declared. These points can be solved based on the acceptance criteria. Acceptance criteria are part of the feature. Acceptance criteria Acceptance criteria are derived from a user story. Acceptance criteria specify when a user story is considered accepted or accepted. In the example already mentioned, the following acceptance criteria can be included in the feature:

Acceptance criterion 1 The customer arrives at the product listing page via the navigation bar

Acceptance criterion 2 The customer can select a cell phone via the product listing page

Acceptance criterion 3 If the customer clicks on a device, he is taken to the product detail page. Acceptance criterion 4 On the product detail page, the customer can configure the mobile phone according to color and memory size

Acceptance criterion 5 If the mobile phone is configured, the customer can add it to the shopping cart.

These acceptance criteria serve as an example and can be expanded as required. There are numerous methods by which the acceptance criteria can be defined. An efficient method is the Gherkin method and would be a support for each company . This enables the companies to present the client's needs in a more understandable way for the developers. In this way, the client also receives the desired product or service. If the first acceptance criterion in table three above is applied to the Gherkin, the Gherkin method looks like this:

Scenario The customer arrives at the product listing page via the navigation bar

Given customer is on the online shop landing page

When the customer clicks on mobile phones in the navigation bar

Then customer lands on the product listing page of the cell phones

Once the user story and acceptance criteria have been created, the stakeholders involved can also be recorded in the feature. Table five shows possible stakeholders of the feature. In this way, the developers can also see which stakeholders are involved in this project.

In addition, prototypes can be stored in the feature and open points can be noted. The effort for the feature is determined by the work performed by one worker per day and the responsibilities can also be noted if necessary.

Definition of Done (DoD)

So that all team members have the same knowledge when a story is finished, the "definition of done" should be discussed at the beginning of the project. Decision points

Definition of done

• Does the development of the developer cover the required acceptance criteria

• Has the functionality been tested by the developer

• Has the code been reviewed by another developer?

• Does the company's development meet the specified security guidelines

• Has the development been made available on the development environment?

Further points can be added depending on experience in PI and the list can be expanded accordingly.

Visualization of the features

A feature board is used in practice. The feature board is used to keep an overview of the various features and to bring transparency into the process.The board is structured as follows and is based on the basis of the Kanban board:

The features in the backlog are created by the product owner. This describes the exact requirements for achieving the target of the product increment. The requirements are to be formulated as simply, precisely and understandably as possible so that they can be understood by all team members in the end. The exact requirements for the product increment are then described there. If some created designs are available, they can already be inserted as prototypes by the designer. When the Product Owner sends the invitation to the developers to analyze the feature, the editing feature is moved to the Analysis column. It is important to understand that the board is dynamic and the features can be in different states.

Prioritization of the features

As already mentioned, the features must be prioritized. In theory, there are many methods by which the features can be prioritized. An example is explained below: prioritization according to business value. The client tells the product owner which features have the highest priority. The rating scale is between one and ten, with ten being the highest priority. If there are more than ten features in the backlog, the scale can be expanded accordingly. With this method the features can be prioritized.

Visualization of the sprint

On the day of the invitation, the feature will be discussed and refined in the team. The product owner opens the meeting by introducing the feature and introducing the details. Ideally, not only the content of the feature should be presented, but also the prototype, so that all team members have the same perception. Once the feature has been presented, the discussion can start. The developers can now mention which development functionalities are required. A visualization could look like this:

A story should be created in the feature for each function and technology. These stories are then estimated by the team based on person-days. Person days are already predefined. It corresponds to the number of employees converted into hours. The PO knows how many hours of resources are available. The simplest method for estimating the stories is the Fibonacci method. In the Fibonacci method, the stories can be estimated in the following person-days: 0.5; 1; 2; 3; 5; 8th; 13; 20; 40; 100. This number means as many person days it takes a story. The higher the number, the more complex the story.

Events & Ceremonies

Feature Refinement A frequently used event is the feature refinement. Features refinement are used to analyze the planned feature for the next PI in the team. The product owner invites the developers involved to this event. At the beginning of this meeting, the product owner introduces the feature, the process and the workflow of the user to the developers. Afterwards a discussion between the developers and the product owner is opened. The aim of the discussion is that all participating developers have the same level of knowledge. In addition, the developers should agree on a common solution and recognize internal and external dependencies and report them. All information is documented accordingly. This event is carried out for all features that are planned for the next PI. The goal of a ceremony is for stories to be created.

PI (Product Increment) Planning

PI planning is usually the largest and longest event in the Scrum method and takes about two days, depending on the size of the team. At this event, the product vision, PI goals and the agenda are communicated and discussed. The PI planning is basically moderated by the release train engineer and takes place in the last sprint. (Safe Scaled Agile, 2020) At the end of the PI planning, the following topics should be clear:

Feature board

All features that have already been refined can be seen in the feature board with their dependency on other teams.

Stories All stories can be seen on the sprint board, have been estimated according to person-days and prioritized by the product owner in the correct order.

Risks Possible risks were documented and assigned to the team members to deal with.

Dependencies on external and internal teams were identified and discussed.

The aim is that the dependencies are resolved in the next PI. Goals The Product Owner specified goals for the entire PI, which are defined according to SMART. The goals should be discussed in the team so that the employees can identify with them. This means that the goals are specific, measurable, accepted, realizable and scheduled. Example: By the end of the PI, the end user will be able to order a cell phone in the new online shop.

The following is recommended for companies:

Capacity planning In order to be able to plan the entire PI optimally, so as not to get behind schedule, it is recommended for companies if the absences of the team members are transparent in advance. This avoids unpleasant surprises and the planning is binding.

Confidence Vote It is recommended to start a satisfaction survey at the end of the PI to determine the confidence of the team members. The scale is usually from one to five. In the event of negative reports (one to three), the worries or challenges of the team members can still be discussed on site.

Sprint planning

Before a sprint starts, the team members meet. This is called sprint planning in technical jargon. The stories already created in PI Planning are discussed in the team and assigned to the developers. The priorities of the stories are given by the product owner. With a view to capacity planning, the team is prevented from becoming overloaded.


The main advantage of the Scrum methodology is basically its flexibility, i.e. agility. The agility is reflected in the sprints. With iterations, i.e. repeating cycles, a sprint is an iteration in the Scrum methodology. Depending on the team, the iteration time can be between two and four weeks. If the team agrees on an iteration period of two weeks, this iteration period must be carried out until the end of the PI. It is not allowed to change an iteration duration during the PI. After the iteration is over, a new sprint starts again.

Daily Scrum

In the Daily Scrum, all team members meet once a day and the session usually lasts about 15 minutes. Each team member asks himself whether the goal of the last Daily Scrum was achieved, what still needs to be done for the next Daily Scrum, and finally, whether there are still challenges that prevent everyday work. General discussions have no place in the Daily Scrum and should be discussed afterwards.

Sprint Review (Sprint Review)

The sprint review is used to ensure that each team member presents their progress. This serves the team, as well as the product owner, to see an overview of the progress so that action can be taken in good time if the development is deficient. In this way, delays would be recognized early and can be discussed with the client. The sprint review is usually carried out on the penultimate day before the new sprint starts.

Sprint Retrospective (Sprint Review)

A retrospective is carried out at the end of the sprint. A retrospective is also a review. In the retrospective, the team discusses what went generally well and less well in the sprint and which points should urgently be left on.

  • Went well

  • Was not so good

  • Do not continue

System demo

On the day of the system demo, the status of the development will be demonstrated to all stakeholders involved. What the team has achieved in each sprint is presented. In the best case, a system demo is organized by the release train engineer after each sprint.

Supporting tools

In order to be able to introduce the Scrum method, some important applications are required that support the team from the start. Some tools are briefly explained here, all of which can be helpful

  • JIRA

  • WIKI

  • Excel

  • Mural board

  • InVision

  • Pokerli

15 Ansichten0 Kommentare