1 Introduction

Traditional Project
2 Management

Traditional Project
3 Management

Project Management
4 Process Models

Automotive PLC
5 Introduction to Agile

Agile Manifesto
6 SCRUM Part 1

7 SCRUM Part 2

Project Management
LESSON 7 – SCRUM PART 2

25.05.2023 1
 SCRUM Framework

Product Backlog:
Impedient Backlog
Joint planning of the Sprint
Obstacles during the Sprint

Product Increment:
Sprint Backlog: Review of Sprint results,
Joint planning of the Sprint updating Product Backlog

25.05.2023 2
 SCRUM Roles – Product Owner
The product owner is responsible for the commercial
success of the product to be developed.
He represents the relevant customer requirements from
a business point of view and summarizes them in a so-
called Product Backlog (requirements catalog).
The individual customer requirements are prioritized in
this product backlog and made available to the team.
The product owner represents the customer's interests.
However, he should not be identical with the customer,
as he is at the same time responsible for the economic
success (from the company's point of view) and works
closely with the team.
The product owner has clearly defined tasks, such as
the creation, maintenance and evaluation of the product
backlog and the evaluation of the product increments.
Delegating these to the customer is difficult in practice
and critical from an economic point of view, as the
company would then completely lose control of the
project content.
1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 167ff
25.05.2023 3
 SCRUM Roles – Team
The team consists of interdisciplinary experts and
implements the customer requirements communicated
by the product owner on its own responsibility.
The team alone determines how this implementation is
to take place, without any influence from the product
owner (or other persons).
The team organizes itself and works according to the
pull principle. This means that tasks are not assigned by
a project manager or a comparable authority. Rather,
each team member collects his or her tasks
independently from the task list, the so-called task
board.
There is no hierarchy within the team. The team should
comprise between 3 and 8 people.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 167ff

25.05.2023 4
 SCRUM Roles – SCRUM Master
The Scrum Master is a promoter of agility and at the
same time a coach.
The Scrum Master is an expert in planning and
executing projects with Scrum. He supports the team in
working efficiently and promotes the project and Scrum
to people outside the team. He supports the product
owner and the team in all questions concerning the
process model.
The Scrum Master tries to remove obstacles in the
development that the team cannot solve on its own.
Across projects, the Scrum Master acts as a change
manager and drives the cultural change towards an
agile company.
The goal should be to make the Scrum Master as
redundant as possible and to run Scrum projects with
qualified Product Owners and strong teams.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 167ff

25.05.2023 5
 SCRUM Roles

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 167ff

25.05.2023 6
Project Organization – Comparison of Competences
Role agile project management compared to traditional project management
Client Decision-making authority regarding project Decision-making authority regarding project alignment
alignment Social competence
Social competence Negotiation competence
Negotiation competence Professional competence
Professional competence
Steering Preliminary decision-making body Preliminary decision-making body
Commitee Connection project - line Connection project - line
Project Self-competence
Manager Social competence
Negotiation competence
Team and leadership competence
Technological/Professional competence
Methodological competence
Decision-making authority within the framework of the
project
PMO Methodological competence

7
Project Organization – Comparison of Competences
Role agile project management compared to traditional project management
Product Owner Self-competence
Social competence
Negotiation competence
Technological/Professional competence
Decision-making authority within the
framework of the project
SCRUM Master Self-competence
Social competence
Team and leadership competence
Methodological competence
Team Team and leadership competence (Self Technological/Professional competence
Organizing)
Technological/Professional competence
Decision-making authority of the subjects of
the upcoming Sprint

8
 SCRUM Activities
The Scrum Activities describe the steps of the Scrum process.

Activities SPRINT 1 SPRINT 2

Implementation

Retrospektive
Estimation

Estimation
Planning 1

Planning 2

Planning 1
Planning

Planning
Meeting

Meeting
Release

Release
Review
Sprint

Sprint

Sprint

Sprint

Sprint
…

Scrum

Scrum

Scrum
Daily

Daily

Daily

…
Input/Output/Artifacts x: pa rtici pa nt
PB | SB PI (x): optiona l pa rtici pa nt
PB PB | RP PB TB IB IB IB IB IB PB PB | RP PB IB: Impedi ment Ba ckl og
Roles Product Owner x x x x x x x PB: Procuct Ba ckl og
PI: Product Increment
Scrum Master x x (x) x x x x x x x x RP: Rel ea s e Pl a n
Team x x x x x x x x x x x SB: Spri nt Ba ckl og
Client x x (x) x x TB: Ta s k Boa rd

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 9
 SCRUM Activities
SPRINT
A sprint is a fixed period of time in which the requirements for the product are implemented.
A sprint begins with its planning. This is followed by the implementation of the planned user stories. At the end of
the sprint, the achieved product increment (result of the sprint) is reviewed (sprint review) and internal processes
are optimized (sprint retrospective). This is immediately followed by the next Sprint, which starts planning again.
Literature suggest a Sprint duration of 30 days. In a smaller project a shorter period if 14 days for progress in
quicker iterations or a period of 60 days in large scale projects can make sense to reduce administrative efforts.
The Sprint duration should always be held constant within a project and ideally cross-project for similar projects, so
the team can easier and more precisely estimate their velocity.
Every Sprint could be seen as a small sub-project with defined scope. The magic triangle is defined in comparison
to traditional managed project with constant time and constant resource utilization.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 10
 SCRUM Activities
SPRINT PLANNING
▪ Determination of the goals of the sprint (Sprint Planning 1)
▪ Transfer of the user stories to be implemented in this sprint from the product backlog to the sprint backlog
▪ Determining how the selected User Stories are to be implemented (Sprint Planning 2)
SPRINT PLANNING 1
The user stories of the prioritized Product Backlog must be estimated in terms of their size (complexity). This can be
done in a separate estimation meeting or at the beginning of Sprint Planning 1.
Based on the now prioritized and estimated Product Backlog, the contents of the next Sprint are defined by the
Product Owner and the Team. Every Sprint has a SPRINT GOAL defined and therefore fitting user stories should be
selected from the Product Backlog. The goal should be specified SMART (specific, measurable, achievable, realistic
und time-bound)
The Sprint Goal and extend of delivery for the next Sprint (User Stories to be solved) are then agreed between the
Product Owner and the Team.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 11
 SCRUM Activities
SPRINT PLANNING 2
This planning is conducted by the team and supported by the SCRUM Master typically without the Product Owner
participating.
The Team then works out how implementation is to be achieved and breaks this down into individual tasks, which
then form the Sprint Backlog.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 12
 SCRUM Activities
SPRINT IMPLEMENTATION
▪ Self-organizing implementation of the user stories of the Sprint Backlog
▪ Self-organizing progress recording and analysis
▪ Daily SCRUMs

The team is starting the self-organized implementation assisted by the SCRUM Master for removal of unforeseen
obstacles.
As agile development depends much on face-to-face cooperation the Daily SCRUM is an important part for the
successful implementation of a Sprint.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 13
 SCRUM Activities
DAILY SCRUM
During the sprint, a short meeting takes place, the so-called Daily Scrum.
It is the central instrument for:
▪ capturing and analyzing of the current status
▪ identification of obstacles
▪ synchronization of tasks in the team
▪ initiation of control measures
▪ planning the next 24 hours

The Daily Scrum (DS) should be the only scheduled regular meeting of the team.
Typical agenda points are: What was achieved since the last DS, What should be achieved until the next DS, What
obstacles cannot be solved by the team itself (are taken along by the Scrum Master and noted in the Impediment
Backlog), What support is necessary to become faster/better.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 14
 SCRUM Activities
SPRINT REVIEW
▪ Team presents current product increment to customer for evaluation
▪ Collecting feedback
▪ Discussion of impact on product backlog

At the end of the sprint, a new product increment (intermediate or final result of the product) is created from the
results of the completed tasks. This fulfills the requirements of the user stories planned for the sprint. The product
increment is reviewed or made available for use in the Sprint Review.
At the end of the Sprint Review, the team has new insights into the acceptance of the current product increment,
can assess risks for further development and provide countermeasures. The product backlog is updated, i.e., new
user stories are added if necessary, existing user stories are revised, and prioritization is reviewed.
As the focus of the Sprint Review lies on the Product Backlog and communication with the customer the
responsible person for this meeting is the Product Owner.

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 15
 SCRUM Activities
SPRINT RETROSPEKTIVE
▪ Sprint review
▪ Identifying possible improvements
▪ Optimize internal processes for the next sprint

While the Sprint Review focuses on product increment and fulfillment of customer requirements, the Sprint
Retrospective analyzes team-internal collaboration and the interfaces to other areas of the company.
In the end, this also benefits the customer, as the team becomes faster, the results achieve a higher quality and
the overall motivation increases.
The sprint retrospective is also used for lessons learned and secures and analyzes experiences gained.
Because of the focus on the non-product / non-technological / processual topics this meeting is led by the Scrum
Master

1) Modernes Projektmanagement; Kuster, Jürg et. al. (2019), p. 178

