Sie sind auf Seite 1von 106

Inhaltsverzeichnis

1 Scrum
1.1 Fakten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Probleme der Softwareentwicklung . . . . . . . . . . . . . . . .
1.1.2 Was ist Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Essens von Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Scrum Werte und Umsetzung (Prinzipien) . . . . . . . . . . . .

1.1.5 Warum schweigt Scrum uber


Softwareentwicklungs-Praktiken?
1.1.6 Selbstorganisation . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Manifesto der Agilen Softwareentwicklung . . . . . . . . . . . . . . . .
1.3 Prinzipien hinter dem Agilen Manifest . . . . . . . . . . . . . . . . . . .
1.4 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Das Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3 Das Entwicklungs-Team . . . . . . . . . . . . . . . . . . . . . . .
1.4.4 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Schatzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

9
9
9
9
10
10
11
11
12
12
13
13
13
14
15
16

2 Scrum Ereignisse/Scrum Meetings


2.1 Sprint . . . . . . . . . . . . . . .
2.2 Sprint Planning . . . . . . . . .
2.2.1 SP1 . . . . . . . . . . . .
2.2.2 SP2 . . . . . . . . . . . .
2.3 Daily Scrum . . . . . . . . . . .
2.4 Sprint Review . . . . . . . . . .
2.5 Retrospektive . . . . . . . . . .
2.6 Weitere . . . . . . . . . . . . . .
2.6.1 Scrum of Scrums . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

18
18
19
20
20
21
22
23
23
23

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

3 Artefakte
3.1 Product Backlog . . . . . . . . . . . . . . .
3.1.1 Backlog Refinement . . . . . . . .
3.2 Sprint Backlog . . . . . . . . . . . . . . . .
3.3 Inkrement/Produktinkrement . . . . . . .
3.4 Burndown Chart/Sprint Burndown Chart
3.5 Impediment Backlog . . . . . . . . . . . .
3.6 Andere Artefakte . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

24
24
25
27
27
27
28
28

4 Sch
atzungen
4.1 Abstrake Schatzmae . . . . . .
4.2 Konzepte des agilen Schatzens
4.3 Planning Poker . . . . . . . . .
4.4 Team Estimation . . . . . . . . .
4.5 Magic Estimation . . . . . . . .
4.6 No Estimation . . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

29
29
31
31
32
33
33

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

5 Retrospektiven richtig durchf


uhren
36

5.1 Warum Retro durchfuhren


. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2
5.3
5.4

Struktur einer Retro . . . . . . . . . . . . . . . . . . . . . . . .


Vorteile der Retro Struktur . . . . . . . . . . . . . . . . . . . .
Eine Retro leiten . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Zeit managen . . . . . . . . . . . . . . . . . . . . . . .
5.4.2 Dich managen . . . . . . . . . . . . . . . . . . . . . . .
5.5 Business Value von Retros . . . . . . . . . . . . . . . . . . . .
Retros . . . . . . . . . . . . . . . . . . .
5.6 Voraussetzungen fur
5.7 Retro von Retros . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting the stage . . . . . . . . . . . . . . . . .
5.8 Aktivitaten fur
5.8.1 Check-In . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8.2 Focus On und Focus Off . . . . . . . . . . . . . . . . .
5.8.3 ESVP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8.4 Working Agreements . . . . . . . . . . . . . . . . . . .
Gathering Data . . . . . . . . . . . . . . . . .
5.9 Aktivitaten fur
5.9.1 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9.2 Triple Nickels . . . . . . . . . . . . . . . . . . . . . . .
5.9.3 Color Code Dots . . . . . . . . . . . . . . . . . . . . .
5.9.4 Mad Sad Glad . . . . . . . . . . . . . . . . . . . . . . .
5.10 Weitere Aktivitaten-Ideen . . . . . . . . . . . . . . . . . . . .
5.10.1 Talk Team-Driven Improvement with Retrospectives
5.11 Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

37
38
38
40
40
41
41
42
42
42
43
43
44
45
45
45
46
46
47
47
48

6 Scrum Test
6.1 The Product Backlog is ordered by: . . . . . . . . . . . . . . . . . . . . . . .
6.2 The three pillars of empirical process control are: . . . . . . . . . . . . . . .
6.3 It is mandatory that the product increment be released to production at
the end of each Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Who should know the most about the progress toward a business objective or a release, and be able to explain the alternatives most clearly? . . .
6.5 Which two (2) things does the Development Team not do during the first
Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Who is on the Scrum Team? . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Scrum Master is a management position? . . . . . . . . . . . . . . . . . .
6.8 The Development Team should have all the skills needed to . . . . . . . .
6.9 An optimal Development Team has at least 5 members . . . . . . . . . . .
6.10 When multiple teams are working together, each team should maintain a
separate Product Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11 What is the recommended size for a Development Team (within the Scrum
Team)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.12 When many Development Teams are working on a single product, what
best describes the definition of done? . . . . . . . . . . . . . . . . . . . .
6.13 When does the next Sprint begin? . . . . . . . . . . . . . . . . . . . . . . . .
6.14 Which statement best describes the Sprint Review? . . . . . . . . . . . . .
6.15 Development Team members volunteer to own a Sprint Backlog item: . .
6.16 When is a Sprint over? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.17 What does it mean to say that an event has a timebox? . . . . . . . . . . . .
6.18 What is the primary way a Scrum Master keeps a Development Team
working at its highest level of productivity? . . . . . . . . . . . . . . . . . .

49
49
49
49
50
50
50
50
51
51
51
51
52
52
52
52
53
53
53

6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
6.31
6.32

6.33
6.34
6.35

6.36
6.37
6.38
6.39
6.40
6.41
6.42
6.43
6.44
6.45
6.46
6.47
6.48
6.49
6.50
6.51
6.52
6.53

Who is required to attend the Daily Scrum? . . . . . . . . . . . . . . . . . .


Who has the final say on the order of the Product Backlog? . . . . . . . . .
Development Team membership should change: . . . . . . . . . . . . . . .
Which statement best describes Scrum? . . . . . . . . . . . . . . . . . . . .
The CEO asks the Development Team to add a very important item to
the current Sprint. What should the Development Team do? . . . . . . . .
Which of the below are roles on a Scrum Team? . . . . . . . . . . . . . . . .
Upon what type of process control is Scrum based? . . . . . . . . . . . . .
Scrum does not have a role called project manager. . . . . . . . . . . . .
Which statement best describes a Product Owners responsibility? . . . . .
An abnormal termination of a Sprint is called when? . . . . . . . . . . . . .
What is the main reason for the Scrum Master to be at the Daily Scrum? .
What is the maximum length of a Sprint? . . . . . . . . . . . . . . . . . . .
How much work must a Development Team do to a Product Backlog item
it selects for a Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Development Team should not be interrupted during the Sprint. The
Sprint Goal should remain intact. These are conditions that foster creativity, quality and productivity. Based on this, which of the following is
false? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
It is mandatory that the product increment be released to production at
the end of each Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Who is responsible for registering the work estimates during a Sprint? . .
An organization has decided to adopt Scrum, but management wants to
change the terminology to fit with terminology already used. What will
likely happen if this is done? . . . . . . . . . . . . . . . . . . . . . . . . . . .
The timebox for a Daily Scrum is? . . . . . . . . . . . . . . . . . . . . . . .
The timebox for the complete Sprint Planning meeting is? . . . . . . . . . .
The purpose of a Sprint is to have a working increment of product done
before the Sprint Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Development Team should have all the skills needed to: . . . . . . . .
Why is the Daily Scrum held at the same time and same place? . . . . . . .
The maximum length of the Sprint Review (its timebox) is: . . . . . . . . .
During the Daily Scrum, the Scrum Masters role is to: . . . . . . . . . . . .
What is the role of Management in Scrum? . . . . . . . . . . . . . . . . . .
What is more important objective of the Backlog Refinement Meeting? . .
Whats the difference between acceptance criteria and definition of done?
Whats the difference between the Product Backlog and the Sprint Backlog?
Should the team expect to know all the tasks necessary to complete the
committed PBIs during the Sprint Planning Meeting? . . . . . . . . . . . .
What is the longest allowable iteration, or Sprint, in Scrum? . . . . . . . .
In Scrum, is it acceptable to postpone testing until another Sprint? . . . . .
How can one Scrum team builda potentally shippable product increment
within one Sprint? (Chose six) . . . . . . . . . . . . . . . . . . . . . . . . . .
A 30-day Sprint uses a 1-day timebox for the Sprint Planning Meeting.
How long should the Sprint Planning Meeting be for a two-week Sprint? .
To avoid technical debt, what should the team write down in their definition of done? (Choose seven) . . . . . . . . . . . . . . . . . . . . . . . . . .
Do you agree the PBI will need some testing tasks? . . . . . . . . . . . . .

53
54
54
54
54
55
55
55
55
55
56
56
56

56
57
57

57
58
58
58
58
59
59
59
59
60
60
60
60
60
61
61
61
61
62

6.54
6.55
6.56
6.57
6.58
6.59
6.60
6.61
6.62
6.63
6.64

6.65
6.66
6.67
6.68
6.69
6.70
6.71
6.72
6.73
6.74

6.75
6.76
6.77
6.78
6.79
6.80
6.81
6.82
6.83
6.84
6.85
6.86
6.87

Who is responsible for committing to work in the Sprint Planning Meeting?


Which is a better measure of progress? . . . . . . . . . . . . . . . . . . . . .
How many Sprints are planned during a Sprint Planning Meeting? . . . .
Who must attend the Sprint Planning Meeting? (Choose three) . . . . . . .
What does a Scrum Team attempt to do during its very first Sprint? . . . .
Which of the following are true regarding Product Backlog Items (PBIs)
and tasks? (Choose four) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Which of the following are explicitly defined questions in the Daily Scrum
Meeting?(Choose three) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Is TDD part of Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Daily Scrum is one technique to encourage team collaboration. Which
physical arrangement encourage collaboration the most? . . . . . . . . . .
What is a good size for a Sprint task? . . . . . . . . . . . . . . . . . . . . . .
During the Sprint Execution, a Scrum Team uses information radiators
such as the taskboard or sometimes a Sprint Burndown Chart. Who are
these for? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In an organisation that embraces Agile values, who would be responsible
for tool selection and configuration? . . . . . . . . . . . . . . . . . . . . . .
When is Sprint execution completed? . . . . . . . . . . . . . . . . . . . . . .
Whats the first thing we should see at the Sprint Review Meeting? . . . .
When were the PBIs committed to the Sprint? . . . . . . . . . . . . . . . . .
To whom should the stakeholder direct his complaint about priorities? . .
Does Scrum have a concept of a partially done PBI? . . . . . . . . . . . .
When should a PBI be considered done? . . . . . . . . . . . . . . . . . . . .
What should a PO usually do with a partially complete PBI? . . . . . . . .
Whats a good use for velocity? . . . . . . . . . . . . . . . . . . . . . . . . .
Henry Ford discovered the more adapted you become to an unchanging
situation, the less adaptable you are. In an unvertain world, which is a
wiser area for a ScrumMaster to focus on? . . . . . . . . . . . . . . . . . . .
Is restrospective safety enhanced by inviting outside spectators who werent working on the team? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Is a safety check by itself a complete Sprint Retrospective? . . . . . . . . .
In Scrum, how often is the Sprint Retrospective Meeting conducted? . . .
Groups often fool themselves with pseudo-solutions that dont really
change anything. Which of the following are more effective? (Choose three)
Which of the following best describes the approach for determining the
iteration (timebox) length? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Who is responsible for prioritizing the product backlog? . . . . . . . . . .
What are the advantages of maintaining consistent iteration (timebox)
length throughout the project? . . . . . . . . . . . . . . . . . . . . . . . . .
Why is it important to trust the team? . . . . . . . . . . . . . . . . . . . . .
An effective workshop facilitator will always ... . . . . . . . . . . . . . . . .
If a timebox (iteration) plan needs to be reprioritised in a hurry, who
should re-prioritise? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is the effect of having a large visible project plan on a wall? . . . . .
How should work be allocated to the team in an Agile project? . . . . . . .
What should the developers do if the customer representative is repeatedly too busy to be available? . . . . . . . . . . . . . . . . . . . . . . . . . .

62
62
62
63
63
63
63
64
64
64

64
64
65
65
65
65
65
66
66
66

66
66
67
67
67
67
68
68
68
68
69
69
69
69

6.88 Which one of the following is an important feature of the daily stand-up
/ wash up / Scrum meeting? . . . . . . . . . . . . . . . . . . . . . . . . . .
6.89 Who should attend the stand-up meetings? . . . . . . . . . . . . . . . . . .
6.90 One of the development stages you would expect to see a team go through
is: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.91 When estimating is done for a project, the developers should: . . . . . . .
6.92 During an iteration (sprint) (timebox) the developers should be: . . . . . .
6.93 The Agile Manifesto states the following values: . . . . . . . . . . . . . . .
6.94 A sustainable pace means ... . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.95 A burn-down chart shows ... . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.96 The reason for holding regular Retrospectives is: . . . . . . . . . . . . . . .
6.97 How could maintainability of the developing product be improved in a
development team? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.98 Agile methods are described as adaptive because... . . . . . . . . . . . .
6.99 What is one difference in responsibility between a Project Manager and a
Scrum Master (Team Leader) in an Agile project? . . . . . . . . . . . . . . .
6.100The responsibilities of a Product Owner will include ... . . . . . . . . . . .
6.101What is the goal of a Sprint Retrospective? Please select the option(s) that
NOT adhere to the purpose of this important Scrum meeting: . . . . . . .
6.102The Product Owner role and Scrum Master role are never included in the
Development Team size count. . . . . . . . . . . . . . . . . . . . . . . . . .
6.103Scrum allows for re-estimating tasks based on growing insight. Which
Scrum team member is responsible for updating the estimates of the work
during a Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.104Timeboxing is an important principle of Scrum. What is the exact meaning of a meeting having a time-box? . . . . . . . . . . . . . . . . . . . . . .
6.105Resolving internal conflicts is NOT the responsibility of the Development
Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.106What is NOT an attribute of the Development Team? . . . . . . . . . . . .
6.107One of the benefits from Scrum is that the Development Team doesnt
have to write detailed specifications anymore. . . . . . . . . . . . . . . . .
6.108What are the major properties of a cross-functional Development Team?: .
6.109A Scrum team thought it a good practice to clearly define a checklist of
items that must be completed before calling a story completed. What
artifact are they likely to be using for this? . . . . . . . . . . . . . . . . . . .
6.110A Sprint just concluded and it was a disaster. None of the planned stories
completed and the review had to be cancelled. Senior management wants
to establish accountability for this. Who is ultimately accountable for the
success or failure of a Scrum team? . . . . . . . . . . . . . . . . . . . . . . .
6.111A team member from a Scrum team feels that a senior technical architect
from another team may have some valuable insights and feedback about
the product. Which is the best forum to solicit such feedback? . . . . . . .
6.112At the end of each working day, the team members update the number of
hours remaining on the tasks on a white board. The Scrum Master then
sums up the hours and plots them on a chart. What is the name of this
chart? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.113How long should it take a five member Scrum team to finalize the Sprint
plan for a three week Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . .

70
70
70
70
71
71
71
71
72
72
72
72
73
73
73

73
74
74
74
74
75

75

75

75

76
76

6.114A Scrum team realizes that it may be late in delivering a component that
another Scrum team is waiting for. What is the best forum to discuss this
issue and find a resolution? . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.115What is an assertion of the Agile manifesto? . . . . . . . . . . . . . . . . . .
6.116What is the best way to improve communications in a distributed Scrum
team? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.117What is the best time to refactor code on a project? . . . . . . . . . . . . . .
6.118In the past eight Sprints, the team has completed 85 story points worth
of work altogether. The team has been asked to start working on a new
project which is estimated at 64 story points. How many Sprints would
be needed to complete this project? . . . . . . . . . . . . . . . . . . . . . . .
6.119Whats the primary goal of Agile development? . . . . . . . . . . . . . . .
6.120The correct sequence of events in using Scrum framework is as follows: .
6.121Who is the most important member of the Scrum Team? . . . . . . . . . .
6.122Who has the authority to change or cancel a Sprint? . . . . . . . . . . . . .
6.123If the Team determines that it has overcommitted itself for a Sprint, who
should be present when reviewing and adjusting the Sprint goal and work?
6.124Which of the following processes reflects Agile Development? . . . . . . .
6.125What does the Sprint Backlog consist of? . . . . . . . . . . . . . . . . . . . .
6.126What happens when the Sprint is cancelled? . . . . . . . . . . . . . . . . .
6.127What does the BurnDown Chart represent? . . . . . . . . . . . . . . . . . .
6.128What is the Time-box for the Sprint Retrospective? . . . . . . . . . . . . . .
6.129Which statement is an incorrect assessment of the Product Owner? . . . .
6.130When should the Product Owner ship or implement a Sprint increment? .
6.131How much work must a Scrum Team do to a Product Backlog it selects
for a Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.132The Scrum Team is most productive if it is not interrupted during a Sprint.
As a result of... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.133What is the best term to define the function of the ScrumMaster? . . . . .
6.134When is a Sprint over? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.135What part of the Sprint Backlog is used for the Sprint burndown chart? . .
6.136Which objectives are covered as part of Sprint Planning? . . . . . . . . . .
6.137If the product effort is estimated to be 1000 hours, what is the time that is
recommended for release planning. . . . . . . . . . . . . . . . . . . . . . . .
6.138Assuming a 2-week Sprint, What is the Time-box for the Sprint Review? .
6.139Drawing a trend line from previous completed work on a release burndown chart indicates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.140What is the Release Burndown? . . . . . . . . . . . . . . . . . . . . . . . . .
6.141Who determines when it is appropriate to update the Sprint Backlog during the Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.142The following artifacts are critical to the success of Agile Development: . .
6.143What happens when the Sprint is cancelled? . . . . . . . . . . . . . . . . .
6.144More than one Scrum Team is working on a single project or release. How
should the Product Backlog be arranged? . . . . . . . . . . . . . . . . . . .
6.145What is the primary responsibility of the ScrumMaster? . . . . . . . . . . .
6.146What are the two primary ways a Scrum Master keeps a Development
Team working at its highest level of productivity? . . . . . . . . . . . . . .
6.147The Product Backlog is ordered by: . . . . . . . . . . . . . . . . . . . . . . .

76
77
77
77

77
78
78
78
78
79
79
79
79
80
80
80
80
81
81
81
81
82
82
82
82
83
83
83
83
84
84
84
84
85

6.148The length of a Sprint should be: . . . . . . . . . . . . . . . . . . . . . . . .


6.149Who is responsible for managing the progress of work during a Sprint? . .
6.150The Development Team should not be interrupted during the Sprint. The
Sprint Goal should remain intact. These are conditions that foster creativity, quality and productivity. Based on this, which of the following is
FALSE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.151When many Development Teams are working on a single product, what
best describes the definition of done? . . . . . . . . . . . . . . . . . . . .
6.152Who should know the most about the progress toward a business objective or a release, and be able to explain the alternatives most clearly? . . .
6.153What is the role of Management in Scrum? . . . . . . . . . . . . . . . . . .
6.154Which two (2) things does the Development Team do during the first Sprint?
6.155When might a Sprint be abnormally terminated? . . . . . . . . . . . . . . .
6.156The CEO asks the Development Team to add a very important item to
a Sprint that is in progress. What should the Development Team do? . . .
6.157Sprint Backlog is ultimately owned by . . . . . . . . . . . . . . . . . . . . .
6.158During a Scrum of Scrums approach for a project, what best defines the
definition of done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.159The used metric to estimate with Planning Poker is . . . . . . . . . . . . .
6.160What are the most critical items to start a Scrum Project? . . . . . . . . . .
6.161During a Sprint, when is a new work or further decomposition of work
to be added to the Sprint Backlog? . . . . . . . . . . . . . . . . . . . . . . .
6.162What is the BEST length of an iteration in Scrum? . . . . . . . . . . . . . .
6.163Items in the Product Backlog tend to be: . . . . . . . . . . . . . . . . . . . .
6.164What are the critical items to start a Scrum Project? . . . . . . . . . . . . . .
6.165What is the ultimate goal of the Scrum Team? . . . . . . . . . . . . . . . . .
6.166Who defines the Sprint Backlog scope? . . . . . . . . . . . . . . . . . . . . .
6.167What is the major difference between Product Backlog and Sprint Backlog?
6.168The maximum duration of the Sprint is highly recommended to be. . . . .
6.169As the Sprint planning progresses, the workload has grown beyond the
teams capacity. Which action makes most sense for the Team? . . . . . . .
6.170What does it mean to say that an event is timebox? . . . . . . . . . . . . . .
6.171Which of the following statement are true about the Daily Scrum Meeting:
6.172Which of the following statements are true for the Product Backlog. . . . .
6.173When should the Sprint Retrospective be held? . . . . . . . . . . . . . . . .
6.174Whats the primary goal of Agile development? . . . . . . . . . . . . . . .
6.175The Sprint Burndown charts are an efficient tracking tool because they
show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.176When is a Product Backlog item considered complete? . . . . . . . . . . . .
6.177The responsibility to remove impediments that will prevent the team from
accomplishing the over all objective of the sprint is? . . . . . . . . . . . . .
6.178Which statement is an incorrect assessment of the Scrum Team? . . . . . .
6.179Which statement is an incorrect assessment of the Scrum Master? . . . . .
6.180Drawing a trend line from previous completed work on a release burndown chart indicates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.181What is the Release Burndown? . . . . . . . . . . . . . . . . . . . . . . . . .
6.182Who is ultimate responsible for the Product Backlog item estimates? . . .

