1 Introduction

Traditional Project
2 Management

Traditional Project
3 Management

Project Management
4 Process Models

Automotive PLC
5 Introduction to Agile

KANBAN
6 Lean Project Mgmt.

Project Management
LESSON 6 – PROJECT MANAGEMENT
PROCESS MODELS

10.05.2023 1
Agile Manifesto – 12 principles
▪ Our highest priority is to satisfy the customer ▪ The most efficient and effective method of
through early and continuous delivery conveying information to and within a development
of valuable software. team is face-to-face conversation.

▪ Welcome changing requirements, even late in ▪ Working software is the primary measure of
progress.
development. Agile processes harness change for
the customer's competitive advantage. ▪ Agile processes promote sustainable development.
The sponsors, developers, and users should be able
▪ Deliver working software frequently, from a to maintain a constant pace indefinitely.
couple of weeks to a couple of months, with a
preference to the shorter timescale. ▪ Continuous attention to technical excellence
and good design enhances agility.
▪ Businesspeople and developers must work ▪ Simplicity--the art of maximizing the amount
together daily throughout the project. of work not done--is essential.
▪ Build projects around motivated individuals. ▪ The best architectures, requirements, and designs
Give them the environment and support they need, emerge from self-organizing teams.
and trust them to get the job done.
▪ At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

2
Agile Manifesto – 12 principles
Principle of agile project management Compared to traditional project management
Our highest priority is to satisfy the customer Highest priority is to satisfy the customer through fulfilling
through early and continuous delivery all requirements in the final product and achieve a high
of valuable software. product quality
Welcome changing requirements, even late in Try to fix the requirement early in the project. Minimize the
development. Agile processes harness change for risk of requirements changes as they impact the plan for
the customer's competitive advantage. the project.
Deliver working software frequently, from a Delivering a product after a fixed schedule (SOP)
couple of weeks to a couple of months, with a No changes to the product after freeze milestones
preference to the shorter timescale.
Business people and developers must work Development teams are assigned to project and often
together daily throughout the project. work on multiple projects. Business people are mainly
controlling the project or external stakeholders.
Build projects around motivated individuals. Projects are often built around “cheap” unqualified
Give them the environment and support they need, personal that is not intrinsically motivated but controlled.
and trust them to get the job done. Project management is continuously controlling and
monitoring the project advancement.
3
Agile Manifesto – 12 principles
Principle of agile project management Compared to traditional project management
The most efficient and effective method of Project teams are often spread across different
conveying information to and within a development departments and locations mainly communicating through
team is face-to-face conversation. scheduled meetings or written documentation.
Working software is the primary measure of progress. Fulfillment of all requirements is the main goal. The project
progress is usually measured in delays, budget or resource
usage.
Agile processes promote sustainable development. Traditional projects often have changing tempo and
The sponsors, developers, and users should be able amount of work packages throughout the project.
to maintain a constant pace indefinitely. Project managers are bearing much responsibility and
controlling tasks but do not have much authority.
Continuous attention to technical excellence Projects are often built around “cheap” unqualified
and good design enhances agility personal that is not intrinsically motivated but controlled.
Instead of technical excellence supposedly cheap
solutions are often chosen.

4
Agile Manifesto – 12 principles
Principle of agile project management Compared to traditional project management
Simplicity--the art of maximizing the amount Traditional projects focus on making plans in advance and
of work not done--is essential. then follow these plans
The best architectures, requirements, and designs The project manager typically has many responsibilities but
emerge from self-organizing teams. not much authority. Early escalating instead of problem
solving inside the project.
Controlling of the project team and project progress
instead of trust in a self-organized team.
At regular intervals, the team reflects on how Plans typically do not include regular self-reflexion. Only at
to become more effective, then tunes and adjusts the projects ending lessons learned and analysis of the
its behavior accordingly. project is done.

5
 SCRUM
Scrum was at the beginning very strongly influenced by the lean and innovative ways in product development in
Japan (Lean Management).
Scrum consists of a few rules. The picture shows schematically the procedure according to Scrum. The start phase
(initialization and product conception) is followed by iterations or sprints in pre-planned time intervals (timeboxes).
The agreed partial assignments are processed by teams that act largely on their own responsibility and organize
themselves.

10.05.2023 6
 Understanding SCRUM
To understand Scrum, you will first learn about the following components:
The Scrum artifacts
▪ Product Backlog
▪ Sprint Backlog
▪ Product Increment
▪ Release Plan
▪ Impediment Backlog.

The Scrum roles

▪ Product Owner
▪ Team
▪ Scrum Master

10.05.2023 7
 Understanding SCRUM
To understand Scrum, you will first learn about the following components:
The Scrum activities
▪ Sprint
▪ Sprint Planning
▪ Daily Scrum
▪ Sprint Review
▪ Sprint Retrospective

10.05.2023 8
 SCRUM
The basic principle of these variants is the relatively short and predefined iteration cycles (timeboxes), within which
highly motivated teams develop and test solutions (increments) on their own responsibility.
Scrum projects are carried out by self-organizing interdisciplinary teams.
These deliver a product increment at fixed intervals, so-called sprints. A product increment is the result of a sprint.