25.05.2023 16
 SCRUM Framework
Sprint Retrospektive:
Review and improvement of the way of
working

Daily Scrum:
Daily information & coordination

Sprint Review:
Sprint Planning:
Review of Sprint results,
Joint planning of the Sprint
updating Product Backlog

25.05.2023 17
 SCRUM Dysfunctions (Simon Flossmann)
Scrum Dysfunction 1: Undone Scrum
Organizations that want to take advantage of agile often fail to do so because of this fundamental principle of the
software development manifesto:
▪ Working software is the most important measure of progress.
▪ In Scrum, "working software" means having a "Done" increment every sprint. This is because only a usable
increment establishes transparency of the current state. Teams that are not able to do this are not yet doing
Scrum. We refer to this dysfunction as "Undone Scrum."
▪ A common symptom of "Undone Scrum" is that the Scrum team does the development. Requirements analysis
and delivery take place in a different team.

1) https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
25.05.2023 18
 SCRUM Dysfunctions (Simon Flossmann)
Scrum Dysfunction 2: Zombie Scrum
If team members attend Scrum meetings only to be able to cross them off the to-do list, they perform Scrum as if
they were zombies.
Typical signs of zombie-like behavior:
▪ In the Daily Stand-up, the developers discuss what each of them did yesterday, but they don't create a plan for
today's workday.
▪ In Sprint Review, the team presents completed features to stakeholders without taking feedback.
▪ In the retrospective, they discuss what went badly in this sprint, but no improvement actions are decided for the
next sprint.
So there is a review of the work, but no adjustment. This dysfunction, where the pulsating heart of continuous
improvement is missing, is what Flossmann1) calls Zombie Scrum.

