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 Sch¨atzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
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 Sch¨atzmaße . . . . . . 4.2 Konzepte des agilen Sch¨atzens 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 Aktivit¨aten 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 Aktivit¨aten 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 Aktivit¨aten-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 Owner’s 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 Master’s role is to: . . . . . . . . . . . . What is the role of Management in Scrum? . . . . . . . . . . . . . . . . . . What is more important objective of the Backlog Refinement Meeting? . . What’s the difference between acceptance criteria and definition of done? What’s 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? . . . . . . . . . . . . . . . . . . . . . . What’s 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? . . . . . . . . What’s 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 weren’t 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 don’t 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 doesn’t 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.119What’s 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 team’s 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.174What’s 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. What’s 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 t¨aglichen Fortschritt und l¨ost 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 • Qualit¨at ↓ und Moral durch Todesm¨arsche ↓
Abbildung 1.1: Stacy Landscape Model: Complicated (Ursache Wirkung klar), Complex (Hinterher ist man immer schlauer; Effektivit¨at 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, w¨ahrend die Produktivit¨at und Kreativit¨at ¨ ¨ Produkte mit hochst-m oglichen Nutzen ausliefert
9
• 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 erh¨alt klare vorgegebene Ziele • Team organisiert sich um die Arbeit selbst • Team liefert regelm¨aßig wertvolle Funktionalit¨aten • Team erh¨alt Feedback von der Außenwelt • 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, großere Herausforderungen anzugehen (wir lernen aus Fehlern 2 ) Offenheit : wir besprechen wie wir vorgehen und was uns im Weg steht, ¨ wir a¨ ußern 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 w¨achst 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 beschr¨ankt und mussen bis dahin auch fertig sein, z.B. Sprintl¨ange, 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 erm¨achtigt die Teams dazu • Entwicklungspraktiken und Werkzeuge sind st¨andigen ∆ 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 Fehlschl¨age 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 Ver¨ande¨ rungen reagieren zu konnen. 6 w¨ ahlen aus, wie sie am besten ihre Arbeit umsetzen, als sich von außen 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 Abh¨angigkeiten ¨ – Priorit¨aten 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 sch¨atzen wir: • Individual and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following plan
⇒ w¨ahrend wir den Wert der Dinge auf der rechten Seite sehen, sch¨atzen 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. ¨ Anforderungs¨anderungen, auch sp¨at in der Entwicklung. Agile Prozesse 2. Begruße ¨ den Wettbewerbsvorteil des Kunden. nutzen den Wandel fur ¨ 3. Liefere h¨aufig funktionierende Software eher in kurzeren Zeitr¨aumen. ¨ 4. Gesch¨aftsleute und Entwickler mussen t¨aglich 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 prim¨are Maß fur ¨ 8. Agile Prozesse fordern nachhaltige Entwicklung. Die Sponsoren, Entwickler und ¨ Benutzer sollten ein gleichbleibendes Tempo ohne Unterbrechung einhalten konnen. 9. Die fortw¨ahrende Beachtung von technischer Exzellenz und gutem Design verbessert die Agilit¨at.
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 regelm¨aßigen 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 repr¨asentieren multilearning11 • verhandelt Commitments zum Sprint mit PO und legen so den scope des Sprint Backlogs fest ¨ von Backlog-Eintr¨agen • Sch¨atzen der Große • 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 Fachkr¨afte, um ein fertiges Produktinkrement am Ende eines Sprints lauff¨ahig zu haben ohne dabei von Personen außerhalb des Entwicklungsteam abh¨angig 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 Eintr¨age – 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 n¨achstes 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-Effektivit¨at und Effizienz • sind Cross-funktional16 ¨ Mitglieder des Entwicklungs-Teams zu17 • keine anderen Titel außer 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 F¨ahigkeiten besitzen, um jedes Produktinkrement zu liefern 17 sonst ver¨ andern sich die Verantwortlichkeiten
14
• Scrum l¨asst keine Sub-Teams zu (auch nicht durchs Testen, Business Analysts) • Individuelle St¨arken im Team sind vorhanden, aber die Verantwortlichkeit liegt auf dem ganzen Team • Große: ¨ <= 3 und <= 9 (PO und SM z¨ahlen 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 • r¨aumt Impediments aus dem Weg20 • erleichtert und h¨alt 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 außerhalb des Scrum-Teams welcher Ihre Interaktionen mit dem Team hilfreich und welche es nicht sind • achtet auf timeboxing • h¨alt 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 Gesch¨aftsziele 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 großen Pizza satt wird ¨ zu, ist empathisch und gibt Einsichten, w¨ahrend er Macht und Authodienende Fuhrungsperson: ¨ hort rit¨at im Team teilt 20 extern: z.B. fehlende Unterstutzung ¨ durch anderes Team; intern: wenn PO nicht weißt, 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 Verst¨andnis 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-Funktionalit¨at – 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 Produktivit¨at des Scrum-Teams erhoht – arbeitet mir anderen SMs zusammen, um die Effektivit¨at von Scrum in der ¨ Org zu erhohen
1.5 Sch¨ atzen ¨ zu bekommen, wie viel Sie schaffen konnen, ¨ ¨ • Team sch¨atzt, um ein Gefuhl es nutzt ¨ den PO tun kann. nix, was man nur fur ¨ • Sch¨atzen ohne Erfahrungen ist schwierig ⇒ z.B. die Sch¨atzungen uber verschie¨ dene Staaten, wie oft darin ein Land von der Große Deutschlands reinpassen 23 ¨ wurde • ist in Agiler Entwicklung weniger wichtig als in traditioneller Entwicklung ⇒ wenn man das Produkt in kleine auslieferbare Zust¨ande h¨alt, dann wird die Arbeit stets so herumpriorisiert • manche Teams benutzen einfaches Sch¨atzen: Alles ist entweder “Small” oder wird ¨ in kleinere Stucke heruntergebrochen Bucket-Sch¨atzung/Magic Estimation ¨ eine große Menge an Stories • eignet sich fur ¨ ¨ • gut Einsortierung in bestimmte Story-Cluster Großen und konnen auch helfen, zu große Stories in weitere kleinere Stories aufzubrechen od. aber ein weite Stories ergeben sich 23 w¨ ahrend
¨ der Ubung anstelle von L¨andern in km2 gesch¨atzt, w¨are es noch viel schwieriger geworden
16
• ist nur eine grobe Sch¨atzung • ist gut beim initialen Aufsetzen des Backlogs ¨ • Warum abstrakte Großen? ¨ 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 sch¨atzen ist fur diese andauernd gibt, dann sollte man Anpassungen vornehmen • Sch¨atzpoker: wird beim SP verwendet – verdecktes Sch¨atzen – gemeinsames Aufdecken – 1 vs 8 gesch¨atzt ⇒ wenn ich Experte bin, heißt es nicht, dass man an alles denkt, deswegen ist es gut wenn Abweichungen im Team hat; man l¨asst sich auf Teamsch¨atzung vs. Einzelsch¨atzung ein – Teamsch¨atzungen verhindern Aufbau von Wissensinseln – gemeinsames Verst¨andnis ¨ – 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 gesch¨atzten Großen bedeuten, dass die Story sehr komplex ist und man ein großes 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 regelm¨aßig 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 • Sprintl¨ange 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 gew¨ahren. 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-Authorit¨at 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 • w¨ahrend des Sprints: ¨ ¨ das Sprint-Ziel darstellen – keine Anderungen machen, die eine Gefahr fur ¨ – Qualit¨ats-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 ge¨andert ∗ Technologie hat sich ver¨andert – alle fertiggestellten und als “done” markieren PBI werden gereviewed. Alle unfertigen PBIs werden erneut gesch¨atzt 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-L¨ange, vorherigere Sprint Velocity, sch¨atzte Stories, Abh¨angigkeiten, 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 L¨ange 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 H¨alfte wird das Sprint Ziel erstellt (muss man sehr großzugig sein, da nicht immer alle involviert sind) und in der zweiten H¨alfte 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 große • Team entscheidet alleine, was es in dem Sprint liefern kann29 • PO muss w¨ahrend 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 Verst¨andnis der An¨ forderungen benotigte Stakeholder anwesend oder rufbereit sind • die Backlogeintr¨age, die das Team zur Lieferung zugesagt hat, nennt man Selected Product Backlog ¨ den laufenden Sprint aufgenommen und noch • evtl. neue Backlog-Eintr¨age, die fur nicht gesch¨atzt wurden, werden in diesem Meeting sofort bemessen • am Ende verspricht das Team dem PO die Lieferung einer selbsteingesch¨atzten Menge an lauff¨ahigen und getesteten Funktionen 2.2.2 SP2 • ist ein Design-Workshop und Team erarbeitet gemeinsam einen Grobentwurf der versprochenen Funktionalit¨aten ⇒ 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 Große 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 Kl¨arung von weiteren Fragen bereitstehen • Entwicklungs-Team hat die Verantwortung, wie die Arbeit getan wird
29 und 30 das
¨ denkt an Sprintdauer, Teamgroße, DoD, Abwesenheiten sowie Maßnahmen aus der letzten Retro Scrum Team ist Besitzer davon; kann w¨ahrend 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 n¨achsten Daily erreichen? Was bremst meinen Fortschritt? ¨ • Unterstutzung von Verbesserungen
Fakten :
• man steht beim Meeting, damit es kurz und knapp ist • kurz, kl¨arende 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 anf¨angt zu reden, das fordert die Selbstorg. – Round-Robin: Irgendwo anfangen und dann im Uhrzeigersinn oder entgegengesetzer Uhrzeigersinn – Token herumreichen • Improvement Board: – werden w¨ahrend des Dailys benannt und ans Board gemacht – Board ist von allen einsehbar und es misst den Fortschritt ¨ zur Erfullung des Problems ¨ – Updates konnen außerhalb des Dailys gemacht werden – durchs aufschreiben verhindert man ausufernde Diskussionen – Board kann die Spalten: Problem, Anzahl, Eind¨ammung, Gegenmaßnahme, 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, Abh¨angigkeiten Output : Akzeptiere/abgelehnte Sprint-Inkremente, update Risiken, updaten Abh¨angigkeiten, 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 Pr¨asentation 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 n¨achsten 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 • große 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 n¨achsten 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 ¨ Repr¨asentieren 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 erg¨anzbar • ist fur • PB wird w¨ahrend 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 abh¨angen – 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 ungef¨ahre Sch¨atzung ¨ 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 n¨achstes arbeiten macht es schwierig fur sollen 35 Anforderungen
werden sich immer a¨ ndern Eintr¨age 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-Abh¨angige 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 Sch¨atzung haben, aber sollten auch mal wieder neugesch¨atzt werden, sofern es weitere Informationen gibt – Emergent: Durch learnings und Ver¨anderungen, sollte jedes PBI ver¨andert ¨ ¨ werden konnen oder aber auch gesplittet, ver¨andert 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 großen Stories, Neusch¨atzung und Umpriorisierung ¨ zukunftige ¨ fur Sprints Teilnehmer : Team, PO, SM ist anwesend und garantiert, dass das Meeting stattfindet, eventuell weitere Stakeholder Ziele :
• Sch¨atzungen von Eintr¨agen39 • Anforderungen kl¨aren • 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 großeren Eintr¨agen 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 ⇒ ubergroße 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? • F¨alligkeit ⇒ fixed date; Wert/Nutzen • Expedite ⇒ verursacht von Anfang an Kosten und die steigen dann sp¨ater 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 Funktionalit¨at 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. Straße bauen (Schotter, Landstraße, 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 sp¨ater konkret sagen, was alles schief l¨auft 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 lauff¨ahig, 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 Abh¨angigkeiten, 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 ausgew¨ahlten Items und der Plan, diese zu liefern, wird Sprint Backlog genannt • beschreibt das WIE und ist ein forecast, welche Funktionalit¨aten im n¨achsten Inkrement geliefert werden • initiale Tasks werden vom Team w¨ahrend des Sprint Planning Meetings bestimmt • nur PO kann das Sprint Backlog w¨ahrend des laufenden Sprints bestimmen, ob ¨ es angemessen ist, das Board updaten, Entwickler konnen jedoch weitere Tasks w¨ahrend des Sprints ans Board machen ¨ Team sichtbar • ist furs ¨ • Scope commitment ist fest w¨ahrend 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 neugesch¨atzt 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 r¨aumen 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 kl¨aren, 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 Verst¨andnis davon haben • Product/Release Burndown Chart – zeichnet die verbliebenen Product Backlog Aufwand von einem Sprint zum n¨achsten 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 sch¨atzt, um ein Gefuhl es nutzt ¨ den PO tun kann. nix, was man nur fur • Sch¨atzungen weichen ab: statt st¨andig 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 ¨ • Sch¨atzen ohne Erfahrungen ist schwierig ⇒ z.B. die Sch¨atzungen uber verschie¨ dene Staaten, wie oft darin ein Land von der Große Deutschlands reinpassen ¨ ¨ wurde (h¨atten wir w¨ahrend der Ubung anstelle von L¨andern in km2 gesch¨atzt, w¨are es noch viel schwieriger geworden) • ist in Agiler Entwicklung weniger wichtig als in traditioneller Entwicklung ⇒ wenn man das Produkt in kleine auslieferbare Zust¨ande h¨alt, 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 • Sch¨atzungen sind immer ungenau ¨ • Personen, die die Aufgabe ausfuhren, sollen immer bei der Sch¨atzung dabei sein • mehr Erfahrung bedeutet pr¨azisere Sch¨atzung • manche Teams benutzen einfaches Sch¨atzen: Alles ist entweder “Small” oder wird ¨ in kleinere Stucke heruntergebrochen
4.1 Abstrake Sch¨ atzmaße • es wird nicht mehr in Aufwand, sondern Komplexit¨at gesch¨atzt, da es die folgenden Vorteile bietet: ¨ – vergleichende/abstrakte Sch¨atzungen sind schneller durchfuhrbar als Sch¨atzen ¨ absoluter Großen ¨ – Komplexit¨ats-Sch¨atzungen altern nicht, d.h. mussen nicht w¨ahrend eines Projekts durch Neusch¨atzungen korrigiert werden. Z.B. dauert das FormularEingabe Formular durch fehlende Erfahrung deutlich l¨anger als im sp¨ateren Projektverlauf, aber die Komplexit¨at bleibt aus Anwendersicht gleich und muss nicht angepasst werden – Trennung von Komplexit¨at und Aufwand wird mehr Objektivit¨at geschaffen, ohne die umsetzenden Individuen zu kennen – Bei Komplexit¨atssch¨atzung muss nicht bereits die Geschwindigkeit unterschiedlicher Entwickler einkalkuliert werden, was die Sch¨atzung aufw¨andig ¨ und personenbezogen machen wurde • Vielschichtigkeit der Komplexit¨at: – 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 absch¨atzbar. Wie wird aus der abstrakten Sch¨atzung eine Aufwandsabsch¨atzung? ¨ • 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. Sch¨atzen: gibts keine historischen Daten und/oder kein Vorprojekt, dann hilft nur die Bauchentscheidung • wenn man die Team-Aufstellungen ver¨andert, 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 L¨ange und mit gleicher Team-St¨arke 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 Großenbestimmungen zur Dauer durch die Verwendung der Velocity her, die Rate, in der ein Team lauff¨ahige, 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 Großen 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 Komplexit¨at wie eine andere Story hat, auch wenn wir nicht wissen, wie lange es dauern wird, jede zu implementieren • Warum bemessen wir Dinge in Komplexit¨ats-Einheiten statt in Zeit? ¨ ¨ oder Kom– ermoglicht und die Rate, in der ein Team arbeitet, von der Große plexit¨at der Arbeit zu trennen – das bewahrt uns davor, unsere Sch¨atzungen anhand dessen zu a¨ ndern, der die Arbeit macht, oder wenn die Fertigkeiten und Kapazit¨at 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 Großenbereich von 1-8 oder vielleicht ¨ ¨ Epics definiert, die in kleinere eine 13 schaffen. Die großeren Zahlen sind fur ¨ Stories heruntergebrochen werden mussen
4.3 Planning Poker • ist ein guter Weg, um bei der Sch¨atzung von Anforderungen innerhalb von Entwicklungsteams einen Konsens zu finden • Sch¨atzungen sind meist akkurat, da es von diejenigen Gesch¨atzt wird, welche die Arbeit auch erledigen • Ablauf: ¨ – PO, Team oder SM stellt die Aufgabe vor und anschließend kann daruber diskutiert werden, Risiken aufgezeigt oder Annahmen getroffen werden – dann folgt die Sch¨atzrunde: Alle Leute drehen Ihre ihre Karten gleichzei¨ tig aufgedeckt um. Gibt es große Abweichungen, dann wird uber den Wert diskutiert. Dabei sagt der SM, dass jeweils die mit den beiden extremsten Auspr¨agungen diskutieren sollen. Anschließend wird erneut gesch¨atzt. Nun ¨ sollte der Wert konvergieren, im Zweifelsfalls wird dann einfach die hohere Sch¨atzung genommen – wird eine Story > “13” oder mit einen “?” gesch¨atzt, 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 Sch¨atzwert. – Schnelle Entscheidung: nach wenigen Sch¨atzrunden einigen sich Teamleute ¨ ¨ meist auf eine Große (geubtes Team kann in einer durchschnittlichen Rate von 3 Minuten pro PBI sch¨atzen). – Transparenz: PO versteht besser, wie die Aufw¨ande entstanden sind, kann ¨ ein Team nicht sch¨atzen, 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 Sch¨atzung beteiligt und sein Wissen beitr¨agt. – 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 Sch¨atzung auch schon die Imple• sehr technische Teams finden, dass fur mentierung bekannt sein muss - Steve Bockman hat mit dieser Sch¨atzvariante 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 Komplexit¨at 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 Verst¨andnisfragen. Draufhin legt er sie an eine von ihm gew¨ahlte 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 n¨achsten Schritt darum, Großenverh¨altnisse zu beschreiben, um Story-Point-Sch¨atzungen zu erg¨anzen:
33
¨ ausw¨ahlen, ∗ Referenz definieren: Team muss eine Referenz-Story mittlerer Große ¨ die es einigermaßen gut uberblicken kann. ¨ die ausgew¨ahlte Referenz muss eine Sch¨atzung ∗ Referenz besch¨atzen: fur ¨ abgegeben werden (entweder schneller mundlicher Konsens oder kleine Pokerrunde zum Thema). ∗ Referenz beibehalten: Ist das Referenzfeature gew¨ahlt und gesch¨atzt, muss es bei folgenden Sch¨atzmeetings als Referenz herhalten und sollte immer mit in die Reihenfolge (erster Schritt) einsortiert werden - und zwar unabh¨angig davon, ob es bereits realisiert wurde oder nicht. ∗ Skala erg¨anzen: nun durchl¨auft man die Reihenfolge, vom ReferenzFeature aus- gehend, erst nach unten (kleiner) und fragt das Team, ab wann die n¨achste Stufe in der Skala erreicht wird (Entscheidung im Konsens). Ebenso verf¨ahrt man anschließend 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 Funktionalit¨aten ¨ zu gelangen (stammt ursprunglich von Boris Gloger) • wie beim Planning Poker geht es nicht um Pr¨azision, sondern um eine erste Einsch¨atzung • Ablauf: – Sch¨atzskala von Fibonacci wird auf den Bode oder ans Board gelegt – PO packt PBIs ans Bord oder legt sie auf den Boden – Team f¨angt an, Karten innerhalb der Sch¨atzskala 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 st¨andig hin und her (Nervous Nelly) muss der PO sie aus dem Spiel nehmen, um sie nachtr¨aglich zu diskutieren • Vorteile: – in kurzer Zeit kann man große Mengen an Anforderungen sch¨atzen lassen – gut um große Projekte bzw. lange Feature-Listen in eine schnelle Initialsch¨atzung mit minimalem Zeitaufwand zu erhalten – gemeinsames Verst¨andnis – Teamsch¨atzungen verhindern Aufbau von Wissensinseln
34
4.6 No Estimation • Woody Zuill und Neil Killick sind sehr aktiv in dieser Szene • Allgemein Sch¨atzung: Eine Sch¨atzung ist eine ungef¨ahre Berechnung oder Beurteilung von einem Wert, Zahl, Menge oder Umfang • Software Sch¨atzung: Es ist ein Versuch die Zukunft vorherzusagen • Grund furs ¨ Sch¨atzen: Bessere Entscheidungen treffen ¨ Anforderungen, die wir nicht genau ent• Sch¨atzungen sind oft Vermutungen fur ¨ uns entschieden wurden42 deckt haben und bereits im Vorfeld furs • Sch¨atzungen sind schwierig: Wenn Anforderungen wage sind (sind die meistens), dann ist die Sch¨atzung 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 h¨atte,dann konnte man es ja bereits schon zeigen) ¨ • Zustand, dass man keine Sch¨atzungen braucht: Kleine Stucke von arbeit inkre¨ mentel zu erledigen, die schnell zu einem moglichst auslieferbares Produkt kommen ¨ • Sch¨atzungen erlaub Entscheider (Manager, Stakeholder) den Start oder Weiterfuhrung ¨ eines Projekts genehmigen. Aufgrund dessen konnen Sie Entwickler die Schuld an ungenauen Sch¨atzungen geben und schneller arbeiten sollen. Und die Entwick¨ ler beschweren sich uber unklare, nicht korrekte und falsche Anforderungen ⇒ großer Kreis von blaming und keiner hat am Ende gewonnen • Zeit, die man zum Sch¨atzen von Stories verwendet, die nicht geliefert werden ¨ (oder mit Verzogerung) ist Verschwendung • Nachdenkfragen: 1. Wenn du herausfindest, das Sch¨atzungen wertlos sind, was kann man dann machen? 2. Wenn Sch¨atzungen falsche Erwartungen wecken und falsche Signale sind, was machst? ¨ 3. Wenn Sch¨atzungen nie existiert h¨atten oder nie erfunden wurden, konnten wir dann arbeiten? ¨ 4. Wenn du einen besseren Weg zur Erledigung von Arbeit gefunden hast, wurdest du dann weiterhin sch¨atzen? ¨ 5. Was ist, wenn ich Sch¨atzungen 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 gesch¨atzt wurde? Wenn Antwort nein ist, dann ist die Sch¨atzung ¨ da die Sch¨atzung nicht zur Entscheidung beigetragen hat. Wenn Antmull, wort ja ist, dann ist es sch¨atzungs-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 Beschr¨ankungen, um Entscheidungen zu treffen, z.B so viel Geld geben wir aus oder bis Juni wollen wir fertig sein – beliebige Beschr¨ankungen (Deadlines ohne Sch¨atzung) 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 sch¨atzt, dann generiert man Unsicherheit, weil du ratest Wie kann man ohne Sch¨atzungen 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 regelm¨aßig 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 Funktionalit¨aten, 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 Teamgroße • 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 – Teamgroße – durchschnittliche Bearbeitungszeit ist (2 + 1 / 4) sind 0,75 Tage
36
5 Retrospektiven richtig durchf¨ uhren • Quintessenz: Maßnahmen 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 sch¨atzen und sie ans Board h¨angen, 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 Gesch¨aft 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 erm¨achtigt fuhlen, dann bringen sich die Leute auch besser ein und haben weniger Hemmungen sich zu a¨ ndern • Teams einigen sich auf Ver¨anderungen und sie leiten die Ver¨anderungen auch eigenst¨andig ¨ • wenn Teams ihre eigene Verbesserungen leiten, ist effektiver, schneller und gunstiger als wenn andere Teams und weitere Leute zwischen den Ver¨anderungen 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 Vertr¨age wie man sozial miteinander umgeht43
Start :
¨ ihre Zeit bedanken • Leute willkommen heißen 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 erkl¨art das F Word: Frage die Leute in Retros nie, wie sie sich fuhlen 3. Generate insights: Zweck :
• Frage nach “Warum”48 ¨ • erlaubt es dem Team einen Schritt zuruckzugehen und das große Bild zu sehen • was bedeutet die Sache aus 2.? Team konsolidiert die Daten, um St¨arken 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 Maßnahmen im n¨achsten Sprint von wem angegangen werden sollen
Start :
• wenn man viele Ideen hat, dann die heraussuchen, die das Team auch bis zur n¨achsten 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 w¨ahlen ¨ • 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 großen 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 • verst¨andisvolle 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: Aktivit¨aten, Gruppendynamiken und Zeit managen • du musst neutral im ganzen Prozess sein ¨ ¨ 10 Sekunden, • fuhre Aktivit¨aten mit einer Vorlage ein, erkl¨are diese und warte fur wenn es keine Fragen gibt, dann kannst du mit der Aktivit¨at 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 • Aktivit¨aten managen – erkl¨are den Zweck jeder Aktivit¨at
39
¨ Fragen verfugbar ¨ – du musst fur sein und den Raum beobachten – debriefe jede Aktivit¨at ⇒ 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 Aktivit¨at zum Pro¨ jekt zu verknupfen 5. Nachdem die Verbindung zwischen Aktivit¨at und Projekt erstellt ist, dann ¨ Frage die Leute, wie Sie Ihre Einsichten verwenden konnen: Was ist ein ¨ Ding, was du ver¨andern 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 Aktivit¨at betragen Gruppendynamik • bedeutet Teilnahme • Leute, die reden wollen sollen auch Reden und Leute die zu dominant beim Reden ¨ sind, mussen eingeschr¨ankt 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 Kreativit¨at zuruck geben kannst 1. Was habt ihr zuvor schon mal probiert? Was ist dabei passiert? Was wollt ihr beim n¨achsten 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 großeres Problem geben, welches ¨ du nicht losen kannst ⇒ sprich mit HR Wie man mit bestimmten Situationen am besten umgehen kann • Tr¨anen: 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 erz¨ahlen 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 h¨aufiger 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 Zeitmessger¨at (Pomodoro, Zeitmessuhr) mit und achte auf die Dauer der einzelnen Aktivit¨aten • 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, Kuhger¨ausche • wenn die Gruppe voller Energie in einer Phase ist, dann frag, ob sie weitermachen wollen und darauf hinweisen, dass die Endaktivit¨at 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 weißt, was du als n¨achstes 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 außerhalb von mir? 3. Wie ist die Gruppe in die Situation gekommen? 4. Wo muss die Gruppe als n¨achstes hingehen? ¨ den n¨achsten 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 Gesch¨aftsnutzen 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 w¨ahrend 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 außerhalb 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 außer Kontrolle ger¨at, d.h. wenn sich der Empf¨anger 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¨ ußert
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, Produktqualit¨at 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 geheißen 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¨ ußern
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 heißen und danach beschreibt der Retroleiter produktive und unproduktive Kommunikationsmuster. Nachdem die Mus¨ ter erkl¨art wurden, diskutieren die Teilnehmer uber die entsprechenden Inhalte ¨ gute KommuZweck : Hilft beim Aufbau eines gemeinsamen Verst¨andnis 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 erkl¨are es. • bilde Gruppen von weniger als 4 Leuten die sollen die Aussage definieren und erkl¨aren ¨ • 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 :
¨ • Erkl¨are, dass du eine Umfrage durchfuhren wirst, um zu lernen, wie die Erwartungshaltung der Leute an die Retro ist • Zeige die Flipchart und erkl¨are die einzelnen Personengruppen:
52 Sie
sollen erkl¨aren, 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 t¨aglichen Schinderei weg zu sein. Manchmal sind fruh sie aufmerksam, aber sie sind froh nicht mehr im Office zu sein ¨ ¨ – Prisoner: Fuhlen sich zur Retro gedr¨angt und wurden liebend gerne etwas anderes machen • verteile Karten, auf dem jeder seine Rolle eintr¨agt • 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 t¨agliche 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 Aktivit¨at 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 • erkl¨are der Gruppe, dass sie 3 - 7 Agreements ausw¨ahlen sollen
53 Pack
die vorgelesenen Zettel weg und schmeißt sie weg, so dass es anonym ist anschließend 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, l¨angere Iteration und Projekt-Release ¨ Beschreibung : Leute schreiben ihre Ideen, personliche Erlebnisse und andere signifikante Erlebnisse auf Karten, welche w¨ahrend einer Iteration, Release oder Projekt passiert. Zweck : Simuliere Erinnerungen was geschehen ist w¨ahrend und außerhalb der Arbeit. ⇒ Erstelle ein Bild von der Arbeit von verschiedenen Parameter ⇒ erkenne Muster, wann sich die Energie-Level ge¨andert 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 (Affinit¨atsgruppen), 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 Aktivit¨at: 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 n¨achstes gemacht werden sollen” Beschreibung : ... ¨ Aktionen oder Vorschl¨age. 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 • erkl¨are den Ablauf: In der ersten Runde hat jede Person 5 Minuten Zeit, um Ideen zum Thema XXX niederzuschreiben. Ziel sollen ¨ die n¨achste 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 Aktivit¨at: Was habt Ihr festgestellt, w¨ahrend 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 l¨angeren 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 Erkl¨are 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 w¨ahrend 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 w¨ahrend des Projektes ¨ ¨ gefuhlt haben und vielleicht konnen wir Quellen entdecken, bei den wir zufrieden und unzufrieden waren.”
47
• erkl¨are das Poster mit den Labeling Mad, Sad und Glad; hab einen ¨ alle greifbar zur Hand Stapel mit farblichen Post-Its und Stiften fur • erkl¨are, dass ihr x Minuten Zeit habt, um die Zeiten/Ereignisse niederzuschreiben, wo ihr Euch Glad, Sad oder Mad w¨ahrend 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 h¨alt 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 ¨ Kreativit¨at – 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 w¨ahlen 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 Aktivit¨at
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 team’s 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 Owner’s 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 won’t 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 can’t 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 Master’s 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 Team’s 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 aren’t 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 What’s the difference between acceptance criteria and definition of done? A) There’s 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 What’s 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 we’ll 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. It’s 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. There’s 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 customer’s 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 don’t 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 What’s 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 haven’t 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, it’s important to quantify everything. B) No, it’s 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 that’s 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 What’s 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 weren’t working on the team? A) Yes. Its just like watching a hockey game. B) No. If the team needs to discuss issues with outsiders it’s 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 don’t 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 won’t 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 team’s 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. It’s 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 doesn’t 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 What’s 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 Team’s 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 aren’t 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 team’s 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 What’s 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 Scrum’s 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. What’s 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 Team’s 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 kl¨aren (Alle) 2. Einteilung zwischen Neulingen und Experten (ist gut geeignet um sich ein entsprechendes Bild von der Gruppe zu machen) (Alle) 3. Agiles Manifest kl¨aren 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