10.05.2023 9
 SCRUM
At the end of each sprint, there is an evaluation meeting called a sprint review. In this meeting, the product
increment is evaluated and assessed from the customer's point of view.
In the process, learning experiences or new user insights are incorporated into the next cycle.
Further sprints with new product increments follow, until the product desired by the customer is created at the end.

10.05.2023 10
 SCRUM
A sprint is planned in such a way that at the end an increment is created that represents added value and is
functional.
This focus on delivering value avoids dealing with side issues or unimportant things.
In sprint planning, the product owner specifies his priorities, wishes and the sprint goal.
Ultimately, however, the team decides on the effective content of the sprint according to the pull principle. This
promotes personal responsibility and self-organization. In addition, the pull system avoids systematic overloading of
the team.
It is also advisable to identify and address problems and obstacles at an early stage. Particularly in the first sprints,
the sticking points should be tackled and led to a solution.

10.05.2023 11
 Understanding SCRUM
To understand Scrum, you will first learn about the following components:

The Scrum artifacts The Scrum roles The Scrum activities

▪ Product Backlog ▪ Product Owner ▪ Sprint
▪ Sprint Backlog ▪ Team ▪ Sprint Planning
▪ Product Increment ▪ Scrum Master ▪ Daily Scrum
▪ Release Plan ▪ Sprint Review
▪ Impediment Backlog. ▪ Sprint Retrospective

10.05.2023 12
 SCRUM Artifacts – Product Backlog
PRODUCT BACKLOG
The Product Backlog is a prioritized collection of requirements for the product to be developed. Unlike the
requirements specification in traditional project management, the Product Backlog does not claim to be complete.
It is a living collection that is updated and detailed during project execution.
The Requirements towards the product are part of the Product Backlog formulated as so called User Stories and
Epics
The product backlog is the collection of requirements (user stories) for the product to be developed.
The product backlog contains user stories (elaborated requirements) and epics (placeholders for requirements to
be elaborated later).

10.05.2023 13
 SCRUM Artifacts – Product Backlog
USER STORY
A user story is a requirement written from the perspective of a specific role, often that of the user. A typical
formulation is: As a user, I would like to be able to … so that …
▪ a requirement written from the perspective of a specific role, often that of the user.
▪ a typical formulation is: As a user, I would like to be able to … so that …
▪ by definition not planed in budget or man days.
▪ extent is estimated as a measure for their complexity. The result is called Story Points. Twice the story points
means twice the complexity.
▪ Usually, implementation also includes all testing and documentation work.
▪ Contains a “Definition of Done”.
▪ A user story is only fully implemented when all the work associated with the user story has been completed and
integrated into a functioning product increment.

10.05.2023 14
 SCRUM Artifacts – Product Backlog
User Stories are by definition not planed in budget or man days. Instead, their extent is estimated as a measure for
their complexity. The result is called Story Points. Twice the story points means twice the complexity.
A prerequisite for estimating the size of user stories is that there is a common understanding of the complete
implementation of a user story.
Usually, implementation also includes all testing and documentation work.
The definition of what exactly belongs to the implementation is called Definition of Done.
A user story is only fully implemented when all the work associated with the user story has been completed and
integrated into a functioning product increment. Consequently, all this work must also be considered when
estimating the size.
Depending on the type of user story, different aspects must be taken into account during its implementation.

10.05.2023 15
 SCRUM Artifacts – Product Backlog
User Stories should be similar to requirements in the requirements book of traditional project management
(SMART).
Cohn1) recommends the acronym (INVEST) as the User Stories should be:

▪ Independent
▪ Negotiable
▪ Valuable
▪ Estimatable
▪ Small
▪ Testable

1) Cohn, Mike (2013): User-Stories applied. For agile software development. 18. print. Boston, Mass.: Addison-Wesley (Addison-Wesley signature series).
10.05.2023 16
 SCRUM Artifacts – Product Backlog
User Stories are then prioritized based on the business value and customer importance of the respective user story
There are various options for the prioritization itself, such as
▪ the pure ranking of the user stories from the most important to the least important user story.
▪ the assignment of points: the smaller (or larger, depending on the convention) the number of points the more
important the user story.
▪ the classification, for example according to the MuSCoW principle into
▪ Must have
▪ Should have
▪ Could have
▪ Won't have..

User Stories with high risks involved should be prioritized high.

If these user stories are implemented accordingly early and are tried out and evaluated by the customer during the
sprint review, the risk can be considerably reduced early on.
The higher user stories are prioritized, the more detailed they should be.

10.05.2023 17
 SCRUM Artifacts – Product Backlog
User Stories can be collected by the SCRUM team on metaplan cards on a (virtual) whiteboard.

As a driver I want the HMI to As a fleet operator I want to know

display the remaining distance of where my vehicles are, so that I
my vehicle so that I know if I can can schedule optimized
finish the planned route utilization

As a passenger I want to know