1) https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
25.05.2023 19
 SCRUM Dysfunctions (Simon Flossmann)
Scrum Dysfunction 3: Uniform Mash Scrum
What is the sprint length of your Scrum team?
Chances are your answer is "two weeks." In a CA Technologies survey, 59.1% of respondents said their sprint was
two weeks long.
Standardizing sprint length for every Scrum team in the company is just one sign of "unity Scrum." Other signs
include these:
▪ Each Scrum team must describe requirements in terms of user stories.
▪ Teams must complete a fixed number of story points per sprint.
▪ Each Scrum team must include exactly 4 developers, 2 testers, 1 analyst, 1 designer, 1 product owner and a
Scrum master.
When organizations care more about control and predictability of a process than value generation, it often leads
them to standardize processes across all teams in the organization. As a result, regular review is lost and "one-size-
fits-all" Scrum is created.

1) https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
25.05.2023 20
 SCRUM Dysfunctions (Simon Flossmann)
Scrum-Dysfunction 4: „Best Practice“-Scrum

There are no best practices in Scrum!

Software product development and delivery are not always predictable. To be successful, it takes creativity and a
willingness to try new things. In the process, self-organizing teams discover practices that work best for them. But
transferring them one-to-one to other Scrum teams, products or contexts doesn't work. Self-proclaimed experts who
claim that Scrum teams are only successful if they use best practices such as User Stories, Story Points and
Planning Poker are hindering continuous improvement. But that's what Scrum is all about at its core.
If the adaptation to the actual situation is missing, I call this Scrum dysfunction "best practice" Scrum.