85
85

85
86
86
86
86
87
87
87
87
88
88
88
88
89
89
89
89
90
90
90
90
91
91
91
92
92
92
92
93
93
93
93
94

6.183When many Scrum Teams are working on a project, what best describes
the definition of done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.184When many Scrum Teams are working on the same product, should all
of their increments be integrated every Sprint? . . . . . . . . . . . . . . . .
6.18515. Whats the Scrum Team definition of Done? . . . . . . . . . . . . . .
6.186Which of the following statements are true about the Sprint? . . . . . . . .
6.187What is the Sprint Burndown? . . . . . . . . . . . . . . . . . . . . . . . . . .
6.188For a one month Sprint, how much time should be dedicated for the
Sprint Planning Activity? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.189The purpose of the Sprint Retrospective is to review the following items .
6.190Which statement best describes the Sprint Review? . . . . . . . . . . . . .
6.191What is the ultimate goal of the Scrum Team? . . . . . . . . . . . . . . . . .
6.192Which statement is an incorrect assessment of the Product Owner? . . . .
6.193How much work must a Scrum Team do to a Product Backlog it selects
for a Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.194The Scrum Team is most productive if it is not interrupted during a Sprint.
As a result of... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.195What is the unit of measure that is used by the Scrum Team in estimating
Product Backlog items? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.196What best describes the Scrum Team Characteristics? . . . . . . . . . . . .
6.197What part of the Sprint Backlog is used for the Sprint burndown chart? . .
6.198The Sprint Backlog is owned by? . . . . . . . . . . . . . . . . . . . . . . . .
6.199Who determines when it is appropriate to update the Sprint Backlog during the Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.200When multiple teams work together on the same product, each team
should maintain a separate Product Backlog. . . . . . . . . . . . . . . . . .
6.201The purpose of a Sprint is to produce a done increment of working product.
6.202The time-box for the Sprint Planning meeting is? . . . . . . . . . . . . . . .
6.203It is mandatory that the product increment be released to production at
the end of each Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94
94
94
95
95
95
95
96
96
96
96
97
97
97
97
98
98
98
98
98
99

7 Unsorted

104

8 Workshop Ideen

105

1 Scrum
1.1 Fakten
Essentials: Das Team organisiert sich selbst, macht einen realistischen Plan, koordiniert
den taglichen Fortschritt und lost Probleme und macht das alles in einem wiederkehrenden
Zyklus.
1.1.1 Probleme der Softwareentwicklung
Auslieferung und Produktivnahmen dauern zu lange
Stabilisierung dauert zu lange

Anderungen
sind schwer einzubringen
Qualitat und Moral durch Todesmarsche

Abbildung 1.1: Stacy Landscape Model: Complicated (Ursache Wirkung klar), Complex (Hinterher ist man immer schlauer; Effektivitat wichtiger als Effizienz)

1.1.2 Was ist Scrum


inkrementelle Produktentwicklung unter Ver ist ein Management-Framework fur

wendung von einem oder mehreren cross-funktionalen, selbstorg. Team. Es ist fur
adaptive komplexe Probleme geeignet, wahrend die Produktivitat und Kreativitat

Produkte mit hochst-m


oglichen
Nutzen ausliefert

gibt Rollen, Meetings und Artefakte vor


Scrum hat fixe Iterationen (zwei Wochen oder max 30 Tage), in denen versucht
wird ein potentiell auslieferbares Produktinkrement zu erstellen
ist ein empirischer1 . Prozess, da in der heutigen Zeit die Anforderungen und die
einen vorhersehbaren Ausgang
Technologie d.h. es ist zu kompliziert fur
Inspect und adapt wird durch Sprint Planning, Daily Scrum, Sprint Review und
Retro (sind Scrum Events) abgedeckt
1.1.3 Essens von Scrum
Team erhalt klare vorgegebene Ziele
Team organisiert sich um die Arbeit selbst
Team liefert regelmaig wertvolle Funktionalitaten
Team erhalt Feedback von der Auenwelt
Team reflektiert seine Arbeitsweisen, um sich zu verbessern

Team und Management kommunizieren ehrlich uber


den Fortschritt und Risiken
sobald man vom Scrum-Weg abweicht, dann muss man sich bewusst sein, was
Auswirkungen hat und das dann einige Sachen von Scrum nicht mehr
das fur
funktionieren
1.1.4 Scrum Werte und Umsetzung (Prinzipien)
Scrum Werte

Fokus : eine Aufgabe losen,


d.h. arbeiten gut zusammen und erzeugen

exzellente Arbeit liefern fruher


wertvolle Ergebnisse

Mut : haben mehr Ressourcen, da wir uns in einer Gruppe unterstutzen

und haben dadurch Mut, groere


Herausforderungen anzugehen (wir lernen aus Fehlern 2 )
Offenheit : wir besprechen wie wir vorgehen und was uns im Weg steht,

wir a uern Bedenken, so dass diese adressiert werden konnen


schafft Vertrauensbasis3
1 Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

Three pillars uphold every implementation of empirical process control: transparency (Scrum Artefakte
alle sichbtar), inspection (Scrum Artefakte checken und den Fortschritt zum Sprint-Ziel checken), und
fur
adaptation (wenn ein oder mehrere Aspekte vom akzeptierbaren Ma abweichen, dann ist das herauskommende Produkt nicht mehr akzeptable, Prozess oder zu bearbeitende Material muss schnell angepasst
werden, damit weitere Abweichung minimiert wird)
2 hoher

Leute in der Hierarchie muss es vorleben, dass man Fehler gemacht werden (man darf auch welche
machen)
3 besser als streng auf den Vertrag zu gucken

10


Selbstverplfichtung : haben Kontrolle uber
unser eigenes Schicksal und dadurch wachst
unsere Selbstverpflichtung zum Erfolg herauskommen; wir denken, dass wir es schaffen.
Respekt : wenn wir zusammenarbeiten und Erfolge und Misserfolge teilen,
dann respektieren wir uns gegenseitig und helfen einander4
Prinzipien
1. empirisches Management: wird durch transparancy, inspect & adapt5 umgesetzt
2. autonomes, selbstorganisiertes6 , Cross-funktionales Team
3. ROI-Fokus: stiften am Sprint-Ende einen Kundennutzen (Value-based Priorisation)

4. timeboxing: alle Schritte im Prozess sind zeitlich beschrankt und mussen


bis dahin
auch fertig sein, z.B. Sprintlange, Retro usw. man soll sich die Zeit nehmen und die
wichtigsten Termine durchgehen und erst dann einen Prozess abschaffen/andern,
wenn man Ihn wenigstens ausprobiert hat.

5. Pull Prinzip7 : Verantwortungsubernahme,


d.h. Nimm dir eine Sache, die du auch

erledigen kannst Verantwortung kann man nicht aufdrucken,


wenn man sich
fuhlt.

nicht verantwortlich dafur


6. Potentiell auslieferbare Produktinkrement
1.1.5 Warum schweigt Scrum u
ber Softwareentwicklungs-Praktiken?

Scrum erwartet von Teams, dass sie alle erforderliche tun, um das gewunschte
Produkt zu liefern es ermachtigt die Teams dazu
Entwicklungspraktiken und Werkzeuge sind standigen unterworfen
1.1.6 Selbstorganisation
hyperproduktive Teams)
selbstorg. Teams sind hoch diszipliniert8 ( Grundlage fur

die
erhalten volle Autonomie und tragen damit eine hohere
Verantwortung fur

Ubereinstimmung der Lieferung mit ihren eigenen Versprechen.


ermutigt, absehbare Risiken einzugehen und durch Fehlschlage und Selbstreflexion zu lernen
Fragen zur Selbtsorg.:
Pflichtmeeting
4 menschlicher

Umgang kann man gut im Teamvertrag regeln


ist ein sehr wichtiges Element, um auf Dauer auf Verande
rungen reagieren zu konnen.
6 w
ahlen aus, wie sie am besten ihre Arbeit umsetzen, als sich von auen Befehle geben zu lassen
7 nicht uberlasten

und arbeite von oben nach unten durch (Akzeptierte Verantwortung aus XP)
8 eines hohes Ma an Vertrauen und hohe Verbindlichkeit sind automatische Resultate von wirklich
selbstorg. Teams

5 Kleine Zyklen und gucken dann, wo ich bin

11

IT-Update/Review
Community of Practice (CoP)
zu viele Abhangigkeiten

Prioritaten Wechsel ohne Begrundung


Projektleitung vs. Verantwortlichkeit
Technische Limitierung (Betriebssystem)
hohe Selbstorg. vs. Command & Conquor Transparenz schaffen
Gewohnheiten vs. Hinterfragen

1.2 Manifesto der Agilen Softwareentwicklung


Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen
dabei helfen, es zu tun. Durch diese Arbeit schatzen wir:
Individual and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following plan

wahrend wir den Wert der Dinge auf der rechten Seite sehen, schatzen wir die Dinge
auf der linken Seite als wichtiger ein.

1.3 Prinzipien hinter dem Agilen Manifest

und kontinuierli1. Unsere hochste


Zielsetzung ist es, den Kunden durch die fruhe
che Lieferung wertvoller Software zufrieden zu stellen.
Anforderungsanderungen, auch spat in der Entwicklung. Agile Prozesse
2. Begrue
den Wettbewerbsvorteil des Kunden.
nutzen den Wandel fur

3. Liefere haufig funktionierende Software eher in kurzeren


Zeitraumen.

4. Geschaftsleute und Entwickler mussen


taglich im Projekt zusammen arbeiten.

5. Baue Projekte um motivierte Individuen. Gib ihnen die Umgebung und Unterstutzung,
die sie brauchen, und traue ihnen zu, den Job zu erledigen.
6. Die effizienteste und effektivste Art der Informationsweitergabe an und in einem
Entwicklungsteam ist die Konversation von Angesicht zu Angesicht.
Fortschritt.
7. Funktionierende Software ist das primare Ma fur

8. Agile Prozesse fordern


nachhaltige Entwicklung. Die Sponsoren, Entwickler und

Benutzer sollten ein gleichbleibendes Tempo ohne Unterbrechung einhalten konnen.


9. Die fortwahrende Beachtung von technischer Exzellenz und gutem Design verbessert die Agilitat.

12

10. Einfachheit - die Kunst der Maximierung von nicht angegangener Arbeit - ist essentiell.
11. Die besten Architekturen, Anforderungen und Designs entstehen in sich selbst
organisierenden Teams.

12. In regelmaigen Intervallen reflektiert das Team daruber,


wie es effektiver werden
kann, und passt dann dein Verhalten entsprechend an.

1.4 Rollen
keine Projektleiter-Rolle in Scrum
Verantwortlichkeiten des traditionellen Projektleiters sind auf die drei Rollen (Product Owner (PO), ScrumMaster (SM), das Entwicklungs-Team) im Scrum Team aufgeteilt
1.4.1 Das Scrum Team
besteht aus PO, Entwicklungs-Team und Scrum Master (SM)
Cross-funktionale Gruppe9 und selbstorg.
versucht ein potential auslieferbares Produkt-Inkrement jeden Sprint zu liefern10
geschafftes zu maximieren
und versuchen, Feedback furs
Teams reprasentieren multilearning11
verhandelt Commitments zum Sprint mit PO und legen so den scope des Sprint
Backlogs fest
von Backlog-Eintragen
Schatzen der Groe
hat Autonomie wie die Commitments erreicht werden
7 +- zwei Mitglieder

Teammitglieder konnen
Entwickler, Tester, Analysten, Architekten, Autoren, Designer und Benutzer sein
1.4.2 Product Owner
Metapher: Product Owner (PO) ist ein CEO
die gemeinsame Produktvision verantwortlich
ROI Maximierung12 und fur
9 hat

alle Fachkrafte, um ein fertiges Produktinkrement am Ende eines Sprints lauffahig zu haben ohne
dabei von Personen auerhalb des Entwicklungsteam abhangig zu sein
10 ultimative Aufgabe, die Anforderungen des POs im Sprint Backlog in ein potentiel auslieferbares Produktinkrement zu wandeln
11 d.h. jeder hat seine spezielle St
arken, aber es werden auch Aufgaben in Bereichen erledigt, in denen sie
nicht so weit bewandert ist
12 kann auch erreicht sein, wenn Stakeholder nicht heulen

13

Produktbacklog (PB) pflege13 :


klar formulierte Eintrage
ordnet PBI so an, dass sie die Ziele am besten erreichen

optimiert den Wert der Arbeit, die das Entwickler Team ausfuhrt
stellt sicher, dass das Produktbacklog sichtbar, transparent und soll darstellen, woran das Scrum-Team als nachstes arbeitet

Leute die eine Anderung


an der Prio im Backlog haben wollen, sollen sich nur an
den PO wenden
Repriorisiert und verfeinert das Produktbacklog
Anforderungs-Losungen

finaler Entscheider fur


akzeptiert oder lehnt Produktinkrement ab14
ist ein Person und kein Komitee (single point of failure)
Devs
ist ein Anforderungsfilter fur
bedenkt die Interessen der Stakeholder
die Entstehung des
ist die wichtigste Person im Scrum-Team, weil er der Grund fur
Scrum-Teams ist
kann als Team Mitglied helfen
1.4.3 Das Entwicklungs-Team
sind Profis, die die Arbeit zur Auslieferung eines potentiell auslieferbaren Inkre
ments unter der Einhaltung von done liefern konnen
das Projekt komplett zur Verfugung

sind selbstorg.15 und Mitglieder sollen fur


stehen
entscheiden, wie viel Arbeit in einem Sprint passt

nur das Entwicklungs-Teams durfen


das Produkt-Inkrement erstellen
Synergien optimieren die Team-Effektivitat und Effizienz
sind Cross-funktional16
Mitglieder des Entwicklungs-Teams zu17
keine anderen Titel auer Entwickler fur
13 entweder

rechenschaftspflichtig;
PO oder Entwicklungs-Team kummern
sich darum, aber PO ist dafur
Hol- und Bringschuld liegt bei Ihm, das Backlog transparent zu halten
14 entscheidet wann ausgeliefert werden soll und ob die Entwicklung fortgesetzt werden soll; im besten Fall
sollte nach jedem Sprint ausgeliefert werden
15 niemand (auch nicht der SM) sagt ihnen, wie sich ein PBI zur Auslieferung fertigstellen sollen
16 funktionsubergreifende

Gruppe von Menschen, die zusammen alle erforderlichen Fahigkeiten besitzen,


um jedes Produktinkrement zu liefern
17 sonst ver
andern sich die Verantwortlichkeiten

14

Scrum lasst keine Sub-Teams zu (auch nicht durchs Testen, Business Analysts)
Individuelle Starken im Team sind vorhanden, aber die Verantwortlichkeit liegt
auf dem ganzen Team
Groe:

<= 3 und <= 9 (PO und SM zahlen nicht in diese Rechnung, es sei denn
sie arbeiten auch im Sprint mit)18
1.4.4 Scrum Master
Metapher: Scrum Master (SM) ist ein Moderator, Coach, Mentor und Bulldozer!
Scrum-Team
ist servant-leader19 furs

stellt sicher, das Scrum verstanden und durchgefuhrt


wird
wichtigste Aufgabe: zeige Rollen Ihre Verantwortlichkeiten
raumt Impediments aus dem Weg20
erleichtert und halt den Scrum Prozess in Bewegung21

fordert
die Erstellung einer Umgebung zur Selbstorg.
sammelt empirische Daten, um Vorhersagen besser anzupassen

beschutzt
das Team von externen Einflussen
und Ablenkungen/Unterbrechungen, damit das Team im Flow bleibt
hilft Leuten auerhalb des Scrum-Teams welcher Ihre Interaktionen mit dem Team
hilfreich und welche es nicht sind
achtet auf timeboxing
halt Scrum-Artefakte sichtbar

fordert
erweiterte Engineering Practices
hat keine Projekt-Manager Rolle22
hilft der Produkt Gruppe beim Scrumlernen und wie man Scrum anwendet, um
die Geschaftsziele zu erreichen

werden
Probleme sollen wann immer moglich
vom Team gelost
unterstutzt

PO:
Techniken zum Effektiven PB Management
18 Team

sollte so gro sein, dass es von einer groen Pizza satt wird
zu, ist empathisch und gibt Einsichten, wahrend er Macht und Authodienende Fuhrungsperson:

hort
ritat im Team teilt
20 extern: z.B. fehlende Unterstutzung

durch anderes Team; intern: wenn PO nicht weit, wie er das PB


richtig vorbereiten soll
21 macht das alles ohne Management, wobei er eine Management-Rolle fur
den Scrumprozess hat
22 jeder mit Autorit

at ubers
Team ist per Definition kein SM
19 eine

15


Scrum-Team Verstandnis geben, warum PBIs klar und genau sein mussen
verstehen, das Produkt Planung ein empirischer Prozess ist
sicherstellen, das PO wei, wie man das PB mit maximalen Nutzen angeordnet sein soll
agile Praktiken verstehen und anwenden
teilnehmen an Scrum-Events, sofern es notwendig ist

Entwicklungs-Team:
unterstutzt
coached Team zu selbstorg. und Cross-Funktionalitat
hilft dem Team hochwertige Produkte herzustellen durch Einsatz von technischen Praktiken
Impediments entfernen, die das Entwicklungsteam aufhalten
coach zum Scrum-lernen
teilnehmen an Scrum-Events, sofern es notwendig ist
unterstutzt

die Org:

planen, leiten und coachen der Scrum-Einfuhrung


hilft Angestellten und Stakeholder Scrum zu verstehen und das Scrum nun
vorgeschrieben ist und empirische Produkt-Entwicklung ist

Anderung
herbeifuhren,
die die Produktivitat des Scrum-Teams erhoht
arbeitet mir anderen SMs zusammen, um die Effektivitat von Scrum in der

Org zu erhohen

1.5 Sch
atzen
zu bekommen, wie viel Sie schaffen konnen,

Team schatzt, um ein Gefuhl


es nutzt
den PO tun kann.
nix, was man nur fur

Schatzen ohne Erfahrungen ist schwierig z.B. die Schatzungen uber


verschie
dene Staaten, wie oft darin ein Land von der Groe
Deutschlands reinpassen
23

wurde
ist in Agiler Entwicklung weniger wichtig als in traditioneller Entwicklung
wenn man das Produkt in kleine auslieferbare Zustande halt, dann wird die Arbeit
stets so herumpriorisiert
manche Teams benutzen einfaches Schatzen: Alles ist entweder Small oder wird

in kleinere Stucke
heruntergebrochen
Bucket-Schatzung/Magic Estimation
eine groe Menge an Stories
eignet sich fur

gut Einsortierung in bestimmte Story-Cluster Groen


und konnen
auch helfen, zu
groe Stories in weitere kleinere Stories aufzubrechen od. aber ein weite Stories
ergeben sich
23 w
ahrend

der Ubung
anstelle von Landern in km2 geschatzt, ware es noch viel schwieriger geworden

16

ist nur eine grobe Schatzung


ist gut beim initialen Aufsetzen des Backlogs

Warum abstrakte Groen?

Stehen jeweils in Relation uber


den absoluten Wert,
z.B. XXL, XL, L, M, S, XS; sind anpassbar; Grundrauschen hat man dabei und
jeden anders; es ist okay, wenn es Ausreiser gibt, aber wenn es
schatzen ist fur
diese andauernd gibt, dann sollte man Anpassungen vornehmen
Schatzpoker: wird beim SP verwendet
verdecktes Schatzen
gemeinsames Aufdecken
1 vs 8 geschatzt wenn ich Experte bin, heit es nicht, dass man an alles
denkt, deswegen ist es gut wenn Abweichungen im Team hat; man lasst sich
auf Teamschatzung vs. Einzelschatzung ein
Teamschatzungen verhindern Aufbau von Wissensinseln
gemeinsames Verstandnis

wenn Management etwas mochte,


von dem man keine Ahnung hat, dann
kann man Experte rufen od. 1-2 Wochen Recherche machen

L od. M solche als Stories geschatzten Groen


bedeuten, dass die Story
sehr komplex ist und man ein groes Risiko hat.

17

2 Scrum Ereignisse/Scrum Meetings


bestehen aus Sprint, Sprint Planning, Daily Scrum, Sprint Review und
Sprint Retrospective
richtige Reihenfolge: Release Planning, Sprint Planning, Sprint, Daily Scrum, Sprint
Review, and Sprint Retrospective
sollen regelmaig stattfinden und die Anzahl der Meetings, die nicht in Scrum
definiert sind, zu minimieren
alle Events sind timeboxed, d.h. jedes Ergeignis hat eine maximale Dauer
Sprintlange ist fest und wird niemals erweitert24
alle anderen Events ist), hat
anders als der Sprint selbst (welcher ein Container fur

jedes Event die Moglichkeit


zum inspect und adapt. Diese anderen Events wurden
so gestaltet, um kritische Transparenz und Einsicht zu gewahren. Wenn eines die dann verliert man Transparenz und dadurch
ser Events nicht seinen Zweck erfullt,

die Moglichkeit
zum inspect und adapt
einen 30-Tage Sprint sind die Timeboxen furs
SP1 und SP2, Review sowie Retro
fur
auf jeweils 4 Stunden angesetzt
an allen Meetings nimmt SM teil, der keine Entscheidungstreffungs-Authoritat hat

wenn Meeting sinnlos ist, dann hofflich


sagen, dass man an der Sache nicht teilhaben kann und dem Meeting keinen weiteren Input mehr liefern kann.
Prisoner of Meeting: ist jemand, der gezwungen wurde, am Meeting teilzunehmen

2.1 Sprint
Sprint ist der Herzschlag des Scrum Zyklus. Er wird markiert durch das Sprint
Planning am Start und Sprint Review und -Retro am Ende
ist timeboxed auf maximal einen Monat oder weniger, in dem ein fertiges (done), nutzbares und potential auslieferbares Produktinkrement erstellt wird
neuer Sprint startet unmittelbar nach Abschluss des vorherigen Sprints
haben am besten eine konstante Dauer
Sprint besteht aus Sprint Planning, Daily Scrums, die Entwicklungsarbeit, dem
Sprint Review und der Sprint Retrospektive
wahrend des Sprints:

das Sprint-Ziel darstellen


keine Anderungen
machen, die eine Gefahr fur

Qualitats-Ziele durfen
nicht herabgesetzt werden
24 andere Events enden, wenn deren Zweck erfullt
ist, wobei entsprechend Zeit dafur
genommen wird ohne

dabei Verschwendung in den Prozess zuzulassen)

