Das Dokument beschreibt den Scrum-Framework, eine agile Methode für die Softwareentwicklung, mit Fokus auf Rollen wie den Scrum Master, den Product Owner und das Entwicklungsteam. Es erläutert die Phasen der Teambildung, die Struktur der Artefakte wie das Product Backlog und die Sprint-Planung sowie die Zeremonien wie tägliche Scrums und Sprint-Reviews. Zudem werden Faktoren, die die Teamarbeit behindern können, und die Bedeutung des Burn-Down-Charts zur Überwachung des Arbeitsfortschritts thematisiert.

1. 1SCRUMEine agile, iterative Vorgehensweise für die Software-Entwicklung

2. 2RollenScrum MasterArtefakteProduct OwnerSprint BacklogRelease BacklogProduct BacklogDevelopment TeamZeremonienBefore Sprint: Sprint Planning MeetingDuring Sprint: Daily ScrumAfter Sprint: Review MeetingScrum ÜberblickBurn-down-chartPair-Programming2

3. 3Rollen3

4. 4Product Owner (PO)Verantwortlich für: Product Backlog und Priorisierung

5. Legt Prioritätslisten der anfallenden Aufgaben an (Product Backlog)

6. Verantwortlich für die Rendite, den Return on Investment (ROI)

7. Validiert Ergebnisse und prüft, ob die Qualität aus Sicht der Endnutzer akzeptabel ist

8. Entscheidet über die Wichtigkeit einzelner Funktionen

9. Er muss dem Team eine Vorstellung über das fertige Produkt vermitteln (Produktvision)

10. Muss auf Rückfragen schnell reagieren

11. Erfüllt in einem Projekt die Rolle des Kommunikators

12. Koordiniert die finanzielle Seite der Produktentwicklung4

13. 5Development TeamVerantwortlich für Software (Owner)

14. Sind selbst organisiert

15. Learning by doing

16. Muss alles tun um das gesteckte Sprint-Ziel zu erreichen (“commitment”)Software DeveloperSoftware DeveloperSoftware DeveloperSoftware DeveloperSoftware Developer5

17. 6Scrum Master “Agile Leader” nimmt sich zurück und tritt hinter das Team (Scrum Master ist nicht Mitglied des Teams; er ist Owner of Scrum Process)

18. Sorgt dafür das, dass Team die Methoden von Scrum beachtet und umsetzt

19. Mischt sich nicht in die entscheidungsspezifischen Entscheidungen des Teams ein

20. Berät das Team und steht ihm zur Seite

21. Greift nur ein wenn das Team oder ein anderer an Projekt Beteiligter die Scrum-Regeln verletzt

22. Muss Schwierigkeiten verhindern, die das Team bei der Arbeit behindern oder stören können6

23. 7Teambildung in vier PhasenFormingDie Gruppe kommt zusammen, lernt sichkennen und Beziehungenbilden sich heraus.Jeder sucht seinen Platz im Team StormingDie Teammitglieder identifizieren Unstimmigkeiten bezüglich des Vorgehens und derMethoden, die jeder für sich als wichtig bewertet.Das führt zu Konfliktendie offene Diskussionenhervorrufen und vonjedem erfordern, deneigenen Standpunkt klar zu vertreten. Es gilt außerdem, eigeneGrenzen zu erkennenNormingIn dieser Phase arbeitetdas Team daran, allenötigen Best Practices für das gemeinsamevorgehen zu definierenund zu implementieren, um alles, was die täglicheArbeit stören könnte, zu beseitigen.In dieser Phase identifiziert die Gruppe die Fähigkeiten, Expertise und Talent, die die einzelnen Mitglieder einbringen können.PerformingIn der letzten Phase hat das Team Unabhängigkeit und Selbstbewusstsein erlangt und kann die meisten Schwierigkeiten, die sich während der Produktentwicklung ergeben, selbst ausräumen.Die Reife und Effizienz der angewandten Best Practices wird kontinuierlich verbessert und optimiert, und das Team erreicht die ihm eigene Geschwindigkeit und Produktivität.7

24. 8Fünf Aspekte, die sich gegenseitig beeinflussen, können die Teamarbeit behindernkeinGesamt-bildvorAugenkeineRechenschaftabzulegenfehlendes CommitmentÄngstevorKonfliktenfehlendesVertrauen8

25. 9Artefakte

26. 10__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Product Backlogs-Produkt-Anforderungen mit Prioritäten-Pflichtenheft für das TeamAbb.110

27. 11Product BacklogsRelease Backlogs______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Release Backlog11

28. 12SprintsRelease BacklogsSprint 1____________________________________________________________________________________________________________________________________________________________________________________Sprint 2____________________________________________________________________________________________________________________________________________________________________________________12