1) https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
25.05.2023 21
 SCRUM Dysfunctions (Simon Flossmann)
Scrum Dysfunction 5: "This doesn't work here"-Scrum.

Since the introduction of Scrum, the team has been working more efficiently.
The Scrum team now schedules its work more regularly, resulting in less wasted work time. Nevertheless, the team
is not able to regularly provide a new version of the product at the end of the sprint. The reason for this is quickly
found; the team often must wait for input from other teams or experts. When asked about this problem, the
response from team members is, "That's just how we work here." As a solution to this problem, team members see
that they now no longer use a Definition of Done.
These are signs of an environment where "This isn't working here" Scrum is being practiced. The framework that
Scrum provides to these teams helps them review how they work. However, there is a lack of alignment in their way
of working.
The bitter truth: Either we do Scrum or we don't do Scrum. Changing Scrum does not solve the problems.

1) https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
25.05.2023 22
 Literature
Project Management Institue (2013): A Guide to the Project Management Body of Knowledge (PMBOK Guide)
Wohland, Gerhard & Huther-Fries, Judith & Wiemeyer, Matthias & Wilmes, Jörg (2004): Vom Wissen zum Können.
Merkmale dynamikrobuster Höchstleistung. Eine empirische Untersuchung auf systemtheoretischer Basis.
Eschborn: Detecon & Diebold Consultants
Pflaeging, Niels & Hermann, Silke. (2015). Komplexithoden. Clevere Wege zur (Wieder)Belebung von Unternehmen
und Arbeit in Komplexität. München: Redline
Kuster, Jürg; Bachmann, Christian; Huber, Eugen; Hubmann, Mike; Lippmann, Robert; Schneider, Emil; Schneider,
Patrick; Witschi, Urs; Wüst, Roger. Handbuch Projektmanagement (German Edition) Springer Berlin Heidelberg.
Kindle-Version.
Axelos (2016): PRINCE2 Certifications. Online verfügbar unter http://www.axelos.com.
Wysocki, Robert K. (2014): Effective project management. Traditional, agile, extreme. 7th ed. Indianapolis, Indiana:
Wiley.

25.05.2023 23
 Literature
VDI/VDE 2206 (2021): Development of mechatronic and cyber-physical systems, VDI/VDE-Gesellschaft Mess- und
Automatisierungstechnik
ISO 26262 (2018): Road vehicles – Functional safety, ISO
Automotive SPICE® Process Reference and Assessment Model (2017), Automotive Special Interest Group and the
Quality Management Center in the German Association of Automotive Industry (VDA QMC)
agilemanifesto.org (2022) - Manifesto for Agile Software Development
scrum.org (2022) – The SCRUM Framework
Cohn, Mike (2013): User-Stories applied. For agile software development. 18. print. Boston, Mass.: Addison-Wesley
(Addison-Wesley signature series).
Simon Flossmann (2022); 6 Scrum-Dysfunktionen, die die Wertschöpfung behindern;
https://www.scrum.org/resources/blog/6-scrum-dysfunktionen-die-die-wertschopfung-behindern
Anderson, David J. (2010): Kanban. Successful evolutionary change for your technology business. Sequim, WA: Blue
Hole Press.

25.05.2023
 Literature
Ohno, T. (1988): Toyota Production System: Beyond target scale production; Cambridge Productivity Press
Liker, Jeffrey K (2006).: Der Toyota Weg: Erfolgsfaktor Qualitätsmanagement; FinanzBuch Verlag
The Standish Group International ed. (2009): CHAOS Summary 2009 report; West Yarmouth, The Standish Group.
Womack, James P. et. al. (2013): Lean Thinking: Banish Waste and Create Wealth in Your Corporation; Free Press
DIN 69901 (2013) Projectmanagement; GPM Deutsche Gesellschaft für Projektmanagement
DIN EN ISO 9001:2015-11 Qualitätsmanagementsysteme.

25.05.2023 25