18

Scope kann korrigiert und neu verhandelt werden zwischen dem PO und
Entwicklungsteam, wenn mehr Wissen vorhanden ist
Sprint abbrechen:
kann vor Ablauf der timebox nur durch PO geschehen, wobei Stakeholder,

dem Entwicklerteam oder auch SM Einfluss darauf haben konnen

Sprint wurde
abgebrochen werden, wenn:
Sprint-Ziel hat keine Bedeutung mehr
Ausrichtung der Firma hat sich geandert
Technologie hat sich verandert
alle fertiggestellten und als done markieren PBI werden gereviewed. Alle
unfertigen PBIs werden erneut geschatzt und ins Product Backlog gepackt

2.2 Sprint Planning

Zusammenfassung : Scrum Team erarbeitet gemeinsam die zu erledigende Arbeit fur


den kommenden Sprint und versucht diese zu verstehen 25
Teilnehmer : SP 1: PO, Team, SM; SP 2: Team, SM, (PO)
Input : : Scrum-Team, Sprint-Lange, vorherigere Sprint Velocity, schatzte
Stories, Abhangigkeiten, Team-Kalender (Abwesenheiten)
Output : Sprint Backlog, Burndown Chart, Sprint-Ziel
Ziele :

Entwicklungs-Team versteht und definiert zu schaffende Arbeit26


SP1: Team forecast sich zu den PBIs
SP2: Erstellt die Tasks zu den einzelnen PBIs

Fakten :

das ganze Team nimmt teil am Meeting


PO entscheidet, welche PBIs am wertvollsten sind.
SP1 und SP2 ist timeboxed 5% der Sprintzeit und hat eine maximale Lange von insgesamt 8 Stunden fur
einen MonatsSprint27
Sprint-Ziel ist definiert28
SM achtet darauf, dass das Meeting stattfindet und das die
Teilnehmer die Absicht des Meetings verstehen und achtet
auf die Einhaltung der Zeit

25 Teil

1 ist das WAS und Teil 2 ist das WIE

der ersten Halfte wird das Sprint Ziel erstellt (muss man sehr grozugig
sein, da nicht immer alle
involviert sind) und in der zweiten Halfte das Sprint Backlog
27 SP1 und SP2 dauern maximal jeweils 2 Stunden fur
ein zwei Wochensprints, maximal jeweils 1 Stunde
fur
ein Wochensprints
28 ist eine Zielvorstellung die durch Implementierung der PBIs des Sprint erfullt
wird und ist ein Leitfaden
Team, warum gerade genau dieses Inkrement gebaut wird und hilft den Fokus zu wahren und sich
furs
weniger mit kleinen Details aufzuhalten

26 in

19

2.2.1 SP1
ist ein detaillierter Anforderungs-Workshop
PO stellt eine Reihe von angedachten Features vor und das Teams stellt Fragen, um
die Anforderungen in ausreichendem Detail zu verstehen, damit Sie den forecast

abgeben konnen,
das jeweilige Feature im kommenden Sprint zu liefern
Meetings ist Product Backlog, das letzte Produkt-Inkrement, die Team Input furs
und die letzte Leistung des Teams
groe
Team entscheidet alleine, was es in dem Sprint liefern kann29
PO muss wahrend des gesamten Meetings anwesend sein, um das Team in die

richtige Richtung zu fuhren


und Ruckfragen
zu beantworten
SM muss sicherstellen, dass beliebige andere vom Team zum Verstandnis der An
forderungen benotigte
Stakeholder anwesend oder rufbereit sind
die Backlogeintrage, die das Team zur Lieferung zugesagt hat, nennt man Selected
Product Backlog
den laufenden Sprint aufgenommen und noch
evtl. neue Backlog-Eintrage, die fur
nicht geschatzt wurden, werden in diesem Meeting sofort bemessen
am Ende verspricht das Team dem PO die Lieferung einer selbsteingeschatzten
Menge an lauffahigen und getesteten Funktionen
2.2.2 SP2
ist ein Design-Workshop und Team erarbeitet gemeinsam einen Grobentwurf der
versprochenen Funktionalitaten wird auch Sprint Backlog30 genannt
Ergebnis dieser Sitzung ist eine Liste von Aufgaben (tasks), die dann im Sprint
Backlog meist durch ein physisches Task Board dargestellt wird

Tasks variieren in Groe


und Aufwand, sollten jedoch maximal einen Tag oder
weniger zur Fertigstellung dauern
Fragen bereitstehen und die Items eventuell neu verhandeln, wenn
PO muss fur
das Entwicklerteam entdeckt, dass es zu viel oder zu wenig zu tun hat
SM muss sicherstellen, dass der PO sowie weitere Stakeholder zur Klarung von
weiteren Fragen bereitstehen
Entwicklungs-Team hat die Verantwortung, wie die Arbeit getan wird

29 und
30 das

denkt an Sprintdauer, Teamgroe,


DoD, Abwesenheiten sowie Manahmen aus der letzten Retro
Scrum Team ist Besitzer davon; kann wahrend des Sprints nur vom PO geupdated werden

20

2.3 Daily Scrum


Wird auch daily scrum, daily huddle, oder morning roll-call genannt.
Zusammenfassung : Update und Koordination zwischen den Team-Mitgliederr
Teilnehmer : Entwicklungs-Team, (PO), (SM)31 , (andere Stakeholder)32
Input : Entwicklungs-Team, SM, Burndown Chart, Impediment Log, Scrumboard
Output : update Burndown Chart, update Impediment Log, motiviertes

Scrum Team, update Scrumboard, nicht zugestimmte Anderungsw


unsche
Ziele :

jeden Tag zur gleichen Zeit am gleichen Ort treffen, um 15


Minuten lang sich gegenseitig vom aktuellen Stand der Dinge zu informieren33
Antwort auf Fragen: Was habe ich seit letzten Daily erreicht?

Was mochte
ich bis zum nachsten Daily erreichen? Was bremst
meinen Fortschritt?

Unterstutzung
von Verbesserungen

Fakten :

man steht beim Meeting, damit es kurz und knapp ist


kurz, klarende Fragen und Antworten sind angemessen, aber

keine weiterfuhrende
Diskussion dieser Themen

ubergeordnete
Themen mussen
nach dem Daily mit den entsprechenden Personen besprochen werden

man berichtet dem Team gegenuber


nicht irgendeinen Boss
oder Manager34
SM stellt sicher, dass Daily Scrum stattfindet, das alle drei

Fragen beantwortet werden, das alle reden konnen,


timebox
einhalten und leitet Diskussionen

das Entwicklungsteam fuhrt


dieses Meeting
Dinge, die nicht in der Hand des Teams liegen, werden als
organizational impediments bezeichnet
Pair Reporting: wenn man eh den ganzen Tag zusammenhockt, dann kann auch nur einer von beiden sprechen
GIFTS: Good Start, Improvement, Fokus, Team, Status
Good start: sollte Energie geben

Improvement: Konnen
nix reparieren, von dem wir nicht
wissen, dass es ein Problem ist, hat aber nix nur mit Pro
blemlosung
zu tun, sondern auch mit besseren Arbeitsweisen und Ideentausch zu tun

31 ist

anwesend und garantiert, dass das Meeting stattfindet

sich dazu und horen


zu
33 Kommunikation + Synchronisation
34 wenn Boss da ist, dann hindert der invisible gun effect die Selbst-Organisation
32 gesellen

21

Fokus: Arbeit durchs System schleusen, so dass man die

gewunschten
Ziele erreichen kann
Team: reden, arbeiten und sich gegenseitig helfen. Ein
effektives Team ist autonom
Status:
Sprachreihenfolge:
LIFO: dann muss niemand jemand bestimmen, der zu

erst anfangt zu reden, das fordert


die Selbstorg.
Round-Robin: Irgendwo anfangen und dann im Uhrzeigersinn oder entgegengesetzer Uhrzeigersinn
Token herumreichen
Improvement Board:
werden wahrend des Dailys benannt und ans Board gemacht
Board ist von allen einsehbar und es misst den Fortschritt

zur Erfullung
des Problems

Updates konnen
auerhalb des Dailys gemacht werden
durchs aufschreiben verhindert man ausufernde Diskussionen
Board kann die Spalten: Problem, Anzahl, Eindammung,
Gegenmanahme, Status (Plan, Do, Check, Act)

2.4 Sprint Review


Zusammenfassung : Inspektion und Adaption in Bezug aufs Produkt-Inkrement
Teilnehmer : Team, PO, weitere Stakeholder, die vom Stakeholder eingeladen
werden
Input : Scrum-Team, Sprint Ergebnisse, Sprint Backlog, Stakeholder, Abhangigkeiten
Output : Akzeptiere/abgelehnte Sprint-Inkremente, update Risiken, updaten Abhangigkeiten, update Release Planning, update PB
Ziele :

Entwicklerteam zeigt die geschaffte Arbeit und beantwortet


Fragen zum Inkrement

eventuelle weitere Anderun Live zeigen und Feedback fur


gen zu erhalten

uberarbeitetes
PB

Fakten :

wird am Ende eines Sprints durchgefuhrt,


um das Inkrement
zu inspecten und da PB bei Bedarf zu adopten
timeboxed auf 2, 5% der Sprintzeit (4 Stunden fur
Monatssprint, 1 Stunde fur
Wochensprint)

22

ist ein informelles Meeting und soll Feedback und Zusam


menarbeit fordern
nach der Prasentation guckt sich der PO die Commitments
an und entscheidet, welche Items done sind und welche nicht
wird eine Story nicht fertig, dann landet Sie wieder im Backlog
SM hilft dem PO und Stakeholder, dass Feedback zu neuen
Items zur Priorisierung durch den PO abzuleiten

2.5 Retrospektive
Zusammenfassung : Inspektion und Adaption in Bezug auf den Prozess und der Umgebung

Teilnehmer : Entwicklungs-Team, SM, (PO), weitere Stakeholder vom Team gewunscht


Input : Entwicklungs-Team, SM, (PO)

Output : ausfuhrbare
und einverstandene Anderungen,
Anderungen
sind

Personen zugewiesen mit moglichen


Enddatum, Retro-Logs, gelernte Sachen
Ziele : Team checkt Prozess, Verhalten, Werkzeuge und macht Action,
kommende Sprints zu a ndern
um es fur
Fakten :

findet nach dem Sprint Review statt und vor der nachsten
Sprint-Planung
timeboxed auf 2, 5% der Sprintzeit (2 Stunden bei 2 Wochen
Sprints, 1 Stunde fur
einen Wochensprint)
SM stellt sicher, dass das Event stattfindet und das alle den
Sinn des Meetings verstehen
groe Dinge identifizieren, die gut und auch potential zur
Verbesserung haben
kom Team checkt ihr Verhalten und macht Action, um es fur
mende Sprints zu a ndern
gute Retro braucht den Sicherheitsfaktor, um wichtige Themen hervorzubringen und kein Blaming zu haben

2.6 Weitere
2.6.1 Scrum of Scrums
wird verwendet, wenn mehrere Scrum Teams an einer Sache arbeiten und sich

gegenseitig updaten und korrigieren mussen


dabei werden folgende Fragen beantwortet:
1. An was hat das Team seit dem letzten Meeting gearbeitet?
2. Was schafft das Team bis zum nachsten Meeting?

23


3. Was sind die Impediments und konnen
andere Teams helfen?
Entscheidungen habt ihr getroffen, die andere Teams beeinflussen
4. Was fur

konnen?

24

3 Artefakte

Reprasentieren Wert, um Transparenz sowie die Moglichkeit


zum inspect und adapt.
Scrum fordert vier Artefakte:
1. Product Backlog
2. Sprint Backlog
3. Produktinkrement
4. Burndown Chart
5. Impediment Backlog

3.1 Product Backlog


ist eine vom PO priorisierte Liste von zu erledigenden Dingen

Anforderungen und Anderungen,


ist die einzige Quelle fur
die am Produkt gemacht werden, d.h. alle Arbeiten des Entwicklungs-Team kommen aus dem PB
verantwortlich, dass es verfugbar,
PO ist dafur

geordnet und mit Inhalt versehen ist


PB ist dynamisch35 (lebendes Dokument) und niemals beendet
alle (PO, Teammitglieder, Stakeholder) einsehbar und erganzbar
ist fur
PB wird wahrend des Backlog Refinement Meetings gewartet36
verantwortlich und muss Rechenschaft dafur
ablegen, dass das PB
PO ist dafur

richtig gefuhrt
wird, auch wenn er bei der Erstellung und Aktualisierung Hilfe in
Anspruch nehmen kann
INVEST37 :
Independent: sollen nicht von einer anderen Story abhangen
Negotiable: details noch verhandelbar sein, wenn man merkt, dass manche

Dinge anders umgesetzt werden mussen,


als erwartet
Valuable: muss Kundennutzen stiften
Estimable: muss nicht exakt sein, aber wir sollten eine ungefahre Schatzung

abgeben konnen.
Small: wenn sie zu gro sind, ist es ein Indikator, dass man die Story nicht
ganz versteht.
Testable: Story ist testbar
Produkte sollen ein PB haben, egal wie viele Teams es verwenden, alles andere
die Teams festzustellen, an was sie als nachstes arbeiten
macht es schwierig fur
sollen
35 Anforderungen

werden sich immer a ndern


Eintrage sind zu gro oder generell und Ideen kommen und gehen
37 Zeichen einer guten Story, so sollen Anforderungen aussehen
36 d.h.

25

Product Backlog Item


beschreibt das WAS
wird oft in User Story Form geschrieben
hat eine Produktweite Definition von done (DoD), um technnical dept zu vermeiden
kann item-Abhangige Akzeptanzkriterien beinhalten

wird nur dann als fertig betrachtet, wenn es die DoD erfullt
DEEP38 :

Detailed: hoher
priorisierte Items sind detailierter als weniger niedrig priorisierte Items
Estimated: sollten eine Schatzung haben, aber sollten auch mal wieder neugeschatzt werden, sofern es weitere Informationen gibt
Emergent: Durch learnings und Veranderungen, sollte jedes PBI verandert

werden konnen
oder aber auch gesplittet, verandert oder geloscht
werden

Priorisiert: hochstens
Items sollten den meisten bang for your buck liefern
3.1.1 Backlog Refinement
Wird auch Product Backlog Grooming, Product Backlog Review, Backlog Estimation
oder Story Time genannt
Zusammenfassung : Splittung von groen Stories, Neuschatzung und Umpriorisierung
zukunftige

fur
Sprints
Teilnehmer : Team, PO, SM ist anwesend und garantiert, dass das Meeting stattfindet, eventuell weitere Stakeholder
Ziele :

Schatzungen von Eintragen39


Anforderungen klaren
Entfernung oder Herabstufung von Items, die nicht mehr relevant sind
Hinzupflegung oder Heraufstufung von Items, die neu hinzugekommen oder wichtiger geworden sind
Items herunterzubrechen und Unklarheiten zu beseitigen

Items zu groeren
Eintragen verschmelzen

Fakten :

timeboxed auf 10% der Sprintzeit (8 Stunden bei 2 Wochen


Sprints, 4 Stunden bei 1 Wochen Sprints)

PBIs werden in User Story Form geschrieben ubergroe


PBIs werden Epics genannt

38 Eigenschaft
39 80-20

eines guten PBI

Regel: 80% des Business Values konnen


mit 20% Aufwand erreicht werden

26

Wonach priorisieren?
Falligkeit fixed date; Wert/Nutzen
Expedite verursacht von Anfang an Kosten und die steigen dann spater immer
mehr an
cost of delay: wenn ich etwas nicht mache, desto teuer wird es
intangible: du musst es noch nicht heute haben, sondern erst, du kannst es heute
aber schon anbieten
Kano Modell (wie zufrieden/unzufrieden ist Kunde mit Feature xy)
Methoden fur
Splittung
Schichten beim Login: UI, MW, BE vertikale Schnitte nach Funktionalitat ist
besser, als wenn man erst eine Schicht komplett fertig baut und dann merkt, dass
das gebaute mit dem Rest nicht mehr richtig funktioniert und/oder sich dann
eventuell andere auf Fertigstellung warten, bis weiter gearbeitet werden kann
Dimensional Planning: z.B. Strae bauen (Schotter, Landstrae, Autobahn)

durch billige Losungen


bekommst du schneller Feedback
statisch vs. dynamisch bauen: statisch API call liefert immer denselben Wert

zuruck

Business Rule Variations (Was): z.B. unterschiedliche Zahlmethoden, Kundigung


einen Anwendungs Data Event Methode (Wie): Ich erfasse nicht alle Daten fur

fall, z.B. Warum-Feld, wenn Sie bei uns kundigen


od. Sicherheitsnummern bei der
Kreditkartenzahlung
manuell vs. automatisch
Error-Handling: erstmal alles abfangen, aber spater konkret sagen, was alles schief
lauft in Detail sagen
Singe- vs Multiuser
Performance: nicht gleich im ersten Schritt performant gestalten
Variation in Data: Lokalisierung
Wege zur Story Splittung:
1. Fokus auf bestimmte User-Rolle oder Persona

2. Basis Funktion (bekomme es lauffahig, dann hubsch


machen)
3. folge CRUD
4. disjunkte Szenarios: happy path, exceptions flows
5. vereinfachte Datenmenge

27

6. vereinfachter Algorithmus
7. Komponenten kaufen, statt es alleine zu bauen
8. Technologien fallen lassen, die Abhangigkeiten, Vendor Lock und Schwierigkeiten
9. manuellen Prozess automatisieren
10. Batch-Processing auf Online-Processing umwandeln

11. Ersetze generische Losung


durch angepasste Losung

12. nicht so viele HW, OS, Browser unterstutzen


13. anhand der AKs eine weitere Story splitten

14. Scanne nach Wortern


wie und und oder

3.2 Sprint Backlog


Wird auch Taskboard oder Scrumboard genannt
die aus dem PB ausgewahlten Items und der Plan, diese zu liefern, wird Sprint
Backlog genannt
beschreibt das WIE und ist ein forecast, welche Funktionalitaten im nachsten Inkrement geliefert werden
initiale Tasks werden vom Team wahrend des Sprint Planning Meetings bestimmt
nur PO kann das Sprint Backlog wahrend des laufenden Sprints bestimmen, ob

es angemessen ist, das Board updaten, Entwickler konnen


jedoch weitere Tasks
wahrend des Sprints ans Board machen
Team sichtbar
ist furs

Scope commitment ist fest wahrend der Sprint Ausfuhrung

Sprint Taks: benotigen


einen Tag oder weniger zur Fertigstellung