where I am, so that I do not miss
the correct bus stop

10.05.2023 18
 SCRUM Artifacts – Product Backlog
EPIC
An Epic is a large, still vague user story. The requirement can only be roughly sketched and can in no way be
estimated in terms of its size (complexity).
Epics are meant as “placeholders” for requirements that are to be detailed at a later stage but must not be
forgotten.
An Epic is too vaguely described to be implemented in the next Sprint, even with high priority.

Provide Status Information

10.05.2023 19
 SCRUM Artifacts – Product Backlog
PRODUCT BACKLOG
The product backlog can be created effectively as a metaplan card on a pinboard.
Here risk and size can be estimated by the team and the cards be arranged accordingly.
Documentation of the result is typically done in lists, e.g. Excel or a tool such as Atlassian Jira

Provide Status
Information

As a driver I want the HMI

to display the remaining
distance of my vehicle so
that I know if I can finish
the planned route As a passenger I want to
know where I am, so that I
do not miss the correct
bus stop
As a fleet operator I want
to know where my vehicles
are, so that I can schedule
optimized utilization

And another cad with a

user stroy

And another cad with a

user story of even lower
priority

10.05.2023 20
 SCRUM Artifacts – Sprint Backlog
SPRINT BACKLOG
From the Product Backlog concrete TASKS need to be derived and implemented by the team.
A tasks should be able to be finished in one working day.
All TASKS derived from the selected USER STORIES are collected in the SPRINT BACKLOG
This is done during the Sprint Planning before each Sprint is started.
User Stories that will be implemented during the Sprint are selected from the Product Backlog.
How many User Stories are selected is depending on the teams VELOCITY.

10.05.2023 21
 SCRUM Artifacts – Sprint Backlog
The Sprint Backlog should be logged as a task board. A physical board or a Kanban software board can be used.

User Stories Tasks waiting Tasks worked on Tasks completed

Nomen est Nomen est Nomen est

omen omen Nomen est
omen Nomen est omen
omen
As a driver I want the HMI
to display the remaining
distance of my vehicle so
that I know if I can finish Nomen est
the planned route omen

Nomen est
omen
Nomen est
As a passenger I want to omen Nomen est Nomen est
know where I am, so that I omen omen
do not miss the correct
bus stop

Nomen est
omen
As a fleet operator I want
to know where my vehicles Nomen est
are, so that I can schedule omen Nomen est Nomen est Nomen est
optimized utilization omen omen omen

Nomen est
omen

And another cad with a

user stroy
Nomen est Nomen est
Nomen est Nomen est
omen omen
omen omen
And another cad with a
user story of even lower
priority Nomen est
omen
Nomen est Nomen est
omen omen

10.05.2023 22
 SCRUM Artifacts – Sprint Backlog
VELOCITY
is the amount of story points a team can manage throughout a sprint. The accuracy of the value depends on
experience.
How many User Stories are selected is depending on the teams VELOCITY.
A new team can only give a first guess (maybe based on experience from former team setups and projects). During
the SCRUM project the estimate gets more and more reliable, as information about the Story Points completed in
the last Sprint(s) is available.
The VELOCITY helps the team to measure its own performance.
The Story Points of a User Story are distributed to the derived tasks. All tasks therefore get their own size
estimation based on story points.

10.05.2023 23
 SCRUM Artifacts – Sprint Backlog
As a way to better measure the Sprints progress a BURNDOWN CHART can be used

10.05.2023 24
 SCRUM Artifacts – Product Increment
PRODUCT INCREMENT
The product increment is the finish line of a Sprint. The finished product is the final product increment .
A product increment always needs to be usable by and presentable to the client.
Feedback from the client is used as input for planning of the next sprint (new or improved user stories,…)
A product increment could be:
▪ A new hardware sample
▪ A new software version
▪ A new product design
▪ A new concept
▪ An improved process
▪ etc…

10.05.2023 25
 SCRUM Artifacts – Release Plan
RELEASE PLAN
The Release Plan gives an overview what user stories are planned to be implemented in which sprint.
It gives the product owner an overview how many sprints it will take to have a finished product, and when market
releases can be planned.

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

Nomen est
omen
Nomen est
omen
Nomen est Nomen est Nomen est
omen omen omen
Nomen est
omen

Nomen est
omen
Nomen est
omen
Nomen est
omen
Nomen est
omen
Nomen est
omen

Nomen est
Nomen est omen
omen
Nomen est
omen
Nomen est
omen Nomen est
omen

Product Release 1.0 Product Release 2.0

10.05.2023 26
 SCRUM Artifacts – Impediment Backlog
IMPEDIMENT BACKLOG
The Impediment Backlog serves the Scrum Master as a Board to write down all obstacles the team encounters
during the course of the sprint.
Typically, new obstacles are reported and tried to be cleared out during the Daily Scrum.
The Impediment Backlog serves as a platform for continuous learning and improvement (continuous lessons
learned).

10.05.2023 27
 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

10.05.2023 28
 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.

10.05.2023 29
 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.

10.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.

10.05.2023 31