29. 13Sprint 1Sprint 4____________________________________________________________________________________________________________________________________________________________________________________Sprint 2Sprint 3____________________________________________________________________________________________________________________________________________________________________________________Sprints & Sprint Backlogs (time boxed)__________________13

30. 149080706050403020100123456789Burndown-DiagrammRelease-1Release-2Release-3Verbleibender Arbeitsaufwand in TagenRelease-414

31. 15Product Backlog:In diesemSprint: klar definierte Arbeit, kann <30 Tagen erledigt werden; ausführbares Programm erzeugen.Wahrscheinlicher nächster Sprint: nächste Backlog-Priorität, von Ergebnissen des vorigen Sprints abhängig.Anforderungen in Textform (jede Anforderung eine Zeile)Während eines Sprints ist das dazugehörige Product Backlog fixiert und kann nur als Ergebnis der in diesem Sprint durchgeführte Arbeit verändert werden. Außerhalb des aktuellenSprints wird das Produkt Backlog immer geändert, weiterentwickelt und neu mit Priorität versehen.GeplantesReleasePrinzip des Product Backlogs15

32. 16Zeremonien16

33. 17(Scrum Master)Product OwnerDeveloperDeveloperDeveloperDeveloperDeveloperSprint Planning MeetingTimebox: 4 hourOwner: POParticipants: PO

34. Team

35. Scrum Master17

36. 18DeveloperDeveloperDeveloperDeveloper(Stakeholder)DeveloperDaily Scrum MeetingTimebox:15 minutesThree Questions: What have I done since last meeting?

37. What will I do until next meeting?

38. What problems do I have?(Scrum Master)18

39. 19DeveloperDeveloperDeveloperDeveloper(Stakeholder)DeveloperSprint Retrospective(Scrum Master)Timebox: 2 hourOwner: Scrum MasterParticipants: PO

40. Team

41. Scrum Master

42. Stakeholders19

43. 20(Scrum Master)Product OwnerDeveloperDeveloperDeveloperDeveloperDeveloperSprint Review MeetingTimebox: 2 hourOwner: TeamParticipants: Product OwnerTeamScrum Master20

44. 21Sprints3 days30 days21

45. 22Prozess22

46. 23From Release Planning to the Daily ScrumReleaseBacklogsDaily Scrum24 hoursPotentially Shippable Product IncrementProduct BacklogSprint2 – 4weeksSprint Backlogstime23

47. 24Inspektion im 24-Stunden-RythmusDaily ScrumSprintProduct BacklogInkrementan FunktionalitätDas Gerüst von ScrumIteration24

48. 25Repeat(Re) Write a testTest succeedsCheck if the Test failsWrite production codeTest failsTest failsRun all testsClean up codeAll tests succeedScrum ProcessMore on Test Driven DevelopmentTest succeedsSiehe auch: http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung25

49. 26Prinzip des Sprints bei skalierten ProjektenEinzelnes TeamStart-Product Backlog- funktionale Anforderungen nicht funktionale Anforderungen

50. Staging der nicht funktionalen Anforderungen die übrigen funktionalen und nicht funktionalen AnforderungenViele TeamsProduct BacklogFunktionale Anforderungen

51. nicht funktionale Anforderungen27Sprint-Planung für mehrere TeamsSprint-Planung für unterschiedlich funktionale TeamsFakturierungSprintSprintZeitplanungSprintEinweisung

52. 28Burn down ChartsWork that is complete is track against remaining days of the sprint

53. The target line indicates the velocity the team should track to during a sprint

54. Points above the line indicate work trending shower, points below the line indicates work trending faster

55. As you complete your work you should trend downward to 0 hours of work on the last day on the sprint29Überblick über den Scrum ProzessAlle 24StundenSprintDemonstration der neuen Funktionalität zum Sprint-EndeSprint BacklogAusgewähltes Product Backlog Product Backlog: sich abzeichnende Anforderungen höchster PrioritätVision: erwarteter ROI, Releases, Meilensteine

56. 30Scrum ProcessDaily CycleSprint planning meetingBusiness case & funding

57. Contractual agreement

58. Vision

59. Initial product backlog

60. Initial release plan

61. Stakeholder buy-in

62. Assemble TeamProduct incrementPreparationReleaseScrum ProcessUpdate Product BacklogSprint reviewSprint retrospectiveScrum Process

63. 31Scrum ProcessDaily CycleSprint planning meetingBusiness case & funding

64. Contractual agreement

65. Vision

66. Initial product backlog

67. Initial release plan

68. Stakeholder buy-in

69. Assemble TeamProduct incrementPreparationReleaseScrum ProcessUpdate Product BacklogSprint reviewSprint retrospectiveProduct BacklogScrum MasterList____________Scrum RollsScrum ArtifactsProduct Backlog Burn downBacklog DeltaProduct Owner________________________Sprint BacklogScrum Process

70. 32ScrumLiteratur zuScrum undMethodikder Software-Entwicklung32