3.3 Inkrement/Produktinkrement
ist das Ergebnis aus allen im Sprint fertiggestellten PBIs am Ende des Sprints
ist so hochwertig, dass es den Nutzern ausgeliefert werden
muss der DoD entsprechen
muss in jedem Bereich vom PO abnehmbar sein

3.4 Burndown Chart/Sprint Burndown Chart


stellt den verbliebenen Team-Aufwand (Arbeit) fur
den laufenden Sprint dar
wird jeden Tag zum Daily neugeschatzt und kann auch mal hochgehen

hat die Absicht die Selbstorg. des Teams zu fordern


Management-Status Reports, dann sollte es vom
wenn es missbraucht wird fur
Teams zum Impediment wird
SM nicht weiter gepflegt werden, wenn es furs

28

3.5 Impediment Backlog


Liste von Dingen, die das Team davon abhalten, Fortschritte zu erzielen oder sich
zu verbessern
es handelt sich dabei um Dinge, die der SM aus dem Weg raumen muss, sei es die
Reparatur der Kaffeemaschine

3.6 Andere Artefakte


Teamvertrag: ist wie eine Teamcharta, z.B. wir machen Pair-Programming, reden
miteinander, machen TDD usw. es regelt die Arbeit miteinander
Definition of Ready: wenn PO sagt wei nicht, dann mit PO zusammen klaren,
wie man es dann umsetzen kann; Story ist so herunter geschrieben, dass man mit
dem Entwickeln anfangen kann
Definition of Done40 : ist sowohl mit Team als auch mit PO vereinbart, arbeiten

mehrere Teams am gleichen System oder Produktrelease, dann mussen


sie ein gemeinsames Verstandnis davon haben
Product/Release Burndown Chart
zeichnet die verbliebenen Product Backlog Aufwand von einem Sprint zum
nachsten auf41
kann relative Einheiten verwenden: Story Points auf Y-Achse, X-Achse die
Sprints
Release Plannung nimmt ca. 15 20% der Zeit in Anspruch

40 wird
41 geht

gemacht, um technical debt Einhalt zu gebieten

den Release-Plan
uber
die Zeit fur

29

4 Sch
atzungen
zu bekommen, wieviel Sie schaffen konnen,

Team schatzt, um ein Gefuhl


es nutzt
den PO tun kann.
nix, was man nur fur
Schatzungen weichen ab: statt standig nach den Ursachen zu forschen, dran denken, dass das Team fixe Kosten hat; Team kann die entsprechende Menge liefern,

zu der Sie gefuhlt


in der Lage sind

Schatzen ohne Erfahrungen ist schwierig z.B. die Schatzungen uber


verschie
dene Staaten, wie oft darin ein Land von der Groe
Deutschlands reinpassen

wurde
(hatten wir wahrend der Ubung
anstelle von Landern in km2 geschatzt,
ware es noch viel schwieriger geworden)
ist in Agiler Entwicklung weniger wichtig als in traditioneller Entwicklung
wenn man das Produkt in kleine auslieferbare Zustande halt, dann wird die Arbeit
stets so herumpriorisiert
komplexe Modelle mit historischen Daten funktionieren einfach nicht, einfachere und schnellere Techniken wie Planning Poker und Affinity Estimating liefern
genau so gute Ergebnisse und sind weniger komplex
Schatzungen sind immer ungenau

Personen, die die Aufgabe ausfuhren,


sollen immer bei der Schatzung dabei sein
mehr Erfahrung bedeutet prazisere Schatzung
manche Teams benutzen einfaches Schatzen: Alles ist entweder Small oder wird

in kleinere Stucke
heruntergebrochen

4.1 Abstrake Sch


atzmae
es wird nicht mehr in Aufwand, sondern Komplexitat geschatzt, da es die folgenden Vorteile bietet:

vergleichende/abstrakte Schatzungen sind schneller durchfuhrbar


als Schatzen

absoluter Groen

Komplexitats-Schatzungen altern nicht, d.h. mussen


nicht wahrend eines Projekts durch Neuschatzungen korrigiert werden. Z.B. dauert das FormularEingabe Formular durch fehlende Erfahrung deutlich langer als im spateren
Projektverlauf, aber die Komplexitat bleibt aus Anwendersicht gleich und
muss nicht angepasst werden
Trennung von Komplexitat und Aufwand wird mehr Objektivitat geschaffen,
ohne die umsetzenden Individuen zu kennen
Bei Komplexitatsschatzung muss nicht bereits die Geschwindigkeit unterschiedlicher Entwickler einkalkuliert werden, was die Schatzung aufwandig

und personenbezogen machen wurde


Vielschichtigkeit der Komplexitat:
es gibt einen komplizierten Ablauf

30

es sind viele Bereiche der Software betroffen

es sind sehr viele Anderungen


vorzunehmen
es sind viele Personen involviert

eine mogliche
Einheit sind Fibonacci Zahlen:
0 - Kein Aufwand notwendig.
1 - Sehr kleiner Umfang.
2 - Kleiner Umfang: doppelt so wie ein kleiner Umfang.
3 - Mittlerer Umfang: so gross wie ein sehr kleiner und ein kleiner Umfang
zusammen.
5 - Grosser Umfang: so gross, wie ein kleiner und mittlerer Umfang zusammen.
8 - Sehr grosser Umfang: so gross, wie ein mittlerer und grosser Umfang zusammen.
13 - Riesiger Umfang: so gross, wie ein grosser und sehr grosser Umfang
zusammen.
? - Nicht abschatzbar.
Wie wird aus der abstrakten Schatzung eine Aufwandsabschatzung?

gelangt man nur uber


den Velocity Faktor, der angibt, wie viele Story-Points in

einem definierten Zeitbereich umgesetzt werden konnen


Velocity kann man durch folgende Varianten ermitteln:
1. Historische Daten: Aus der Vergangenheit ist es bekannt, wichtig ist, dass
die Teamzusammensetzung vergleichbar ist
2. Vorprojekt: ein kleiner Ausschnitt des Gesamtprojekts wird in einem kurzen
Vorprojekt umgesetzt und daraus die Velocity-Kennziffer ermittelt
3. Schatzen: gibts keine historischen Daten und/oder kein Vorprojekt, dann
hilft nur die Bauchentscheidung
wenn man die Team-Aufstellungen verandert, dann invalidiert das die VelocityMessungen
Wenn man mehr Leute ins Team holt, dann kann dies ebenfalls die Velocity Zahl
senken
Sustainable Velocity kann erst entstehen, wenn man mehrere hintereinander aus

gefuhrte
Sprints fester Lange und mit gleicher Team-Starke durchgefuhrt
hat
Velocity Messungen klappen am besten, wenn man End-To-End Features am Ende
eines jeden Produktes ausrollt, so wie es vom Scrum-Framework vorgeschlagen
wird (NFR-Stories durchbrechen diese Linie mal wieder)

31

4.2 Konzepte des agilen Sch


atzens

stellen den Bezug zwischen unseren Groenbestimmungen


zur Dauer durch die
Verwendung der Velocity her, die Rate, in der ein Team lauffahige, getestete Features an den Product Owner liefern kann. Wir sagen, ein Team hat eine Velocity
von 25, wenn es am Ende jedes Sprints fertige Stories abliefern kann, deren auf
summierte Groen
im Durchschnitt 25 Punkte betragen
Warum bemessen wir Dinge, die relativ zueinander stehen?

Menschen
naturlicher
fur
man kann sich leichter darauf einigen, dass eine Story doppelte Komplexitat
wie eine andere Story hat, auch wenn wir nicht wissen, wie lange es dauern
wird, jede zu implementieren
Warum bemessen wir Dinge in Komplexitats-Einheiten statt in Zeit?

oder Kom ermoglicht


und die Rate, in der ein Team arbeitet, von der Groe
plexitat der Arbeit zu trennen
das bewahrt uns davor, unsere Schatzungen anhand dessen zu a ndern, der
die Arbeit macht, oder wenn die Fertigkeiten und Kapazitat des Teams sich
mit der Zeit a ndert. Wir verwenden Story Points als Einheit
Warum eine nicht-lineare Bemessungsskala verwenden?
weil die Differenz zwischen einer 1 und einer 2 offensichtlich mehr aussagt relativ betrachtet - als die zwischen einer 20 und 21
Fibonaccia Zahlen: 1,2,3,5,8,13,20,40

ein Team kann eventuell Stories im Groenbereich


von 1-8 oder vielleicht

Epics definiert, die in kleinere


eine 13 schaffen. Die groeren
Zahlen sind fur

Stories heruntergebrochen werden mussen

4.3 Planning Poker


ist ein guter Weg, um bei der Schatzung von Anforderungen innerhalb von Entwicklungsteams einen Konsens zu finden
Schatzungen sind meist akkurat, da es von diejenigen Geschatzt wird, welche die
Arbeit auch erledigen
Ablauf:

PO, Team oder SM stellt die Aufgabe vor und anschlieend kann daruber
diskutiert werden, Risiken aufgezeigt oder Annahmen getroffen werden
dann folgt die Schatzrunde: Alle Leute drehen Ihre ihre Karten gleichzei
tig aufgedeckt um. Gibt es groe Abweichungen, dann wird uber
den Wert
diskutiert. Dabei sagt der SM, dass jeweils die mit den beiden extremsten
Auspragungen diskutieren sollen. Anschlieend wird erneut geschatzt. Nun

sollte der Wert konvergieren, im Zweifelsfalls wird dann einfach die hohere
Schatzung genommen
wird eine Story > 13 oder mit einen ? geschatzt, dann ist diese von der
Detaillierung der Funktion her zu ungenau beschrieben

32

Vorteile:
Teamentscheidungen: Entscheidungen sollen auf den Konsens aller Teammitglieder aufbauen, alle stehen hinter dem Schatzwert.
Schnelle Entscheidung: nach wenigen Schatzrunden einigen sich Teamleute

meist auf eine Groe


(geubtes
Team kann in einer durchschnittlichen Rate
von 3 Minuten pro PBI schatzen).
Transparenz: PO versteht besser, wie die Aufwande entstanden sind, kann

ein Team nicht schatzen, dann ist dies ein Indikator, dass die Story uberarbeitet werden muss.

alle sind beteiligt: berucksichtigt


Gruppendynamische Aspekte, d.h. sehr
dominanten oder devoten Personen wird entgegengewirkt, mit dem Ziel dass
jedes Gruppenmitglied sich aktiv an der Schatzung beteiligt und sein Wissen
beitragt.
Unterschiedliche Expertenmeinungen: Aufgaben, die viele unbekannte Variablen beinhalten, ist es gut, wenn sich die verschiedenen Fachbereiche zu
sammentun und sich miteinander uber
das Produkt gemeinsam austauschen.

4.4 Team Estimation


eine gute Schatzung auch schon die Imple sehr technische Teams finden, dass fur
mentierung bekannt sein muss - Steve Bockman hat mit dieser Schatzvariante eine
Losungsm

schone
oglichkeit
gefunden:
Ablauf:
PO, Team, SM sind da
User-Stories auf Karten mitbringen: Alle Stories liegen auf einzelnen Story
Cards aufgedruckt und verdeckt auf einen Stapel.
Reihenfolge herstellen: Erstes Ziel ist, die Karten nach aufsteigender Komplexitat in eine Reihenfolge zu bringen. Ganz unten in der folge liegt die einfachste Karte und ganz oben die Komplexeste Team muss sich einigen wo
einfachste Karte und ganz oben die Komplexeste Team muss sich einigen
wo oben und unten ist.
Team spielt: Teammitglieder sind reihum dran und jeder Spieler macht einen

von zwei moglichen


Zugen:
1. Spieler zieht eine Karte, liest diese vor und stellt dem PO Verstandnisfragen. Draufhin legt er sie an eine von ihm gewahlte Stelle innerhalb der
Reihenfolge ab

2. Spieler verschiebt mit einer kurzen Begrundung


eine bereits auf dem
Tisch liegende Karte an eine andere Stelle in der Reihenfolge
herumwandernde Karten: wandert eine Karte in der Reihenfolge hin und
her, muss der PO sie aus dem Spiel nehmen, offenbar ist die Anforderung
nicht exakt genug beschrieben und es besteht Uneinigkeit im Team, welchen
Inhalt das Feature genau hat

Ist die Reihenfolge hergestellt, geht es im nachsten Schritt darum, Groenverhaltnisse zu beschreiben, um Story-Point-Schatzungen zu erganzen:

33

auswahlen,
Referenz definieren: Team muss eine Referenz-Story mittlerer Groe

die es einigermaen gut uberblicken


kann.
die ausgewahlte Referenz muss eine Schatzung
Referenz beschatzen: fur

abgegeben werden (entweder schneller mundlicher


Konsens oder kleine
Pokerrunde zum Thema).
Referenz beibehalten: Ist das Referenzfeature gewahlt und geschatzt,
muss es bei folgenden Schatzmeetings als Referenz herhalten und sollte
immer mit in die Reihenfolge (erster Schritt) einsortiert werden - und
zwar unabhangig davon, ob es bereits realisiert wurde oder nicht.
Skala erganzen: nun durchlauft man die Reihenfolge, vom ReferenzFeature aus- gehend, erst nach unten (kleiner) und fragt das Team, ab
wann die nachste Stufe in der Skala erreicht wird (Entscheidung im Konsens). Ebenso verfahrt man anschlieend in die Gegenrichtung.

4.5 Magic Estimation


Wird auch Bucket Estimation genannt

gut, um moglich
beim Start eines neuen Projektes mit vielen Stories schnell zu

einer Aussage uber


den gesamten Umfang der zu entwickelnden Funktionalitaten

zu gelangen (stammt ursprunglich


von Boris Gloger)
wie beim Planning Poker geht es nicht um Prazision, sondern um eine erste Einschatzung
Ablauf:
Schatzskala von Fibonacci wird auf den Bode oder ans Board gelegt
PO packt PBIs ans Bord oder legt sie auf den Boden
Team fangt an, Karten innerhalb der Schatzskala zu verteilen. Dabei darf weder gesprochen, noch nonverbal per Mimik und Gestik kommuniziert werden
bei Unklarheiten den PO fragen und sie sollen sich nicht untereinander unterhalten
ein Teammitglied darf jederzeit eine bereits zugeordnete Karte erneut verschieben
wandert eine Karte standig hin und her (Nervous Nelly) muss der PO sie aus
dem Spiel nehmen, um sie nachtraglich zu diskutieren
Vorteile:
in kurzer Zeit kann man groe Mengen an Anforderungen schatzen lassen
gut um groe Projekte bzw. lange Feature-Listen in eine schnelle Initialschatzung
mit minimalem Zeitaufwand zu erhalten
gemeinsames Verstandnis
Teamschatzungen verhindern Aufbau von Wissensinseln

34

4.6 No Estimation
Woody Zuill und Neil Killick sind sehr aktiv in dieser Szene
Allgemein Schatzung: Eine Schatzung ist eine ungefahre Berechnung oder Beurteilung von einem Wert, Zahl, Menge oder Umfang
Software Schatzung: Es ist ein Versuch die Zukunft vorherzusagen
Grund furs
Schatzen: Bessere Entscheidungen treffen
Anforderungen, die wir nicht genau ent Schatzungen sind oft Vermutungen fur
uns entschieden wurden42
deckt haben und bereits im Vorfeld furs
Schatzungen sind schwierig: Wenn Anforderungen wage sind (sind die meistens), dann ist die Schatzung auch wage; wenn Anforderungen klar sind, kann
man nicht sagen, wie lange etwas dauert, wenn man es vorher noch nicht getan

hat (wenn man es vorher bereits getan hatte,dann konnte


man es ja bereits schon
zeigen)

Zustand, dass man keine Schatzungen braucht: Kleine Stucke


von arbeit inkre
mentel zu erledigen, die schnell zu einem moglichst
auslieferbares Produkt kommen

Schatzungen erlaub Entscheider (Manager, Stakeholder) den Start oder Weiterfuhrung

eines Projekts genehmigen. Aufgrund dessen konnen


Sie Entwickler die Schuld an
ungenauen Schatzungen geben und schneller arbeiten sollen. Und die Entwick
ler beschweren sich uber
unklare, nicht korrekte und falsche Anforderungen
groer Kreis von blaming und keiner hat am Ende gewonnen
Zeit, die man zum Schatzen von Stories verwendet, die nicht geliefert werden

(oder mit Verzogerung)


ist Verschwendung
Nachdenkfragen:
1. Wenn du herausfindest, das Schatzungen wertlos sind, was kann man dann
machen?
2. Wenn Schatzungen falsche Erwartungen wecken und falsche Signale sind,
was machst?

3. Wenn Schatzungen nie existiert hatten oder nie erfunden wurden, konnten
wir dann arbeiten?

4. Wenn du einen besseren Weg zur Erledigung von Arbeit gefunden hast, wurdest
du dann weiterhin schatzen?

5. Was ist, wenn ich Schatzungen brauche, aber wir sie nicht gut durchfuhren,
wie kann man das reparieren?

6. hat ein PO jemals einer Story uber


eine andere geschoben, weil eine Story
niedriger geschatzt wurde? Wenn Antwort nein ist, dann ist die Schatzung
da die Schatzung nicht zur Entscheidung beigetragen hat. Wenn Antmull,
wort ja ist, dann ist es schatzungs-kontrolliert, was dann mehr auf Wertbasierte Entscheidungen geht, wenn man dann das Backlog so nimmt und
42 wir

verstehen es nicht ganz und konnen


deshalb haben Aussagen daruber
auch keinen Wert

35

Release Planning auf Velocity Basis macht, dann ist ist es ein kosten-basierter

Ansatz (somit wurde


es Google, Facebook, Spotify usw. nicht geben)
Aufruf:
benutze richtige Beschrankungen, um Entscheidungen zu treffen, z.B so viel
Geld geben wir aus oder bis Juni wollen wir fertig sein
beliebige Beschrankungen (Deadlines ohne Schatzung) verursachen dysfunktionale und ineffektives Verhalten
Stories klein und simpel halten, WIP Limit erstellt ein vorhersehbares System

Wir konnen
Software nicht bauen, ohne zu wissen, wie lange es dauert und wie

teuer es ist? Es gibt keine Sicherheit in der Softwareentwicklung, wenn man uber
Kosten und Zeit schatzt, dann generiert man Unsicherheit, weil du ratest
Wie kann man ohne Schatzungen arbeiten

mache echte Arbeit (schafft vertrauen, man ist hoflich)

liefere kleine, nutzliche


Dinge vom gesamten Ding aus
immer an etwas mit einen Nutzen arbeiten
und regelmaig aus
liefere fruh
entscheide auf Basis von funktionierende Software
mach das, was gerade wichtig ist
halte den Code lesbar, erweiterbar und austauschbar
werde besser in der Erstellung von simplen, eindeutigen Scheiben von Funktionalitaten, messe deinen Durchsatz
Wie kann man den empirischen Durchsatz messen:
messe die aktuelle Lead Time, die ein Task zur Fertigstellung braucht
messe den Durchsatz, d.h. wieviele Karten sind am Ende in einer Done Spalte
sein)
Verwende WIP (kann amn Anfang die Teamgroe
nun kannst du Littles Law benutzen, um die durchschnittle Bearbeitungszeit zu
messen von einem Task n in der Queue verwenden (WIP + n / Durchsatz)
z.B.
Anzahl der Karten in einer Woche: 20, d.h. der Durchsatz ist 4 Karten pro Tag
ist zwei, d.h. WIP = 2
Teamgroe
durchschnittliche Bearbeitungszeit ist (2 + 1 / 4) sind 0,75 Tage

36

5 Retrospektiven richtig durchf


uhren
Quintessenz: Manahmen herausfinden, um die eigene Zusammenarbeit zu verbessern
der Inspect-Teil wird hierdurch ganz stark beschrieben
Post-Mortem Retro: macht man, nachdem ein Projekt vorbei ist, wie lief Planung,
Aufteilung, die Sprints
checkt am Start normalerweise die Ergebnisse der vorherigen Retro und guckt, ob
die damals beschlossenen Aktionen abgeschlossen sind
alles, was bei der Retro auskommt, werden in kommenden Sprint umgesetzt

die Aktionen der Retro konnen


ins Produktbacklog aufgenommen werden, damit

Sie auch umgesetzt werden konnen,


Man sie auch schatzen und sie ans Board
hangen, damit sie sichtbar sind
Vorteile der Retro
das Team Teams sind selbstorg. und haben die
Aktionen vom Team, fur
Macht, ihren Arbeitsfluss zu a ndern
der Inspect-Teil wird hierdurch ganz stark beschrieben
Post-Mortem Retro: macht man, nachdem ein Projekt vorbei ist, wie lief Planung, Aufteilung, die Sprints

5.1 Warum Retro durchf


uhren

Orgs mussen
sich verbessern, um in Geschaft zu bleiben und um Kundennutzen
liefern
klassische Organisationsverbesserungen dauern lange und sind meistens ineffizient und ineffektiv

wenn man mehr Kundennutzen liefern mochte,


dann muss man die Art wie man

arbeitet Retros helfen Probleme zu losen


und sich selbst zu verbessern
Retros werden vom Team gehalten und hilft Ihnen besser zu arbeiten, nicht der

Organisationen Macht den Teams, wo es auch hingehort

wenn Teams sich ermachtigt fuhlen,


dann bringen sich die Leute auch besser ein
und haben weniger Hemmungen sich zu a ndern
Teams einigen sich auf Veranderungen und sie leiten die Veranderungen auch eigenstandig

wenn Teams ihre eigene Verbesserungen leiten, ist effektiver, schneller und gunstiger als wenn andere Teams und weitere Leute zwischen den Veranderungen stehen

37

5.2 Struktur einer Retro


1. Setting the stage:
Zweck :

Kontext und Fokus auf Ziel der Retro


neues Team braucht Vertrauensbasis (Security Check machen)
Arbeitsvereinbarungen und Vertrage wie man sozial miteinander umgeht43

Start :

ihre Zeit bedanken


Leute willkommen heien und fur
Retro-Ziel und Dauer benennen

2. Gather data:
Zweck :

Was ist passiert? Gutes und schlechtes sammeln44


timeline (Arbeit, privates) sammeln

Start :

mit harten Fakten: Ereignisse45 , Metriken46 , Feature und die Anzahl


der fertiggestellten Stories
eine Stunde angesetzt, dann frage alle Leute in der
ist die Retro fur

Runde, um uber
die Daten und Ereignisse nachzudenken47
frag die Leute, dass sie sich die gesammelten Daten ansehen und

Muster sowie Anderungen


und Uberraschungen
entdecken

S. 10 im Buch erklart das F Word: Frage die Leute in Retros nie, wie sie sich fuhlen
3. Generate insights:
Zweck :

Frage nach Warum48

erlaubt es dem Team einen Schritt zuruckzugehen


und das groe
Bild zu sehen
was bedeutet die Sache aus 2.? Team konsolidiert die Daten, um
Starken und Probleme von den bisherigen Iterationen zu sammeln

Start :

begleite und fuhre


das Team die Bedingungen49 zu untersuchen, Interaktionen und Muster zu erkennen, die an Ihren Erfolg teilgehabt
haben

losungs-orientiertes
Denken: Zu allererst scheinen Ideen okay zu sein,
aber oftmals sind sie es nicht50

4. Decide what to do next:

43 (z.B.

Handys ausstellen)
das versuchen Individuen ihre eigenen Ansichten und Glaubensrichtungen zu verifizieren
45 Meetings, Entscheidungspunkte, Meilensteine, Feiern, Aneignung von neuen Technologien
46 Burndown-Charts, Velocity (Geschwindigkeitsmessungen), Anzahl der geschafften Stories, Anzahl von

uberarbeiteten
Code
47 (harte Fakten helfen den Leuten hoffentlich an ihre Gefuhle

Konversationen)
zu denken gut fur
48 denke daran, wie man es anders machen kann
49 halte Ausschau nach Risiken und unerwarteten Ereignissen oder Ergebnissen
50 versuche die Wurzel des Problems zu entdecken und entscheide mit dem Team gemeinsam wie Ihr diese
Sache angehen wollt
44 ohne

38

Zweck :

Cluster uber
Probs. bilden und welche 2-3 Manahmen im nachsten
Sprint von wem angegangen werden sollen

Start :

wenn man viele Ideen hat, dann die heraussuchen, die das Team
auch bis zur nachsten Retro erledigen kann
wenn das Team aus einer Phase kommt, von der es sich erstmal erholen muss, dann hilf dem Team einen weniger komplexen Task zu
wahlen

sehe zu, dass jeder Task ein personliches


Commitment hat, Leute
nehmen an, dass es das Team machen wird und dann macht es letzten Endes niemand im Team

5. Checkout:
Zweck :
Start :

Hilfe dem Team sich zu entscheiden, wie Sie die gelernten Erkennt
nisse aus der Retro behalten konnen
verfolge neue Taktiken mit Postern oder groen Sichtbaren Charts

mache Bilder die gelernten Sachen gehoren


dem Team
die harte Arbeit, die Sie in den Sprint gesteckt haben
danke alle fur
nimm dir Zeit, eine Retro der Retro zu machen

5.3 Vorteile der Retro Struktur


Meinungen der anderen verstehen
verstandisvolle Sicht auf die vom Team verwendeten Arbeitsmethoden und Tools
Diskussion erlauben in die Richtung zu gehen, in der sie gehen sollen, ohne vorher
schon mit einen festen Ergebnis auszugehen
Struktur gibt dem Retroleiter ein Versuchset in die Hand, die dem Team beim inspect and adapt hilft

5.4 Eine Retro leiten


neben kontext auch den Prozess beachten
Prozess bedeutet: Aktivitaten, Gruppendynamiken und Zeit managen
du musst neutral im ganzen Prozess sein

10 Sekunden,
fuhre
Aktivitaten mit einer Vorlage ein, erklare diese und warte fur
wenn es keine Fragen gibt, dann kannst du mit der Aktivitat anfangen
wenn du doch aktiv in die Retro eintauchen willst, dann gib bescheid, dass du
kurz deinen Hut abnimmst, deine Meinung sagst und danach wieder die RetroRolle einnimmst
Aktivitaten managen
erklare den Zweck jeder Aktivitat

39

Fragen verfugbar

du musst fur
sein und den Raum beobachten
debriefe jede Aktivitat hilft dem Team die gesammelten Erfahrungen und
gewonnenen Erkenntnisse zu untersuchen, es macht eine konsequent Verbindung zu den neuen Idee
1. Frage nach beobachteten Ereignissen und sensorischen Input: Was habt

Ihr gesehen und gehort?

2. Wie haben die Leute auf die Ereignisse reagiert: Was hat Euch uberrascht,
was hat Euch herausgefordert?
3. Erkundige dich nach Einsichten und Analyse mit Fragen: Was hast du

daruber
gelernt, was
4. Erkundige dich nach Einsichten und Analyse mit Fragen: Was hast du

daruber
gelernt, was sagt dir das uber
das Projekt aus solche Fragen
helfen den Leuten, ihre Ideen zu formulieren und die Aktivitat zum Pro
jekt zu verknupfen
5. Nachdem die Verbindung zwischen Aktivitat und Projekt erstellt ist, dann

Frage die Leute, wie Sie Ihre Einsichten verwenden konnen:


Was ist ein

Ding, was du verandern wurdest?

folgt genau den gleichen Schema einer Retro (Daten Sammeln, Einsichten
erstellen und entscheide dann, was gemacht)
Debriefing sollte 50 - 100 Prozent Zeit der gemachten Aktivitat betragen
Gruppendynamik
bedeutet Teilnahme
Leute, die reden wollen sollen auch Reden und Leute die zu dominant beim Reden

sind, mussen
eingeschrankt werden
aktiviere Leute, die nicht so viel sprechen

Manager fuhlen
sich oft dazu in der Lage versetzt, leere zu fullen
(sprich zu viel
zu reden) briefe den Manager vor dem Meeting und sage, dass die anderen zu
erst sprechen sollen

wie du dem Team helfen kannst, voranzukommen: Wie du die Kreativitat zuruck
geben kannst
1. Was habt ihr zuvor schon mal probiert? Was ist dabei passiert? Was wollt ihr
beim nachsten Mal a ndern, damit das nicht nochmal passiert?

2. Wenn wir die Anderung


haben, was wurdet
ihr geben?
3. Habt Ihr schon jemals etwas anderes ausprobiert?
achte auf Working Agreements wenn du optionale Vereinbarungen akzeptierst, dann
erweckt es den Eindruck, dass die Working Agreements ebenfalls optional ist

40

Blame danger YOU besser die ICH Sprache verwenden, denn dadurch fokussiert man sich auf die Beobachtungen und Erfahrungen des Sprechers wenn
du das Verhalten von Leuten beschreibst, da hat dies zur Folge, das Leute eine

Pause einlegen und daruber


nachdenken, was sie gerade machen

wenn du blame oder personliche


Kritik horst,
dann greif ein und lenke die Diskussion auf den eigentlichen Inhalt
du musst dich mit emotionalen Interaktionen und Situationen herumschlagen

wenn Eklats die Regel sind, dann muss es ein groeres


Problem geben, welches

du nicht losen
kannst sprich mit HR
Wie man mit bestimmten Situationen am besten umgehen kann
Tranen: Biete ein Taschentuch an, wenn die Person wieder sprechen kann, dann
frag nach, was mit der Person los ist. Stelle auch die Frage, ob die Person weiter
an der Retro mitmachen kann.
schreien: Wenn jemand schreit, dann ist die Reaktion der Leute so, dass sie nicht
mehr teilnehmen. Greif unmittelbar ein (Hand heben) und sag, dass die Person
den Sachverhalt nochmal erzahlen kann, nur diesmal ohne zu schreien. Wenn auch

das keine Losung


ist, dann lege eine Pause ein und rede mit der aufgebrachten
Person privat.

stampfen, auftreten: Frag das Team nach den Grund und frage, ob es moglich
ist,
die Retro weiterzumachen, wenn dies haufiger mit der entsprechenden Person der
Fall ist, dann rede mit der Figur.
Unangebrachtes Lachen und Herumalbern Frag, warum das ab einen bestimmten Punkt passiert.
die Ruhe und ob die Gruppe mude

Unpassende Stille Frage nachdem Grund fur


ist oder unsicher, wie man mit dem Thema weitermachen soll.
5.4.1 Zeit managen
nimm ein Zeitmessgerat (Pomodoro, Zeitmessuhr) mit und achte auf die Dauer
der einzelnen Aktivitaten
wenn mehr als 8 Leute vertreten sind, dann verwende eine Glocke oder etwas
vergleichbares, um die Leute nach einem Event zusammenzutrommeln
rumschreien und Pfeifen bringt nix - besser Entenrufe, Kuhgerausche
wenn die Gruppe voller Energie in einer Phase ist, dann frag, ob sie weitermachen
wollen und darauf hinweisen, dass die Endaktivitat nicht erreicht wird

41

5.4.2 Dich managen

verstehe und manage deine Gefuhlslage


ist der Schlussel
zum Managen von Gruppendynamik
wenn du Angst hast oder sich Spannung aufbaut, dann atme tief durch, mach eine
Pause wenn es notwendig ist. Angst ist ein Zeichen, dass du nicht genau weit,
was du als nachstes machen musst
die Emotionen im Raum verantwortlich bist
erinnere dich daran, dass du nicht fur

und es liegt nicht in deiner Verantwortung, dass alles und jeder glucklich
und nett
ist
wodurch du
wenn du Angst hast, dann ist der Blutfluss zu deinem Gehirn gestort,

nicht klar denken kannst, was dann zu noch mehr Angst fuhrt.
Wenn dein Gehirn
wieder mit Sauerstoff versorgt ist, dann stell dir folgende Fragen:
1. Was ist gerade passiert?
2. Wieviel von mir war in mir und wieviel von mir was auerhalb von mir?
3. Wie ist die Gruppe in die Situation gekommen?
4. Wo muss die Gruppe als nachstes hingehen?
den nachsten Schritt?
5. Was sind meine drei Optionen fur
6. Was bietet ich der Gruppe an?

5.5 Business Value von Retros


den Kunden und
dadurch, das Teams besser werden wird auch dessen Wert fur
der Org besser
das kann die Org schneller, effizienter und innovativer machen
hier nun einige Sachen wie man den Geschaftsnutzen in Retros verbessern kann:
halte Actions Ausschau, die das Team auch a ndern kann
Fokus auf Lernen und Verstehen statt blaming
Begrenze die Anzahl an Issues, die man in der Retro untersuchen will
machen root cause analyse um die Ursachen und nicht die Symptome zu
finden

5.6 Voraussetzungen f
ur Retros
Bedurfnis

nach diesem Ritual


Leute halten normalerweise wahrend eines Projektes nicht an, um zu reflektieren
ein Ritual bringt Leute zusammen, um sich auf das wichtigste zu konzentrieren

und um Erreichtes zu wurdigen


keine Limits, wie viele Teilnehmen wollen und es ist gut die Sichtweisen der anderen zu sehen

42

Dem Prozess einen Namen geben


andere Namen sind postmortem, post partum, post-engagement
klarer Name hilft, dass jeder im und auerhalb des Prozesses das Metting verstehen kann
Kernaufgabe der Retro: Zustand der Sicherheit51
Die dunklen Seite der Retro vermeiden
es gibt auch manchmal Complain Sessions, aber man muss darauf achten, dass das
nicht auer Kontrolle gerat, d.h. wenn sich der Empfanger der Kritik getroffen
wird und sofort in den Verteidungsmodus geht und zum Gegenschlag ausholt

man kann es vermeiden, in dem man Wunsche


anstelle von Beschuldigungen
a uert

5.7 Retro von Retros


mehrere Teams arbeiten am selben Produkt und jedes Team hat sein Retros es
kann gut sein, wenn alle Teams ihre gelernten Sachen miteinander teilen
RoR kann die Zusammenarbeit zwischen den Teams und ihre Projektteilnahme

erhohen

Risiken behandeln, Produktqualitat steigern, es kann auch die Chance erhohen,


brauchbare Funktionen schnell und kontinuierlich auszuliefern

5.8 Aktivit
aten f
ur Setting the stage
5.8.1 Check-In
eine normale Retro
Dauer : 5 - 10 Minuten sind gut fur
Beschreibung : Nachdem du alle willkommen geheien hast und das Ziel der Retro
besprochen hast, stellt der Retroleiter eine zentrale Frage
Zweck : erfahre was sich die Leute von der Retro erhoffen
Schritte :

Stelle eine Frage, die jeder mit einem Wort oder in einem Satz beantworten kann
Was ist das Wort, was am besten das beschreibst, was du von
dieser Retro erwartest?
In ein oder zwei Worten, was sind deine Hoffnungen von dieser Retro?
Was ist eine Stelle, due du gerade im Kopf hast

51 denn

nur dann fuhlen


sich die Leute in der Lage, ihre Probleme, Meinungen und Bedenken zu a uern

43

ein Auto wurdest

Wenn du in die Retro kommst, was fur


du
sein?
es ist okay, wenn manche Leute keine Antworten auf die Fragen
haben und den Ball einfach weitergeben
dir jede Antwort
gehe nach und nach jede Person durch und hore
an
5.8.2 Focus On und Focus Off
eine normale Retro
Dauer : 8 - 12 Minuten gut fur
Beschreibung : Alle willkommen heien und danach beschreibt der Retroleiter produktive und unproduktive Kommunikationsmuster. Nachdem die Mus
ter erklart wurden, diskutieren die Teilnehmer uber
die entsprechenden
Inhalte
gute KommuZweck : Hilft beim Aufbau eines gemeinsamen Verstandnis fur

nikation. Es hilft den Teilnehmern Vorwurfe


und Vorurteile Beiseite zu
legen und auch die Angst davor zu verlieren.
Schritte :

stelle das Poster mit den entsprechenden Aussagen auf und erklare es.
bilde Gruppen von weniger als 4 Leuten die sollen die Aussage
definieren und erklaren

frag jede Gruppe was die beiden Worter


bedeuten und welche Verhaltensweisen dahinter verbirgt52
jede Gruppe stellt Ihre Ergebnisse dem ganzen Team vor
frage die Leute, ob sie sich eher in der linken oder rechten Spalte
sehen

5.8.3 ESVP
Dauer : 10 - 15 Minuten - gut in einer langen Iteration, Release und ProjektRetro
Beschreibung : Jeder Teilnehmer teilt anonym seine Einstellung zur Retro als Explorer,
Shopper, Vacationer oder Prisoner fest. Der Retroleiter fest die Ergeb
nisse als Graphik zusammen und fuhrt
dann eine Diskussion, was die
die Gruppe bedeuten
Ergebnisse fur
Zweck : Fokus der Leute auf die Retro und verstehe die Einstellungen der Leute
zur Retro
Schritte :

Erklare, dass du eine Umfrage durchfuhren


wirst, um zu lernen,
wie die Erwartungshaltung der Leute an die Retro ist
Zeige die Flipchart und erklare die einzelnen Personengruppen:

52 Sie

sollen erklaren, wie jedes davon Einfluss auf das Team und die Retro hat

44

Explorers: sind eifrig neue Ideen und Einsichten zu erlangen;

Sie willen alles was sie konnen


uber
die Iteration, Release, Projekt erfahren

Shoppers: Gucken sich alle Verfugbaren


Informationen an und
sind froh, wenn sie mit einer guten Idee heimgehen
Vacationers: Sind nicht an der Retro interessiert, sind aber
von der taglichen Schinderei weg zu sein. Manchmal sind
fruh
sie aufmerksam, aber sie sind froh nicht mehr im Office zu
sein

Prisoner: Fuhlen
sich zur Retro gedrangt und wurden
liebend
gerne etwas anderes machen
verteile Karten, auf dem jeder seine Rolle eintragt
erinnere die Leute daran fertig zu werden und ihre Zettel zu falten

und sie geschuttelt


unsichtbar in eine Tombola zu werfen
jeden Ein frag einen der Teilnehmer einen Strich im Histogram fur
53
trag zu machen
frage, was die Leute mit den Daten machen wollen54
einen Einfluss haben diese Einstel Abschlussbesprechung: Was fur
lungen auf unsere tagliche Arbeit?
5.8.4 Working Agreements
Dauer : 10 - 30 Minuten - gut in einer langen Iteration, Release und ProjektRetro
effektives Verhalten zu erhalBeschreibung : Leute arbeiten zusammen um Ideen fur
bis sieben Vereinbarungen treffen konnen

ten, bei dem sie funf


Zweck : Verhaltensweisen etablieren, welche das Team in produktive Diskus
sionen unterstutzt
Schritte :

Wir erarbeiten in dieser Aktivitat eine Menge an Working Agreements, so dass wir festhalten, nach welchen Vereinbarungen wir
zusammenarbeiten. Jeder hat die Aufgabe die Einhaltung der Regeln zu begutachten und sollten diese Fehler versetzt werden, dann
soll das Team auf diese Verletzung aufmerksam gemacht werden.
Die Vereinbarungen helfen uns bei der Retro.
bilde kleine Gruppen mit nicht mehr als 4 Leute
jede Gruppe soll 3 - 5 Working Agreements erstellen
in Round-Robin Manier soll jede Gruppe Ihre Vereinbarungen auf
ein Flipchart schreiben
erklare der Gruppe, dass sie 3 - 7 Agreements auswahlen sollen

53 Pack

die vorgelesenen Zettel weg und schmeit sie weg, so dass es anonym ist
anschlieend eine Diskussion wie die Einstellungen Einfluss auf die Retro haben werden

54 fuhre

45


sollte es zu viele Vereinbarungen geben, dann mussen
die Agreements priorisiert werden
wenn es weniger als drei Agreements gilt, dann soll demokratisch
abgestimmt werden: Daumen hoch (stimme zu), Daumen seitlich

(Ich unterstutze
den Willen der Gruppe), Daumen runter (lehne
ab)

5.9 Aktivit
aten f
ur Gathering Data
5.9.1 Timeline
Dauer : 30 - 90 Minuten, langere Iteration und Projekt-Release

Beschreibung : Leute schreiben ihre Ideen, personliche


Erlebnisse und andere signifikante Erlebnisse auf Karten, welche wahrend einer Iteration, Release
oder Projekt passiert.
Zweck : Simuliere Erinnerungen was geschehen ist wahrend und auerhalb der
Arbeit. Erstelle ein Bild von der Arbeit von verschiedenen Parameter
erkenne Muster, wann sich die Energie-Level geandert haben
Schritte :

Wir werden eine Zeitleiste erstellen, um ein ganzes Bild uber


die gesamten Situation zu erfahren. Wir wollen die Ereignisse aus

mogliche
verschiedene Perspektiven.
splitte die Gruppe mit Leuten mit nicht mehr als 5 Leute (Affinitatsgruppen), verteile Stifte, Index-Karten und Sticky Notes

frage die Leute, dass Sie sich zurucklehnen


sollen und sich die Iterationen/Releases/Projekt genannt werden sollen55
achte auf den Level der Aktivitat: Wenn nix mehr geschieht, dann
ist es vorbei, wenn nach einer gewissen Zeit noch nix gekommen
ist, dann informiere dich bei den Leuten ob du Ihnen helfen kannst
wenn alle Karten auf die Wand gepostet wurden, dann sollen alle

daruber
nochmal einen Blick werfen. Es ist okay, wenn die Leute
noch neue Karten posten

5.9.2 Triple Nickels


Dauer : 30 - 60 Minuten, verwende dies bei der Datensammlung oder als Teil
von Was als nachstes gemacht werden sollen
Beschreibung : ...
Aktionen oder Vorschlage. Decke unwichtige Themen
Zweck : Erstelle Ideen fur
zum Projekt-Geschehen auf
Schritte :

55 erfasse

Ziel des Meetings ist es so viele Ideen wie moglich


zum Thema
XXX zu sammeln

jede erinnerungswurdige,
personliche
Erfahrungen

46

bilde Gruppen von nicht mehr als 5 Leuten in Gruppen und erinnere Leute daran auf dem Papier leserlich zu schreiben, so dass

auch andere Team-Leute die Informationen lesen konnen


erklare den Ablauf: In der ersten Runde hat jede Person 5 Minuten Zeit, um Ideen zum Thema XXX niederzuschreiben. Ziel sollen
die nachste Runde solmindestens 5 Ideen auf den Zettel sein. Fur
len weitere Ideen aufbauend auf den Ideen sein, die bereits auf
den Zettel sind
nach zehn Minuten gib ein Signal und sag den Leuten, dass sie das
Papier an die Person rechts weitergeben sollen und dann vorlesen
sollen
Debrief die Aktivitat: Was habt Ihr festgestellt, wahrend Ihr die

Ideen geschrieben habt? Was hat Euch dabei uberrascht?


Wurden

Eure Erwartungen erfullt?


Wie wurden die Erwartungen erfullt?
Was fehlt auf der List? Welche Themen und Ideen sollen weiter
untersucht werden?
5.9.3 Color Code Dots

Dauer : 5 - 20 Minuten, gut in Verbindung in der Timeline um Daten uber


Meinung in einer langeren Iteration, Release oder Projekt-Retro
Beschreibung : Leute benutzen Punkte, um auf der Timeline Hochs und Tiefs zu markieren
Zweck : Zeigt wie Leute bestimmte Ereignisse auf der Timeline erlebt haben
Schritte :

Nachdem alle Events in der Timeline dargestellt und von allen


angesehen wurden, ist es an der Zeit, die Ereignisse herauszufiltern, bei dem die Energie hoch und niedrig war
jeder der Teilnehmer bekommt zwei Klebepunkte in zwei Farben;
hohe Energie und welche fur
niedrige
Erklare welche Farbe fur
Energie steht
Nun soll jede Person die Punkte setzten, wo ein hoher Energielevel
war und wo es langsam abflachte

5.9.4 Mad Sad Glad

Dauer : 20 - 30 Minuten, sammle Daten uber


Gefuhle
wahrend einer Iteration,
Release oder Projektretro
Beschreibung : Leute benutzen farblich unterschiedliche Karten, um Zeiten zu beschreiben, wo sie Mad, Sad oder Glad waren

Zweck : Die Gefuhlten


Fakten sollen auf den Tisch gepackt werden
Schritte :

Lasst uns gemeinsam sehen, wie wir uns wahrend des Projektes

gefuhlt
haben und vielleicht konnen
wir Quellen entdecken, bei
den wir zufrieden und unzufrieden waren.

47

erklare das Poster mit den Labeling Mad, Sad und Glad; hab einen
alle greifbar zur Hand
Stapel mit farblichen Post-Its und Stiften fur
erklare, dass ihr x Minuten Zeit habt, um die Zeiten/Ereignisse
niederzuschreiben, wo ihr Euch Glad, Sad oder Mad wahrend des

Projekts, Iteration gefuhlt


habt; schreibt auf jede Karte ein Event

5.10 Weitere Aktivit


aten-Ideen
5.10.1 Talk Team-Driven Improvement with Retrospectives
Male deine eigenes Gutes Schiff (Team oder Firmenname)
Was gibt uns Wind in den Segeln?

Welcher Ankor halt uns zuruck?

Nach welchen Moglichkeiten


gucken wir?
Welche Gefahren gibt es?
Male deinen Superhelden:
Arbeite in Paare und male dein Team oder Firma als ein Cartoon Superheld
Super powers?
Schwachpunkte?
Welche Kumpanen brauchen wir?
Quadranten:
Wohin geht unsere Zeit? Vertikale Achse ist Spa, horizontale Achse welche
Zeit es genommen hat. Nimm ein Thema pro Quadranten.
Thinking hats:
schwarz: vorsichtig
weiss: Fakten
blau: Prozess
rot: Emotionen
Kreativitat
grun:
gelb: Vorteile

Emotions-Graph: Horizontale Achse ist Zeit, vertikale Achse ist Glucklichkeit


Star Fisch: Stop, Start, More, Keep, Less
Futurespective: Denke an Sprint + 1 und der war ein Erfolg. Warum ist der so
erfolgreich geworden?
Appreciations (Arbeit und Beteiligung loben) and Commiserations (Mitleid, Mit
gefuhl,
gut dass du es gemacht hast, aber du musst es nicht jedesmal machen)
Feedback Form: Anonym machen, dann wahlen es mehr Leute aus, man kann z.B.
Fragen ob Zeit gut genutzt wurde, Textfeld mit wertvollen Feedback, hat die Retro
Einfluss gehabt, wie fandet Ihr die folgende Aktivitat

48

5.11 Referenzen
retrospectives.com - einige gute Sachen
xp123.com - viele gute Ideen
retromat
core scrum

49

6 Scrum Test
Fragen: http://scrumsource.com/scrumexams.php, https://www.scrum.org/Assessments/
Open-Assessments
Videos: http://www.collab.net/services/training/agile_e-learning
weitere Folien: http://scrumtrainingseries.com/

6.1 The Product Backlog is ordered by:


A) Small items at the top to large items at the bottom.
B) Safer items at the top to riskier items at the bottom.
C) Least valuable items at the top to most valuable at the bottom.
D) Items are randomly arranged.
E) Whatever is deemed most appropriate by the Product Owner.
Solution: E

6.2 The three pillars of empirical process control are:


A) Respect For People, Kaizen, Eliminating Waste
B) Planning, Demonstration, Retrospective
C) Inspection, Transparency, Adaptation
D) Planning, Inspection, Adaptation
E) Transparency, Eliminating Waste, Kaizen
Solution: C

6.3 It is mandatory that the product increment be released to production at


the end of each Sprint.
A) true
B) false
Solution: B

50

6.4 Who should know the most about the progress toward a business
objective or a release, and be able to explain the alternatives most
clearly?
A) The Product Owner.
B) The Development Team.
C) The Scrum Master.
D) The Project Manager.
Solution: A:

6.5 Which two (2) things does the Development Team not do during the
first Sprint?
A) Deliver an increment of potentially shippable functionality.
B) Nail down the complete architecture and infrastructure.
C) Develop and deliver at least one piece of functionality.
D) Develop a plan for the rest of the project.
Solution: B, D

6.6 Who is on the Scrum Team?


A) The Scrum Master
B) The Product Owner
C) The Development Team
D) Project Manager
E) None of the above
Solution: A, B, C

6.7 Scrum Master is a management position?


A) true
B) false
Solution: A

51

6.8 The Development Team should have all the skills needed to
A) Complete the project as estimated when the date and cost are committed to the Product Owner.
B) Do all of the development work, but not the types of testing that require specialized
testing, tools, and environments.
C) Turn the Product Backlog items it selects into an increment of potentially shippable
product functionality.
Solution: C

6.9 An optimal Development Team has at least 5 members


A) To have enough coverage in case of illness or emergency
B) To ensure high productivity
C) To increase the reliability of their estimates
D) This is not required as long as the overall team maturity is high
E) This is not required in Scrum.
Solution: E

6.10 When multiple teams are working together, each team should maintain
a separate Product Backlog.
A) true
B) false
Solution: B

6.11 What is the recommended size for a Development Team (within the
Scrum Team)?
A) Minimal 7
B) 3 to 9
C) 7 plus or minus 2
D) 9
Solution: B

52

6.12 When many Development Teams are working on a single product,


what best describes the definition of done?
A) Each Development Team defines and uses its own. The differences are discussed and
reconciled during a hardening Sprint.
B) Each Development Team uses its own but must make their definition clear to all
other Teams so the differences are known.
C) All Development Teams must have a definition of done that makes their combined
work potentially releasable.
D) It depends.
Solution: C

6.13 When does the next Sprint begin?


A) Next Monday.
B) Immediately following the next Sprint Planning.
C) When the Product Owner is ready.
D) Immediately after the conclusion of the previous Sprint.
Solution: D

6.14 Which statement best describes the Sprint Review?


A) It is a review of the teams activities during the Sprint.
B) It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and
figure out what to do in the upcoming Sprint.
C) It is a demo at the end of the Sprint for everyone in the organization to provide
feedback on the work done.
D) It is used to congratulate the Development Team if it did what it committed to doing,
or to punish the Development Team if it failed to meet its commitments.
Solution: B

6.15 Development Team members volunteer to own a Sprint Backlog item:


A) At the Sprint planning meeting.
B) Never. All Sprint Backlog Items are owned by the entire Development Team, even
though each one may be done by an individual development team member.
C) Whenever a team member can accommodate more work.
D) During the Daily Scrum.
Solution: B

53

6.16 When is a Sprint over?


A) When all Product Backlog items meet their definition of done.
B) When the Product Owner says it is done.
C) When all the tasks are completed.
D) When the timebox expires.
Solution: D

6.17 What does it mean to say that an event has a timebox?


A) The event must happen at a set time.
B) The event must happen by a given time.
C) The event must take at least a minimum amount of time.
D) The event can take no more than a maximum amount of time.
Solution: D

6.18 What is the primary way a Scrum Master keeps a Development Team
working at its highest level of productivity?
A) By facilitating Development Team decisions and removing impediments.
B) By ensuring the meetings start and end at the proper time.
C) By preventing changes to the backlogs once the Sprint begins.
D) By keeping high value features high in the Product Backlog.
Solution: A

6.19 Who is required to attend the Daily Scrum?


A) The Development Team.
B) The Scrum team.
C) The Development Team and Scrum Master.
D) The Development Team and Product Owner.
E) The Scrum Master and Product Owner.
Solution: A

54

6.20 Who has the final say on the order of the Product Backlog?
A) The Stakeholders
B) The Development Team
C) The Scrum Master
D) The Product Owner
E) The CEO
Solution: D

6.21 Development Team membership should change:


A) Every Sprint to promote shared learning.
B) Never, because it reduces productivity.
C) As needed, while taking into account a short term reduction in productivity.
D) Just as it would on any development team, with no special allowance for changes in
productivity.
Solution: C

6.22 Which statement best describes Scrum?


A) A complete methodology that defines how to develop software.
B) A cookbook that defines best practices for software development.
C) A framework within which complex products in complex environments are developed.
D) A defined and predictive process that conforms to the principles of Scientific Management.
Solution: C

6.23 The CEO asks the Development Team to add a very important item
to the current Sprint. What should the Development Team do?
A) Add the item to the current Sprint without any adjustments.
B) Add the item to the current Sprint and drop an item of equal size.
C) Add the item to the next Sprint.
D) Inform the Product Owner so he/she can work with the CEO.
Solution: D

55

6.24 Which of the below are roles on a Scrum Team?


A) Development Team
B) Users
C) Customers
D) Product Owner
E) Scrum Master
Solution: A, D, E

6.25 Upon what type of process control is Scrum based?


A) Empirical
B) Hybrid
C) Defined
D) Complex
Solution: A

6.26 Scrum does not have a role called project manager.


A) true
B) false
Solution: A

6.27 Which statement best describes a Product Owners responsibility?


A) Optimizing the value of the work the Development Team does.
B) Directing the Development Team.
C) Managing the project and ensuring that the work meets the commitments to the
stakeholders.
D) Keeping stakeholders at bay.
Solution: A

6.28 An abnormal termination of a Sprint is called when?


A) When it is clear at the end of a Sprint that everything wont be finished.
B) When the Team feels that the work is too hard.
C) When Sales has an important opportunity.
D) When the Product Owner determines that it makes no sense to finish it.
Solution: D

56

6.29 What is the main reason for the Scrum Master to be at the Daily
Scrum?
A) To make sure every team member answers the three questions in the right team
member order.
B) He or she does not have to be there; he or she only has to ensure the Development
Team has a Daily Scrum.
C) To write down any changes to the Sprint Backlog, including adding new items, and
tracking progress on the burndown.
D) To gather status and progress information to report to management.
Solution: B

6.30 What is the maximum length of a Sprint?


A) Not so long that the risk is unacceptable to the Product Owner.
B) Not so long that other business events cant be readily synchronized with the development work.
C) No more than one calendar month.
D) All of these answers are correct.
Solution: D

6.31 How much work must a Development Team do to a Product Backlog


item it selects for a Sprint?
A) As much as it has told the Product Owner will be done for every Product Backlog
item it selects in conformance with the definition of done.
B) As much as it can fit into the Sprint.
C) The best it can do given that it is usually impossible for QA to finish all of the testing
that is needed to prove shippability.
D) Analysis, design, programming, testing and documentation.
Solution: A

6.32 The Development Team should not be interrupted during the Sprint.
The Sprint Goal should remain intact. These are conditions that foster
creativity, quality and productivity. Based on this, which of the
following is false?
A) The Product Owner can help clarify or optimize the Sprint when asked by the Development Team.

57

B) The Sprint Backlog and its contents are fully formulated in the Sprint Planning meeting and do not change during the Sprint.
C) As a decomposition of the selected Product Backlog Items, the Sprint Backlog changes and may grow as the work emerges.
D) The Development Team may work with the Product Owner to remove or add work
if it finds it has more or less capacity than it expected.
Solution: B

6.33 It is mandatory that the product increment be released to production


at the end of each Sprint.
A) True
B) False
Solution: B

6.34 Who is responsible for registering the work estimates during a Sprint?
A) The Development Team.
B) The Scrum Master.
C) The Product Owner.
D) The most junior member of the Team.
Solution: A

6.35 An organization has decided to adopt Scrum, but management wants


to change the terminology to fit with terminology already used. What
will likely happen if this is done?
A) Without a new vocabulary as a reminder of the change, very little change may actually happen.
B) The organization may not understand what has changed with Scrum and the benefits of Scrum may be lost.
C) Management may feel less anxious.
D) All answers apply.
Solution: D

58

6.36 The timebox for a Daily Scrum is?


A) The same time of day every day.
B) Two minutes per person.
C) 4 hours.
D) 15 minutes.
E) 15 minutes for a 4 week sprint. For shorter Sprints it is usually shorter.
Solution: D

6.37 The timebox for the complete Sprint Planning meeting is?
A) 4 hours.
B) 8 hours for a monthly Sprint. For shorter Sprints it is usually shorter.
C) Whenever it is done.
D) Monthly.
Solution: B

6.38 The purpose of a Sprint is to have a working increment of product


done before the Sprint Review.
A) True
B) False
Solution: A

6.39 The Development Team should have all the skills needed to:
A) Complete the project as estimated when the date and cost are committed to the Product Owner.
B) Do all of the development work, but not the types of testing that require specialized
testing, tools, and environments.
C) Turn the Product Backlog items it selects into an increment of potentially shippable
product functionality.
Solution: C

59

6.40 Why is the Daily Scrum held at the same time and same place?
A) The place can be named.
B) The consistency reduces complexity and overhead.
C) The Product Owner demands it.
D) Rooms are hard to book and this lets it be booked in advance.
Solution: B

6.41 The maximum length of the Sprint Review (its timebox) is:
A) 2 hours.
B) 4 hours for a monthly Sprint. For shorter Sprints it is usually shorter.
C) As long as needed.
D) 1 day.
E) 4 hours and longer as needed.
Solution: B

6.42 During the Daily Scrum, the Scrum Masters role is to:
A) Lead the discussions of the Development Team.
B) Make sure that all 3 questions have been answered.
C) Manage the meeting in a way that each team member has a chance to speak.
D) Teach the Development Team to keep the Daily Scrum within the 15 minute timebox.
E) All of the above.
Solution: D

6.43 What is the role of Management in Scrum?


A) To continually monitor staffing levels of the Development Team.
B) To monitor the Development Teams productivity.
C) Management supports the Product Owner with insights and information into high
value product and system capabilities. Management supports the Scrum Master to
cause organizational change that fosters empiricism, self-organization, bottom-up
intelligence, and intelligent release of software.
D) To identify and remove people that arent working hard enough.
Solution: C

60

6.44 What is more important objective of the Backlog Refinement Meeting?


A) To get precise estimates.
B) To get a better understanding of upcoming work and combine it to from larger PBIs.
C) To get better understanding of upcoming work and split it to from smaller PBIs.
D) To get a better understanding of upcoming work and create a monolithic detailed
design document.
Solution: C

6.45 Whats the difference between acceptance criteria and definition of


done?
A) Theres no difference
B) Definition of done applies globally to all PBIs for a product, while acceptance criteria
pertain to specific items. Acceptance criteria could also from the basis of new stories.
Solution: B

6.46 Whats the difference between the Product Backlog and the Sprint
Backlog?
A) There is no difference.
B) The Product Backlog contains features, while the Sprint Backlog contains bugs.
C) The Product Backlog contains everything we might ever work on, while the Sprint
Backlog contains just the things well work on during one Sprint.
Solution: C

6.47 Should the team expect to know all the tasks necessary to complete
the committed PBIs during the Sprint Planning Meeting?
A) No. According to Agile Project Management with Scrum (Schwaber 2004), only 60% of
the tasks are likely to be identified during the Sprint Planning Meeting. Other tasks,
such as unanticipated dependencies, will be discovered during Sprint Execution.
B) Yes. The most important thing is to make sure everyone is busy every hour of the
entire Sprint.
Solution: A

6.48 What is the longest allowable iteration, or Sprint, in Scrum?


A) 30 days, or one calendar month, but one or two weeks is recommended.
B) Six weeks.
C) It depends how much fork was committed to the Sprint.
Solution: A

61

6.49 In Scrum, is it acceptable to postpone testing until another Sprint?


A) No. In Scrum teams attempt to build a potentially shippable product increment every Sprint.
B) Yes. We canot learn how to code and test in one Sprint.
Solution: A

6.50 How can one Scrum team builda potentally shippable product
increment within one Sprint? (Chose six)
A) By using modern software engineering approaches such as test-driven development
(TDD), continous design, continuous integration, merciless refactoring.
B) They cannot do it. Its too difficult to code and test in one Sprint.
C) By improved collaboration techniques: pair programming, working in a team room,
and eliminating over the wall hand offs.
D) By checking code in multiple times per day, and by reducing or eliminating branches
in the version control system.
E) By organizing teams around features rather than architectural components.
F) By full-time allocation to one team, focusing on only one set of Sprint goals.
G) By agreeing to a smaller amount of feature scope at the Sprint Planning Meeting,
allowing more time for integration, testing, and fixing during each Sprint.
Solution: A, C, D, E ,F, G:

6.51 A 30-day Sprint uses a 1-day timebox for the Sprint Planning Meeting.
How long should the Sprint Planning Meeting be for a two-week
Sprint?
A) A 4 hours maxiumum.
B) 1 day maxium.
C) 1 hour maxiumum.
D) 15 minutes maxium.
Solution: A

6.52 To avoid technical debt, what should the team write down in their
definition of done? (Choose seven)
A) Nothing. It is not helpful to write down important agreements.
B) All previous regression tests pass.
C) Checkout and build are fully reproducible, typically with one ot two commands.

62

D) Duplicate code has been removed through refactoring.


E) Code has been written by pairs, or at least reviewed by other team members.
F) Manual, exploratiy testing has been conducted.
G) Regression tests for new functionality run automatically with every build.
H) Messy and poorly designed code has been cleaned up through refactoring.
Solution: B, C, D, E, F, G, H:

6.53 Do you agree the PBI will need some testing tasks?
A) Yes, if the team learns to use TDD, some of this will be handled implicitly and repeatably. Manual exploratory testing is also important.
B) No. Testing should be done at the of the project. Theres always enough time at the
end of the project.
Solution: A

6.54 Who is responsible for committing to work in the Sprint Planning


Meeting?
A) The Project Manager
B) The ScrumMaster
C) The Team
Solution: C

6.55 Which is a better measure of progress?


A) How much work has been started.
B) How much work has been finished.
Solution: B

6.56 How many Sprints are planned during a Sprint Planning Meeting?
A) All the Sprints left in the project. We know more on the first day of a project than we
will know in the future.
B) One sprint only. Once the Team has established a consistent velocity, the Product
Owner can use this velocity to make longer range forecasts and release plans.
C) Four Sprints.
Solution: B

63

6.57 Who must attend the Sprint Planning Meeting? (Choose three)
A) Outside stakeholders.
B) The Scrum Development Team.
C) The ScrumMaster.
D) The Product Owner.
E) The manager of the team members.
Solution: B, C, D

6.58 What does a Scrum Team attempt to do during its very first Sprint?
A) Analyze, design, build, integrate, and test a potentially shippable product increment,
even if its features are initially simple and small.
B) Analyze requirements only.
C) Analyze requirements, and put together infrastructure only.
Solution: A

6.59 Which of the following are true regarding Product Backlog Items
(PBIs) and tasks? (Choose four)
A) A PBI is more about the what than the how. A task is more about the how.
B) A well-formed PBI represents distinct business value, ideally from the customers
perspective. A task is just a step by team to create that value.
C) A task should be no bigger than one day of work.
D) Some Scrum Teams who have learned how to define small enough PBIs no longer
find tasks necessary.
E) The Product Backlog should contain tasks.
Solution: A, B, C, D

6.60 Which of the following are explicitly defined questions in the Daily
Scrum Meeting?(Choose three)
A) What will I do today (or before the next Scrum meeting)?
B) What time is the next Daily Scrum Meeting?
C) What impeded me (blocks my progress, reduces my effectiveness, etc.)?
D) What I do yesterday (or since the last Scrum meeting)?
E) What are my actuals compared to my estimates (in hours or days)?
Solution: A, C, D

64

6.61 Is TDD part of Scrum?


A) Yes. Scrum is a complete methodology containing everything you need to succeed.
B) No. Scrum is only a feedback framework. It does not specify particular technical
practices.
Solution: B

6.62 The Daily Scrum is one technique to encourage team collaboration.


Which physical arrangement encourage collaboration the most?
A) In a typical classroom set up, with all chairs facing the front of the room.
B) Standing in an unobstructed circle, without laptops or phones.
C) In a typical conference room, with large comfortable chairs encouraging people to
stay longer.
Solution: B

6.63 What is a good size for a Sprint task?


A) 2-3 people 2-3 days, so that every Product Backlog Item equals one Sprint Task.
B) One person-day or less, so other team members can easily detect when a task is
stuck.
Solution: B

6.64 During the Sprint Execution, a Scrum Team uses information


radiators such as the taskboard or sometimes a Sprint Burndown
Chart. Who are these for?
A) Outside managers, so they can intervene as soon as they dont like how a Sprint is
going.
B) The Team, so they can take responsibility for their own work habits.
Solution: B

6.65 In an organisation that embraces Agile values, who would be


responsible for tool selection and configuration?
A) The Teams, who would have to coordinate with each other.
B) The ScrumMasters, who would have to coordinate with each other.
Solution: A

65

6.66 When is Sprint execution completed?


A) When all tasks are complete.
B) It depends.
C) When call committed Product Backlog Items meet their definition of done.
D) When the timebox expires.
Solution: D

6.67 Whats the first thing we should see at the Sprint Review Meeting?
A) A live demonstration of potentially shippable (properly tested) product increment.
B) PowerPoint slides describing project status.
C) Design artifacts such as UML diagrams and architectural drawings of things that
havent build and tested yet.
D) A report about what happened during the Sprint.
Solution: A

6.68 When were the PBIs committed to the Sprint?


A) During the Backlog Refinement Meeting.
B) During the Sprint Planning Meeting.
C) During the Release Planning Meeting.
D) During the Daily Scrum Meeting.
Solution: B

6.69 To whom should the stakeholder direct his complaint about priorities?
A) Any developer on the team.
B) The Product Owner.
Solution: B

6.70 Does Scrum have a concept of a partially done PBI?


A) Yes, its important to quantify everything.
B) No, its important to avoid self deception.
Solution: B

66

6.71 When should a PBI be considered done?


A) When the Product Owner declares it meets the definition of done and any acceptance
criteria negotiated with the team.
B) When all its tasks have been completed.
Solution: A

6.72 What should a PO usually do with a partially complete PBI?


A) Return the entire PBI wherever he wants within the Product Backlog.
B) Try to count the part thats done and put the rest back into the Product Backlog.
C) Call it done but log a defect against it in a seperate tracking system.
Solution: A

6.73 Whats a good use for velocity?


A) To help the Product Owner make forecasts about what might be done by a given
release date.
B) To specify exactly how much work the Team should commit into the next Sprint.
C) To guide a conditional reward system for employees.
Solution: A

6.74 Henry Ford discovered the more adapted you become to an


unchanging situation, the less adaptable you are. In an unvertain world,
which is a wiser area for a ScrumMaster to focus on?
A) An efficient team. More! Better! Faster!
B) A learning team. A learning team can become more efficient when necessay.
Solution: B

6.75 Is restrospective safety enhanced by inviting outside spectators who


werent working on the team?
A) Yes. Its just like watching a hockey game.
B) No. If the team needs to discuss issues with outsiders its usually better to do this
after the retrospective.
Solution: B

67

6.76 Is a safety check by itself a complete Sprint Retrospective?


A) Yes.
B) No.
Solution: B

6.77 In Scrum, how often is the Sprint Retrospective Meeting conducted?


A) Every day.
B) Every Sprint.
C) Every project.
Solution: B

6.78 Groups often fool themselves with pseudo-solutions that dont really
change anything. Which of the following are more effective? (Choose
three)
A) Make an agreement that will be vetoed by someone who is not present.
B) Agree to try harder from now on.
C) A volunteer agress to a specific action by a specific date.
D) Team writes concrete adjustments to its working agreements.
E) Team agrees to try a different approach as an experiment for one Sprint.
F) Delegate a job to someone who wont have time to do it.
Solution: C, D, E

6.79 Which of the following best describes the approach for determining the
iteration (timebox) length?
A) Iterations (timeboxes) should always be 30 days
B) The team determines iteration (timebox) length by dividing the total number of story
points by the average velocity of the team
C) Iterations (timeboxes) should always be two weeks
D) The team should agree on the length of the iteration (timebox), taking the size and
complexity of the project into consideration
Solution: D

68

6.80 Who is responsible for prioritizing the product backlog?


A) PO
B) Project Manager
C) Lead Developer
D) Business Analyst
Solution: A

6.81 What are the advantages of maintaining consistent iteration (timebox)


length throughout the project?
A) It helps to establish a consistent pattern of delivery
B) It helps the team to objectively measure progress
C) It provides a consistent means of measuring team velocity
D) All of the above
Solution: D

6.82 Why is it important to trust the team?


A) High trust teams do not have to be accountable to each other
B) High trust teams do not require a user representative
C) The Project Manager does not then have to keep a project schedule
D) The presence of trust is positively correlated with the team performance
Solution: D

6.83 An effective workshop facilitator will always ...


A) Involve the whole project team in all project workshops
B) Agree the process and participants of the workshop with the workshop owner before
the workshop
C) Involve only those team members who will commit to doing further work after the
workshop
D) Act as a proxy for any invited participant who is unable to attend the workshop on
the day
Solution: B

69

6.84 If a timebox (iteration) plan needs to be reprioritised in a hurry, who


should re-prioritise?
A) The developers alone (they know what the customer wants).
B) The Product Owner (the developers would only choose the easy things as top priority).
C) The Project Leader (they can give an independent, pragmatic view).
D) The whole team including Product Owner and developers (together they can consider both business value and practicality).
Solution: D

6.85 What is the effect of having a large visible project plan on a wall?
A) It removes the need to create any other reports for management.
B) It continuously communicates progress within the team and to other stakeholders.
C) It allows the Project Manager to allocate tasks to specific team members.
D) It is restrictive, as it does not allow the team to innovate and change.
Solution: B

6.86 How should work be allocated to the team in an Agile project?


A) The Team Leader (Scrum Master) should allocate specific tasks to individuals
B) Tasks should be randomly allocated to team members, using Planning Poker
C) Team members should self-select tasks appropriate to their skills
D) The most complex tasks should be allocated by the Team Leader (Scrum Master)
Solution: C

6.87 What should the developers do if the customer representative is


repeatedly too busy to be available?
A) Continue the work, record the assumptions and ask the customer later for input.
B) Send the customer a written warning that the end product will be completed on
time, but may not meet their needs
C) Allow the Business Analyst to take on the role of Proxy Customer Representative
D) Draw the problem to the attention of the Scrum Master (Team Leader)
Solution: D

70

6.88 Which one of the following is an important feature of the daily


stand-up / wash up / Scrum meeting?
A) Everyone is expected to stand for the whole time, to keep the meeting short
B) The meeting must be kept short and well structured
C) The meeting should ensure that it is clear to all which team members are not performing
D) No-one is allowed to leave the stand-up meeting until all problems raised have been
solved
Solution: B

6.89 Who should attend the stand-up meetings?


A) Sponsor and Executive Management only
B) Project Manager and Technical Leads only
C) Project Leader and Customer Representatives only
D) The entire team
Solution: D

6.90 One of the development stages you would expect to see a team go
through is:
A) Storming
B) Warming
C) Cloning
D) Yawning
Solution: A

6.91 When estimating is done for a project, the developers should:


A) Be fully involved in the estimating process
B) Be in total control of the estimating process
C) Be consulted after the Team Leader (Scrum Master) has made the estimates for the
teams work
D) Not make estimates unless velocity is already known
Solution: A

71

6.92 During an iteration (sprint) (timebox) the developers should be:


A) Able to contact the customer to clarify aspects of the work
B) Completely uninterrupted by the customer
C) In twice-daily contact with the customer
D) Able to work without needing to disturb the customer
Solution: A

6.93 The Agile Manifesto states the following values:


A) People are more important than contracts.
B) Working software should have priority over comprehensive documentation.
C) Plans should have priority over ability to respond.
D) Contracts should be negotiated which allow control over the people.
Solution: B

6.94 A sustainable pace means ...


A) If the team members work long hours regularly they will get used to it, and be able
to sustain it
B) A 40 hour week is only for the weaker members of the team. Others can do more.
C) The team should establish a velocity which can be sustained within normal working
hours
D) Working long hours is the only way to deliver on time
Solution: C

6.95 A burn-down chart shows ...


A) The energy level and velocity of the team
B) The remaining work (effort, points) to complete before the iteration (timebox) end
C) The number of hours worked by each team member during the iteration (timebox)
D) The rate of spending of the budget for a project
Solution: B

72

6.96 The reason for holding regular Retrospectives is:


A) It allows the team to take a necessary break from work
B) It gives management information to use in team members performance reviews
C) It allows learning which can be used to improve team performance during the project
D) It prevents deviation from the process which the team has been following
Solution: C

6.97 How could maintainability of the developing product be improved in a


development team?
A) Apply standard design patterns
B) All of these
C) Make refactoring a common practice
D) Ensure unit testing is included in the done criteria
Solution: B

6.98 Agile methods are described as adaptive because...


A) Agile teams have the empowerment to frequently respond to change and to learn on
a project by changing the plan
B) The rate of development progress on an Agile project is constantly tracked to allow
adaptation
C) Project Managers are not needed in Agile methods because teams are self-organising
D) Workshops held at the beginning and the end of every iteration (timebox) allow the
team to adapt the product specification
Solution: A

6.99 What is one difference in responsibility between a Project Manager


and a Scrum Master (Team Leader) in an Agile project?
A) None. Its basically the same. Scrum Master (or Team Leader) is just a better term
than Project Manager in an Agile project
B) The Project Manager creates the detailed delivery plans while the Team Leader monitors execution within the team
C) Project Manager communicates with project governance authorities when necessary
D) The Project Manager monitors the realisation of benefits in the business case.
Solution: C

73

6.100 The responsibilities of a Product Owner will include ...


A) Business processes diagramming
B) Prioritizing requirements
C) Managing the project budget
D) All of these
Solution: B

6.101 What is the goal of a Sprint Retrospective? Please select the


option(s) that NOT adhere to the purpose of this important Scrum
meeting:
A) Discuss the impediments raised by the Development Team during the last sprint,
and make a plan for implementing improvements.
B) Refinement of epics nominated by the Product Owner for the next couple of sprints,
in order to promote reliable release planning.
C) Verification of how well the product increment satisfies the applicable user stories in
the Product Backlog.
D) Discuss the interaction within the Scrum Team, and agree upon measures to improve
the collaboration.
Solution: B, C

6.102 The Product Owner role and Scrum Master role are never included in
the Development Team size count.
A) True
B) False
Solution: B

6.103 Scrum allows for re-estimating tasks based on growing insight. Which
Scrum team member is responsible for updating the estimates of the
work during a Sprint?
A) Development Team
B) SM
C) most senior member of the Team.
D) PO
Solution: A

74

6.104 Timeboxing is an important principle of Scrum. What is the exact


meaning of a meeting having a time-box?
A) must happen by a given time.
B) must happen at the same time every day.
C) must take at least a minimum amount of time.
D) can take no more than a maximum amount of time.
Solution: D

6.105 Resolving internal conflicts is NOT the responsibility of the


Development Team.
A) True
B) False
Solution: B

6.106 What is NOT an attribute of the Development Team?


A) Members of Development Teams are exchanged frequently to promote continuous
learning and cross-functionality.
B) The Development Team provides input for the Sprint Planning Meeting with respect
to the projected capacity during the upcoming Sprint.
C) The Development Team may re-negiotiate with the Product Owner the work needed to deliver the agreed upon sprint goal during the running sprint, when more is
learned.
D) The Development Team update their estimate of the total amount of remaining work
for completion of the running sprint, so that it can be plotted on the Sprint Burndown
Chart.
Solution: A

6.107 One of the benefits from Scrum is that the Development Team
doesnt have to write detailed specifications anymore.
A) True
B) False
Solution: B

75

6.108 What are the major properties of a cross-functional Development


Team?:
A) The team is able to complete the project according to the planning, after the date and
cost are committed to the Product Owner.
B) The team has all the skills on board, needed to accept collective ownership for the
next product increment.
C) All team members have a the knowledge and experience needed to deliver the correct product increment.
D) The team comprises competence teams dedicated to particular domains like specialized testing or business analysis, to facilitate deliverance of the highest business
value.
Solution: B

6.109 A Scrum team thought it a good practice to clearly define a checklist


of items that must be completed before calling a story completed.
What artifact are they likely to be using for this?
A) Burndown chart
B) Definition of done
C) Product backlog
D) Sprint backlog
Solution: B

6.110 A Sprint just concluded and it was a disaster. None of the planned
stories completed and the review had to be cancelled. Senior
management wants to establish accountability for this. Who is
ultimately accountable for the success or failure of a Scrum team?
A) Product Owner
B) Scrum Master
C) Senior Management
D) Team
Solution: D

76

6.111 A team member from a Scrum team feels that a senior technical
architect from another team may have some valuable insights and
feedback about the product. Which is the best forum to solicit such
feedback?
A) Daily Scrum
B) Sprint Planning
C) Sprint Retrospective
D) Sprint Review
Solution: D

6.112 At the end of each working day, the team members update the
number of hours remaining on the tasks on a white board. The Scrum
Master then sums up the hours and plots them on a chart. What is
the name of this chart?
A) Burndown chart
B) Burnup chart
C) Niko-Niko chart
D) Parking lot diagram
Solution: A

6.113 How long should it take a five member Scrum team to finalize the
Sprint plan for a three week Sprint?
A) One to three hours
B) Three to six hours
C) Six to twelve hours
D) Fifteen hours
Solution: B (Sprint planning should ideally take one to two hours per week of Sprint
duration)

6.114 A Scrum team realizes that it may be late in delivering a component


that another Scrum team is waiting for. What is the best forum to
discuss this issue and find a resolution?
A) Daily scrum of either team
B) Scrum-of-Scrum
C) Sprint review
D) Sprint retrospective
Solution: B

77

6.115 What is an assertion of the Agile manifesto?


A) We value contract negotiation over customer collaboration.
B) We value following a plan over responding to change.
C) We value processes and tools over customer individuals and interaction.
D) We value working software over comprehensive documentation.
Solution: D

6.116 What is the best way to improve communications in a distributed


Scrum team?
A) Appointing a single point of contact for communication across locations
B) Co-locating the entire team for a release planning session
C) Establish a clear audit trail for all communication on the project
D) Introduce additional sign-offs on the project to ensure oversight
Solution: B

6.117 What is the best time to refactor code on a project?


A) Continuously and at the earliest possible opportunity
B) During hardening iterations
C) During the last iteration
D) When the Product Owner decides to schedule it
Solution: A

6.118 In the past eight Sprints, the team has completed 85 story points
worth of work altogether. The team has been asked to start working
on a new project which is estimated at 64 story points. How many
Sprints would be needed to complete this project?
A) Five
B) Seven
C) Eight
D) Ten
Solution: B,The velocity of the team is 85/8. The number of Sprints required to complete
the project is 64/velocity, which works out to be slightly above six. Hence seven is the
most reasonable answer.

78

6.119 Whats the primary goal of Agile development?


A) Added value of working software.
B) Delivering software every Quarter.
C) Collocation of the team.
D) Processes, Documentation, Contracts, and limited change.
Solution: A

6.120 The correct sequence of events in using Scrum framework is as


follows:
A) Release Planning, Sprint Planning, Sprint, Sprint Retrospective, Daily Scrum, and
Sprint Review.
B) Release Planning, Sprint Planning, Sprint, Daily Scrum, Sprint Review, and Sprint
Retrospective.
C) Sprint Planning, Release Planning, Sprint, Sprint Retrospective, Daily Scrum, and
Sprint Review.
D) Release Planning, Sprint Planning, Daily Scrum, Sprint, Sprint Review, and Sprint
Retrospective.
Solution: B

6.121 Who is the most important member of the Scrum Team?


A) The ScrumMaster.
B) The Team.
C) The Stakeholder.
D) The Product Owner.
Solution: D

6.122 Who has the authority to change or cancel a Sprint?


A) The team members.
B) The Scrum Master.
C) The Product Owner.
D) The Project Manager.
Solution: C

79

6.123 If the Team determines that it has overcommitted itself for a Sprint,
who should be present when reviewing and adjusting the Sprint goal
and work?
A) The ScrumMaster, Project Manager, and Team.
B) The Team.
C) The Product Owner and Team.
D) The Product Owner and all stakeholders.
Solution: C

6.124 Which of the following processes reflects Agile Development?


A) Analysis, Design, Development, Testing, Documentation, Training, Implementation
and Maintenance.
B) Vision, Release Planning, Product Backlog, Sprint Planning, Sprint Backlog, Daily
Scrum Meeting, Sprint Review, Sprint Retrospective.
C) Analysis, Design, Code, and Test.
D) Release Planning, Sprint Planning, Daily Scrum, Sprint, Sprint Review, and Sprint
Retrospective.
Solution: B

6.125 What does the Sprint Backlog consist of?


A) User Stories.
B) Use Cases.
C) Tasks.
D) Test cases.
Solution: A

6.126 What happens when the Sprint is cancelled?


A) The Scrum Team disbands immediately.
B) The complete Sprint Backlog is put back to the Product Backlog.
C) The completed Sprint Backlog items are evaluated for a release and incomplete items
are discarded.
D) The completed Sprint Backlog items are evaluated for a release and incomplete items
are put back to the Product Backlog.
Solution: D

80

6.127 What does the BurnDown Chart represent?


A) Work completed by the Scrum Team.
B) Work remaining to be completed in the Sprint Backlog.
C) Work remaining to be completed in the Product Backlog.
D) Work completed in the Sprints completed to date.
Solution: B

6.128 What is the Time-box for the Sprint Retrospective?


A) As long as required.
B) 1 hour.
C) 2 hours.
D) 3 hours.
Solution: D

6.129 Which statement is an incorrect assessment of the Product Owner?


A) The Product Owner plays a dual role, Product Owner and Scrum Master.
B) The Product Owner is the only person responsible for the Product Backlog.
C) The Product Owner prioritizes the Product Backlog
D) The Product Owner is one person not a committee.
Solution: A

6.130 When should the Product Owner ship or implement a Sprint


increment?
A) At the end of every Sprint.
B) When the Team feels is done with every Sprint.
C) Whenever the increment is free of defects.
D) When it makes sense.
Solution: A

81

6.131 How much work must a Scrum Team do to a Product Backlog it


selects for a Sprint?
A) As much work as the Team can fit into a Sprint.
B) All of the analysis, design, development, testing and documentation work.
C) The best amount of work the Team can do given that is usually impossible for QA to
finish all of the testing that is needed to prove it can be shipped.
D) As much work as it has told the Product Owner will be done for every Product
Backlog item it selects.
Solution: D

6.132 The Scrum Team is most productive if it is not interrupted during a


Sprint. As a result of...
A) The Spring Backlog emerges to reflect the work to develop the committed Product
Backlog items.
B) The Spring Backlog can only change with approval from the product owner.
C) The Sprint Backlog is devised during the Sprint Planning and should not need changing thereafter.
D) The Sprint Backlog is never changed.
Solution: B

6.133 What is the best term to define the function of the ScrumMaster?
A) Customer.
B) Developer.
C) Servant Leader.
D) Stakeholder.
Solution: C

6.134 When is a Sprint over?


A) When all Sprint Backlog items meet their definition of done.
B) When all the tasks are completed.
C) When the Product Owner says it is done.
D) When the time-box expires.
Solution: D

82

6.135 What part of the Sprint Backlog is used for the Sprint burndown
chart?
A) The percentage of work completed by each Team member.
B) The number of Product Backlog items completed by all the Team members.
C) The actual time spent on each task by each team member.
D) The remaining time required to complete each task by each team member.
Solution: D

6.136 Which objectives are covered as part of Sprint Planning?


A) Updating the scope of the release with all Sprints, end dates, and costs.
B) Recalculating empirical velocity, adjusting team capacity accordingly, and projecting
end dates.
C) Reviewing current functionality that binds the software solution.
D) Understanding what functionality the Product Owner desires within the next Sprint
and figuring out how to do it.
Solution: D

6.137 If the product effort is estimated to be 1000 hours, what is the time
that is recommended for release planning.
A) 100 hours.
B) 50% of the effort.
C) 1000 hours.
D) 15-20% of the effort.
Solution: D

6.138 Assuming a 2-week Sprint, What is the Time-box for the Sprint
Review?
A) 2 hours at the end of every sprint.
B) 15 minutes.
C) However long is needed.
D) 4 hours.
Solution: A

83

6.139 Drawing a trend line from previous completed work on a release


burndown chart indicates.
A) When the project will be over if the Product Owner removes work that is equal in
effort to any new work that is added.
B) Cost of the project.
C) When all Sprint Backlog tasks will be completed and the Scrum Team will be released for other work.
D) When the work remaining will be completed if nothing changes.
Solution: D

6.140 What is the Release Burndown?


A) A graph indicating what has been completed by the Scrum Team.
B) What has been completed by the Scrum Team to date.
C) The work remaining to be completed by the Product Owner.
D) A measure of the remaining Product Backlog across the time of a release plan.
Solution: D

6.141 Who determines when it is appropriate to update the Sprint Backlog


during the Sprint?
A) The Team.
B) The Scrum Master.
C) The Product Owner.
D) The Scrum Team.
Solution: C

6.142 The following artifacts are critical to the success of Agile


Development:
A) Status Report, Design Document, and Test Results.
B) Scrum Master, Product Owner, and Delivery Team.
C) Product Backlog, Sprint Backlog, and BurnDown Chart.
D) Vision, Release Planning, Product Backlog, Sprint Planning, Sprint Backlog, Daily
Scrum Meeting, Sprint Review, Sprint Retrospective.
Solution: C

84

6.143 What happens when the Sprint is cancelled?


A) The Scrum Team disbands immediately.
B) The complete Sprint Backlog is put back to the Product Backlog.
C) The completed Sprint Backlog items are evaluated for a release and incomplete items
are discarded.
D) The completed Sprint Backlog items are evaluated for a release and incomplete items
are put back to the Product Backlog.
Solution: D

6.144 More than one Scrum Team is working on a single project or release.
How should the Product Backlog be arranged?
A) A separate Product Backlog is constructed for each Scrum Team. All of the increments are integrated at the end in an integration Sprint
B) All Scrum Teams work from a common Product Backlog and integrate their work
every sprint
C) Only one Scrum Team should work on Scrum project
D) Scrum Teams should have their separate Product Backlogs.
Solution: B

6.145 What is the primary responsibility of the ScrumMaster?


A) To Prioritize the Product Backlog.
B) To manage the Scrum Team.
C) To work with the Product Owner to develop the Product Backlog.
D) To remove any impediments the Scrum Team encounters during their work.
Solution: D

6.146 What are the two primary ways a Scrum Master keeps a Development
Team working at its highest level of productivity?
A) By facilitating Development Team decisions
B) By removing impediments that hinder the Development Team
C) By ensuring the meetings start and end at the proper time
D) By keeping high value features high in the Product Backlog
Solution: A, B

85

6.147 The Product Backlog is ordered by:


A) Size, where small items are at the top and large items are at the bottom.
B) Risk, where safer items are at the top, and riskier items are at the bottom
C) Least valuable items at the top to most valuable at the bottom.
D) Items are randomly arranged.
E) Whatever is deemed most appropriate by the Product Owner.
Solution: E

6.148 The length of a Sprint should be:


A) Short enough to keep the business risk acceptable to the Product Owner.
B) Short enough to be able to synchronize the development work with other business
events.
C) No more than one calendar month.
D) All of these answers are correct.
Solution: D

6.149 Who is responsible for managing the progress of work during a Sprint?
A) The Development Team
B) The Scrum Master
C) The Product Owner
D) The most junior member of the Team
Solution: A

6.150 The Development Team should not be interrupted during the Sprint.
The Sprint Goal should remain intact. These are conditions that
foster creativity, quality and productivity. Based on this, which of the
following is FALSE?
A) The Product Owner can help clarify or optimize the Sprint when asked by the Development Team.
B) The Sprint Backlog is fully formulated in the Sprint Planning meeting and does not
change during the Sprint.
C) As a decomposition of the selected Product Backlog Items, the Sprint Backlog changes and may grow as the work emerges.
D) The Development Team may work with the Product Owner to remove or add work
if it finds it has more or less capacity than it expected.
Solution: B

86

6.151 When many Development Teams are working on a single product,


what best describes the definition of done?
A) Each Development Team defines and uses its own. The differences are discussed and
reconciled during a hardening Sprint.
B) Each Development Team uses its own but must make their definition clear to all
other Teams so the differences are known.
C) All Development Teams must have a definition of done that makes their combined
work potentially releasable.
D) It depends.
Solution: C

6.152 Who should know the most about the progress toward a business
objective or a release, and be able to explain the alternatives most
clearly?
A) The Product Owner
B) The Development Team
C) The Scrum Master
D) The Project Manager
Solution: A

6.153 What is the role of Management in Scrum?


A) Continually monitor staffing levels of the Development Team.
B) Monitor the Development Teams productivity.
C) Support the Product Owner with insights and information into high value product
and system capabilities. Support the Scrum Master to cause organizational change
that fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of software.
D) Identify and remove people that arent working hard enough.
Solution: C

6.154 Which two (2) things does the Development Team do during the first
Sprint?
A) Deliver an increment of releasable software.
B) Determine the complete architecture and infrastructure for the product.
C) Develop and deliver at least one piece of functionality.

87

D) Develop a plan for the rest of the release.


E) Create the complete Product Backlog to be developed in subsequent Sprints.
Solution: A, C

6.155 When might a Sprint be abnormally terminated?


A) When it becomes clear that not everything will be finished by the end of the Sprint.
B) When the Development Team feels that the work is too hard.
C) When the sales department has an important new opportunity.
D) When the Sprint Goal becomes obsolete.
Solution: D

6.156 The CEO asks the Development Team to add a very important
item to a Sprint that is in progress. What should the Development
Team do?
A) Add the item to the current Sprint without any adjustments.
B) Add the item to the current Sprint and drop an item of equal size.
C) Add the item to the next Sprint.
D) Inform the Product Owner so he/she can work with the CEO.
Solution: D

6.157 Sprint Backlog is ultimately owned by


A) The product owner
B) The scrum master
C) The stakeholders
D) The scrum team
Solution: A

6.158 During a Scrum of Scrums approach for a project, what best defines
the definition of done?
A) Each Team define and uses its own.
B) Each Team users its own but must make it clear to all other Teams.
C) All teams must use the same definition.
D) It depends.
Solution: B

88

6.159 The used metric to estimate with Planning Poker is


A) Numeric sizing (1..10)
B) T-short sizes (XS, S, M, ...)
C) The Fibonacc sequence
D) Person hours
Solution: C

6.160 What are the most critical items to start a Scrum Project?
A) Scrum Team and Stakeholders
B) Scrum Team, Product Backlog, Scrum Master
C) Product Backlog, Scrum Team, Scrum Master, and Product Owner
D) Time, Scope, Budget, and Quality
Solution: C

6.161 During a Sprint, when is a new work or further decomposition of work


to be added to the Sprint Backlog?
A) During the Daily Scrum after the Development Team approves them
B) When the Scrum Master has time to enter them
C) Whent the Product Owner identifies a new work
D) As soon as possible after they are identified
Solution: D

6.162 What is the BEST length of an iteration in Scrum?


A) 1 week
B) There is no ideal iteration length. It depends on the project and can vary.
C) 2 weeks
D) 1 month
Solution: B

89

6.163 Items in the Product Backlog tend to be:


A) Smaller than the items in the Sprint Backlog
B) Larger than the items in the Sprint Backlog
C) Usually much smaller than related Sprint Backlog Items, but it depends
D) The same size as the items in the Sprint Backlog
Solution: B

6.164 What are the critical items to start a Scrum Project?


A. Scrum Team and Stakeholders B. Scrum Team, Product Backlog, Scrum Master C.
Product Backlog, Scrum Team, Scrum Master, and Product Owner D. Time, Scope, Budget, and Quality
A) A and D.
B) C.
C) A, B, and C.
D) A and B.
Solution: B

6.165 What is the ultimate goal of the Scrum Team?


A) To prioritize the Sprint Backlog.
B) To complete the Product Backlog.
C) To prioritize the Product Backlog.
D) To complete the Sprint Backlog into a releasable piece of the product.
Solution: D

6.166 Who defines the Sprint Backlog scope?


A) Product Owner.
B) Scrum Team.
C) Scrum Master.
D) Stakeholders.
Solution: B

90

6.167 What is the major difference between Product Backlog and Sprint
Backlog?
A) The Product Backlog is equal to the Sprint Backlog.
B) The Product Backlog is a subset of the Sprint Backlog.
C) The Sprint Backlog is a subset of the Product Backlog.
D) The Sprint Backlog is owned by the Product Owner.
Solution: C

6.168 The maximum duration of the Sprint is highly recommended to be.


A) 5 days.
B) 10 days.
C) 15 days.
D) Less than a month.
Solution: D

6.169 As the Sprint planning progresses, the workload has grown beyond
the teams capacity. Which action makes most sense for the Team?
A) Work overtime for the Sprint
B) Collaborate with the Product Owner and potentially remove or change items
C) Cancel the Sprint
D) Star the Sprint and recruit additional team members
Solution: B

6.170 What does it mean to say that an event is timebox?


A) The event must be completed in a certain time.
B) The event is boxed to a maximum amount of time that it can take.
C) The event has a suggested time to meet every week.
D) The event is a box that contains time.
Solution: A

91

6.171 Which of the following statement are true about the Daily Scrum
Meeting:
A. This is a daily 15-minutes meeting.
B. The Product Owner runs the meeting.
C. The Daily Scrum Meeting takes place at the same time and place.
D. The Daily Scrum Team Meeting is for each team member to provide things
accomplished, thing to do before the next meeting, and identify any obstacles.
A) A and C.
B) A and D.
C) A, B, and C.
D) A, C, and D.
Solution: D

6.172 Which of the following statements are true for the Product Backlog.
A. The Product Owner is responsible for the Product Backlog.
B. The Product Backlog is dynamic.
C. Priority is driven by risk, value, and necessity.
D. The Product Backlog is fixed and it cannot changed once it is fully defined.
A) A, B, and C.
B) B and C.
C) A and B.
D) A, B, and D.
Solution: A

6.173 When should the Sprint Retrospective be held?


A) At the end of the last Sprint in a project or release.
B) At the beginning of each Sprint.
C) Only when the Scrum team determines it needs one.
D) At the end of each Sprint.
Solution: D

92

6.174 Whats the primary goal of Agile development?


A) Added value of working software.
B) Delivering software every Quarter.
C) Collocation of the team.
D) Processes, Documentation, Contracts, and limited change.
Solution: A

6.175 The Sprint Burndown charts are an efficient tracking tool because
they show.
A) The estimated work remaining as the Sprint progresses.
B) How many Product Backlog items remain.
C) How many hours have been worked by each team member.
D) How much effort has gone into the Sprint.
Solution: A

6.176 When is a Product Backlog item considered complete?


A) When all defined tasks are complete.
B) When QA reports that it passes all acceptance criteria.
C) When it adheres to the definition of done.
D) At the end of the Sprint.
Solution: C

6.177 The responsibility to remove impediments that will prevent the team
from accomplishing the over all objective of the sprint is?
A) The ScrumMaster.
B) The Product Owner.
C) The Stakeholders.
D) The Developer.
Solution: A

93

6.178 Which statement is an incorrect assessment of the Scrum Team?


A) The Scrum Team is self-organizing.
B) The Scrum Team is responsible for the Sprint Backlog.
C) The Scrum Team is cross-functional.
D) The Scrum Team is made up of fifteen members of various set of skills.
Solution: D

6.179 Which statement is an incorrect assessment of the Scrum Master?


j
A) The ScrumMaster is responsible for ensuring the team adheres to Scrum rules.
B) The Scrum Master helps the team to be more productive and produce higher quality
results that contribute towards the end product.
C) The Scrum Master manages the Team.
D) The Scrum Master removes impediments that prevents the team from performing
effectively and efficiently.
Solution: C

6.180 Drawing a trend line from previous completed work on a release


burndown chart indicates.
A) When the project will be over if the Product Owner removes work that is equal in
effort to any new work that is added.
B) Cost of the project.
C) When all Sprint Backlog tasks will be completed and the Scrum Team will be released for other work.
D) When the work remaining will be completed if nothing changes.
Solution: D

6.181 What is the Release Burndown?


A) A graph indicating what has been completed by the Scrum Team.
B) What has been completed by the Scrum Team to date.
C) The work remaining to be completed by the Product Owner.
D) A measure of the remaining Product Backlog across the time of a release plan.
Solution: D

94

6.182 Who is ultimate responsible for the Product Backlog item estimates?
A) ScrumMaster.
B) Product Owner.
C) The Scrum Team.
D) Stakeholders.
Solution: C

6.183 When many Scrum Teams are working on a project, what best
describes the definition of done?
A) Each Team defines and uses its own.
B) Each Team uses its own but must make it clear to all other Teams.
C) All teams must use the same definition.
D) It depends.
Solution: C

6.184 When many Scrum Teams are working on the same product, should
all of their increments be integrated every Sprint?
A) No, that is far too hard.
B) Yes, but only the Scrums Teams whose work has dependencies.
C) No, each Scrum Team stands alone.
D) Yes, otherwise Product Owners may not be able to inspect what is done accurately.
Solution: D

6.185 15. Whats the Scrum Team definition of Done?


A) Whatever the ScrumMaster wants it to be.
B) Whatever the Product Owner wants it to be.
C) Whatever the Stakeholders want it to be.
D) Whatever the Scrum Team defines done to be.
Solution: D

95

6.186 Which of the following statements are true about the Sprint?
Sprints are time-boxed.
Sprint is an iteration.
The Product Backlog is a subset of the Sprint Backlog.
The Scrum Master ensures no changes are made to the Sprint Goal.
A) A
B) B
C) A, B, and D
D) All of the above.
Solution: C

6.187 What is the Sprint Burndown?


A) The item completed from the Sprint Backlog.
B) A graph indicating the items completed by the Scrum Team.
C) A measure of the remaining Sprint Backlog across the time of the Sprint plan.
D) The last item remaining to be completed on the Sprint Backlog.
Solution: C

6.188 For a one month Sprint, how much time should be dedicated for the
Sprint Planning Activity?
A) 8 hours.
B) Whatever time is needed.
C) 1 Month.
D) 4 hours.
Solution: A

6.189 The purpose of the Sprint Retrospective is to review the following


items
A) Review the remaining Product Backlog.
B) Review how the last Sprint went in terms of people, process, tools.
C) Review only things that went well.
D) Review the ScrumMaster contributions to the Sprint.
Solution: B

96

6.190 Which statement best describes the Sprint Review?


A) It is use to build Team spirit.
B) It is a time allocated to judge the validity of the project.
C) It gives stakeholders an opportunity to inspect the product increments and progress
to date, and to provide feedback.
D) It is a review of the Teams activities during the Sprint.
Solution: C

6.191 What is the ultimate goal of the Scrum Team?


A) To complete the Product Backlog.
B) To estimate Sprint Backlog items.
C) To deliver increments of product functionality every Sprint.
D) To prioritize Sprint Backlog items.
Solution: C

6.192 Which statement is an incorrect assessment of the Product Owner?


A) The Product Owner plays a dual role, Product Owner and Scrum Master.
B) The Product Owner is the only person responsible for the Product Backlog.
C) The Product Owner prioritizes the Product Backlog
D) The Product Owner is one person not a committee.
Solution: A

6.193 How much work must a Scrum Team do to a Product Backlog it


selects for a Sprint?
A) As much work as the Team can fit into a Sprint.
B) All of the analysis, design, development, testing and documentation work.
C) The best amount of work the Team can do given that is usually impossible for QA to
finish all of the testing that is needed to prove it can be shipped.
D) As much work as it has told the Product Owner will be done for every Product
Backlog item it selects.
Solution: D

97

6.194 The Scrum Team is most productive if it is not interrupted during a


Sprint. As a result of...
A) The Spring Backlog emerges to reflect the work to develop the committed Product
Backlog items.
B) The Spring Backlog can only change with approval from the product owner.
C) The Sprint Backlog is devised during the Sprint Planning and should not need changing thereafter.
D) The Sprint Backlog is never changed.
Solution: B

6.195 What is the unit of measure that is used by the Scrum Team in
estimating Product Backlog items?
A) Minutes.
B) Hours.
C) Days.
D) Initial estimating is relative to each item in the Product Backlog.
Solution:

6.196 What best describes the Scrum Team Characteristics?


A) Less than ten members, Cross Functional Team, Collocated, and Committed to the
Sprint Goal.
B) Developers and Testers working together to deliver functional components.
C) Developers disperse across countries, working together as a team to deliver simple
easy Product Backlog items first.
D) Customer, Stakeholders, Developers, Architects, Testers, Management, Designers,
all thrown together to do whatever it takes to get the job done.
Solution: A

6.197 What part of the Sprint Backlog is used for the Sprint burndown
chart?
A) The percentage of work completed by each Team member.
B) The number of Product Backlog items completed by all the Team members.
C) The actual time spent on each task by each team member.
D) The remaining time required to complete each task by each team member.
Solution: B

98

6.198 The Sprint Backlog is owned by?


A) The ScrumMaster.
B) The Product Owner.
C) The Stakeholders.
D) The Scrum Team.
Solution: D

6.199 Who determines when it is appropriate to update the Sprint Backlog


during the Sprint?
A) The Team.
B) The Scrum Master.
C) The Product Owner.
D) The Scrum Team.
Solution: C

6.200 When multiple teams work together on the same product, each team
should maintain a separate Product Backlog.
A) True
B) False
Solution: B

6.201 The purpose of a Sprint is to produce a done increment of working


product.
A) True
B) False
Solution: A

6.202 The time-box for the Sprint Planning meeting is?


A) 4 hours.
B) Monthly.
C) 8 hours for a monthly Sprint. For shorter Sprints it is usually shorter.
D) Whenever it is done.
Solution: C

99

6.203 It is mandatory that the product increment be released to production


at the end of each Sprint.
A) True
B) False
Solution: B

6.204
A)
B)
C)
D)
Solution:

6.205
A)
B)
C)
D)
Solution:

6.206
A)
B)
C)
D)
Solution:

6.207
A)
B)
C)
D)
Solution:

100

6.208
A)
B)
C)
D)
Solution:

6.209
A)
B)
C)
D)
Solution:

6.210
A)
B)
C)
D)
Solution:

6.211
A)
B)
C)
D)
Solution:

6.212
A)
B)
C)
D)
Solution:

101

6.213
A)
B)
C)
D)
Solution:

6.214
A)
B)
C)
D)
Solution:

6.215
A)
B)
C)
D)
Solution:

6.216
A)
B)
C)
D)
Solution:

6.217
A)
B)
C)
D)
Solution:

102

6.218
A)
B)
C)
D)
Solution:

6.219
A)
B)
C)
D)
Solution:

6.220
A)
B)
C)
D)
Solution:

6.221
A)
B)
C)
D)
Solution:

6.222
A)
B)
C)
D)
Solution:

103

6.223
A)
B)
C)
D)
Solution:

6.224
A)
B)
C)
D)
Solution:

6.225
A)
B)
C)
D)
Solution:

6.226
A)
B)
C)
D)
Solution:

6.227
A)
B)
C)
D)
Solution:

104

6.228
A)
B)
C)
D)
Solution:

6.229
A)
B)
C)
D)
Solution:

6.230
A)
B)
C)
D)
Solution:

7 Unsorted
Planning: In Agile Planning changes from thinking about how to schedule making
things we think we can have into discovering and creating the truly meaningful
things we never dreamed we could have.
Its about doing, deploying, discovering and steering and doing this over and over
in a sustainable collaborative manner
bf
bf

105

8 Workshop Ideen
1. Erwartungen an den Workshop klaren (Alle)
2. Einteilung zwischen Neulingen und Experten (ist gut geeignet um sich ein entsprechendes Bild von der Gruppe zu machen) (Alle)
3. Agiles Manifest klaren was das ist und die einzelnen Punkte sortieren (die Punkt
wurden jeweils als entsprechende Aussagen ausgelegt und die Kursteilnehmer
mussten sich einigen welches Aussagen zusammenpassen) (Alle)
4. Artefakte: Gruppe findet Begriffe und muss diese den entsprechenden Artefakten
zuordnen

106