Agile Scrum Foundation

In diesem Kurs erhalten Sie das notwendige Wissen für die Agile Scrum Foundation Prüfung.

Scrum Einführung

Scrum eine Einführung

Srum eine Einführung

Klassische Modelle zur Abwicklung von Projekten gab es schon lange vor dem Computerzeitalter. Beispiele hierfür waren das Wasserfallmodell, das Spiralmodell etc.

Mit dem Aufkommen von Software wurden diese klassischen Modelle angepasst, z.B. mit dem V-Modell.

Das Problem bei diesen Modellen ist, dass ein Softwareprojekt zwar systematisch und in hoher Qualität entwickelt wird, aber es sehr lange dauert, bis das Endprodukt entwickelt bzw. sichtbar ist. Die Software entspricht dann möglicherweise nicht mehr den aktuellen Anforderungen des Unternehmens.

Agile Modelle

Agile Modelle

Um die Softwareentwicklung einfacher und vor allem flexibler zu gestalten, wurden agile Methoden entwickelt. Beispiele hierfür sind Extreme Programming (XP) oder Scrum.

Die Vor- und Nachteile von Agilen Methoden sind wie folgt:

Vorteil

Flexibler, Anforderungen können laufend eingebracht werden.

Programmierer werden geschützt, indem während den Programmierphasen keine Änderungen an den definierten Anforderungen eingebracht werden können.

Übersicht ist einfacher zu behalten, da immer nur kleine Abschnitte programmiert werden.

Nachteil

Kosten sind schwerer kontrollierbar, da laufend neue Anforderungen eingebracht werden können.

Kann dazu führen, dass Benutzer sich zu Beginn des Projektes zu wenig Gedanken über die Software machen, da ja noch laufend Anforderungen eingebracht werden können.

Rollen in Scrum

Rollen in Scrum

Bei Scrum gibt es 3 Rollen:

Der Scrum-Master ist für den Prozess verantwortlich und moderiert die Besprechungen. Er arbeitet nicht aktiv im Team mit, unterstützt das Team aber, indem er Support bietet und Probleme aus dem Weg schafft. Pro Team steht ein Scrum-Master zur Verfügung.

Beim Product Owner handelt es sich um den Vertreter des Kunden oder um einen Produktmanager. Dieser definiert die Anforderungen und deren Priorität.

Bei der dritten Rolle handelt es sich um das Team, das selbstgesteuert plant und arbeitet und für die Umsetzung der Anforderungen verantwortlich ist. Ein typisches Team umfasst 3 bis 9 Mitarbeiter. Innerhalb des Teams existieren keine Rollen wie Architekt, Tester etc. Alle Teammitglieder arbeiten zusammen und zielgerichtet am Produkt.

Was ist eine These im Agilen Manifest?

  • Der Vertragsverhandlung kommt eine höhere Wertschätzung zu als der Zusammenarbeit mit dem Kunden.
  • Der Einhaltung eines Plans kommt eine höhere Wertschätzung zu als der Reaktion auf Änderungen.
  • Prozessen und Tools/Hilfsmitteln kommt eine höhere Wertschätzung zu als einzelnen Personen und Interaktion.
  • Einer funktionierenden Software kommt eine höhere Wertschätzung zu als eine umfassende Dokumentation.

Welche Richtlinie gilt für das Arbeitstempo bei der Entwicklung gemäss Agile?

  • Schnell
  • Sich steigernd
  • Konstant

Ein Team bereitet sich auf die Übernahme von Scrum vor. Es ist bereits eine Rolle mit der Bezeichnung „Projektkoordinator“ vorhanden, die Hindernisse beseitigt und das Team als Coach unterstützt. Wie heisst diese Rolle in Scrum?

  • Projektkoordinator
  • Projektmanager
  • Scrum Master
  • Scrum-Projektmanager

Ein Kunde fordert einen Bericht an, der die neuen Funktionalitäten und erkannten und behobenen Fehler sofort am Ende eines Sprints zusammenfasst. Wer ist am besten dafür geeignet, diesen Bericht zu erstellen?

  • Der Product Owner
  • Der Scrum Master
  • Das Entwicklungsteam
  • Es sollte kein solcher Bericht erstellt werden

Was ist der wichtigste Verantwortungsbereich eines Scrum Masters, mit dem er dafür sorgt, dass ein Scrum-Team stets maximale Produktivität liefert?

  • Sicherstellen, dass Features höchster Priorität stets oben im Product Backlog aufgeführt sind.
  • Keine Änderungen am Product Backlog zulassen, sobald der Sprint begonnen hat.
  • Die Entscheidungen des Entwicklungsteams unterstützen und bei der Behebung ihrer Schwierigkeiten helfen.

Wer hat die meisten Kenntnisse über den Fortschritt auf dem Weg zum geschäftlichen Ziel oder Release?

  • Der Product Owner
  • Der Scrum Master
  • Das Entwicklungsteam

Das obere Management verlangt regelmässige Audits, um zu überprüfen, ob das Scrum-Team die Scrum-Praktiken und -Prinzipien befolgt. Wer ist am besten dafür geeignet, ein solches Audit durchzuführen?

  • Der Product Owner
  • Der Scrum Master
  • Das Entwicklungsteam
  • Die Tester

Der Product Owner wird für drei Wochen im Urlaub sein. Das Team soll am Ende der ersten Urlaubswoche des Product Owners den aktuellen Sprint abschliessen und einen neuen Sprint starten. Wie sollte vorgegangen werden?

  • Jedes Scrum-Team sollte im Idealfall über zwei Product Owner verfügen, um alles abdecken zu können.
  • Der Product Owner sollte gebeten werden, seinen Urlaub um eine Woche zu verschieben.
  • Der Scrum Master sollte die Rolle und Aufgaben des Product Owners übernehmen.

Scrum planen

Product Backlog

Product Backlog

Stakeholder können laufend Anforderungen beim Product Owner einreichen.

Der Product Owner nimmt diese Anforderungen entgegen und legt diese in einem zentralem Verzeichnis ab. Dieses Verzeichnis nennt sich in Scrum "Product Backlog".

Der Product Backlog ist eine priorisierte Liste mit Anforderungen an das Produkt. Das Product Backlog ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss seinen Ursprung im Product Backlog haben.

Der Product Owner ist für die Pflege des Product Backlogs verantwortlich (Reihenfolge bzw. Priorisierung der Einträge).

Product Backlog Refinement

Product Backlog Refinement

Das Product Backlog Refinement ist ein fortlaufender Prozess (Meeting), bei dem der Product Owner und das Team gemeinsam das Product Backlog weiterentwickeln.

Hierzu gehören:

•Ordnen der Einträge

•Löschen von Einträgen, die nicht mehr wichtig sind

•Hinzufügen von neuen Einträgen

•Detaillieren von Einträgen

•Zusammenfassen von Einträgen

•Aufteilung von Einträgen

•Schätzen von Einträgen

•Planung von Releases

User Stories in Scrum

User Stories in Scrum

Nachdem der Product Ownder eine Anforderung der Stakeholder angeommen hat und diese im Product Backlog Refinement geschätzt wurden, werden aus einer Anforderung mehrere User Stories definiert.

User Story ist eine Technik zur Beschreibung von Anforderungen aus der Perspektive eines Benutzers unter Verwendung von Alltagssprache. Z.B. der Benutzer kann eine Rechnung am Bildschirm anschauen.

Sprint Backlog

Sprint Backlog

Die nun erstellten User Stories werden nun vom Team zentral in einem Sprint Backlog verwaltet. Der Spring Backlog enthält somit die Aufträge des Teams.

Das Team stellt die Menge an abzuarbeitenden Anforderungen selber zusammen und berücksichtigt dabei die Prioritäten des Product Owners.

Das Team verspricht die im Sprint Backlog vorhandenen User Stories innerhalb des nächsten Sprints zu erledigen.

Sprint

Sprint

Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird.

Er beginnt mit einem Sprint Planning und endet mit dem Sprint Review und der Sprint-Retrospektive. 

Sprints folgen unmittelbar aufeinander. Während eines Sprints sind keine Änderungen erlaubt.

Ein Sprint umfasst ein Zeitfenster von ein bis vier Wochen. Alle Sprints sollten idealerweise die gleiche Länge haben, um so dem Projekt einen Takt zu geben.

Ein Sprint wird niemals verlängert und ist zu Ende, wenn die Zeit um ist.

Kann eine Arbeit nicht in der geplanten Zeit erledigt werden, so muss das Team das weitere Vorgehen mit dem Product Owner absprechen.

Definition of Done

Definition of Done

Die "Definition of Done" (DoD) ist eine Liste von Fertigstellungskriterien die das Team zur Erstellung des Produktes zu beachten hat. Meist sind damit Wünsche des Product Owners an Qualität, Skalierbarkeit etc. verbunden. 

Die Hoheit über die "DoD" liegt aber beim Team. Sprich das Team erstellt auf Basis der Wünsche des Product Owners die Liste von Fertigstellungskriterien, damit die Wünsche des Product Owners erfüllt werden können.

Beispiele für Punkte einer Definition of Done könnten folgende sein:

  • Alle Akzeptanzkriterien werden erfüllt
  • Der Code ist fertiggestellt und im Versionierungssystem eingespielt
  • Dokumentation Update durchgeführt
  • Release Dokumentaion angepasst
  • Coding Guidelines und Standards wurden eingehalten
  • Es wurden Unit Tests durchgeführt und auf "Grün"
  • Es sind keine kritischen Bugs offen

Ein Scrum-Team hält es für eine gute Idee, in einer Checkliste alle zu erledigenden Aufgaben eindeutig festzulegen, bevor eine Story als „abgeschlossen“ bezeichnet wird. Welches Artefakt ist dafür am besten geeignet?

  • Burn-Down Chart
  • Definition of Done (Definition von „fertiggestellt“)
  • Product Backlog
  • Sprint Backlog

Kurz vor dem Ende eines Sprints stellt das Entwicklungsteam fest, dass es nicht möglich sein wird, alle zugesagten Storys abzuschließen. Welche Massnahme im Hinblick auf das Entwicklungsteam ist in diesem Fall die beste Empfehlung?

  • Das Team um weitere Mitarbeiter und Mitglieder erweitern, um die Ziele des aktuellen Sprints zu erreichen.
  • Den Product Owner bitten zu entscheiden, welche Storys in den nächsten Sprint verschoben werden können.
  • Eine neue Definition of Done (Definition von „fertiggestellt“) für die Sprint Backlog-Einträge festlegen.

Das Entwicklungsteam stellt fest, dass es in einem Sprint zu viele Zusagen gemacht hat, die es nicht einhalten kann. Wer sollte bei der Überprüfung und Anpassung der Sprint-Aufgaben anwesend sein?

  • Das Entwicklungsteam, der Scrum Master und der Product Owner. Die Stakeholder sollten beratend hinzugezogen werden.
  • Das Entwicklungsteam und der Scrum Master. Der Product Owner sollte beratend hinzugezogen werden.
  • Nur das Entwicklungsteam. Der Product Owner sollte beratend hinzugezogen werden.

Wie sollte „done“ (fertiggestellt) definiert werden, wenn mehrere Scrum-Teams an ein und demselben Produkt arbeiten?

  • Für alle Scrum-Teams muss dieselbe Definition of Done (Definition von „fertiggestellt“) gelten.
  • Jedes Scrum-Team muss seine eigene Definition of Done (Definition von „fertiggestellt“) festlegen und einhalten.
  • Der Scrum Master definiert, wann ein Eintrag fertiggestellt ist.

Ein Scrum-Team wählt einen Product Backlog-Eintrag (PBI, Product Backlog Item) für das Sprint Backlog aus. Was muss das Entwicklungsteam tun, um den ausgewählten Product Backlog-Eintrag abzuschliessen?

  • Es muss so viel wie möglich vor dem Endtermin im Sprint fertigstellen.
  • Es muss so viel wie nötig tun, um der Definition of Done (Definition von „fertiggestellt“) zu entsprechen.
  • Es muss den Product Backlog-Eintrag analysieren, entwerfen, programmieren, testen und dokumentieren.

Ein Sprint wurde soeben abgeschlossen und es kam zu einer Katastrophe. Keine der geplanten Storys wurden fertiggestellt und der Review musste abgebrochen werden. Das obere Management möchte wissen, wer schuldig ist. Bei wem liegt die Verantwortung?

  • Beim Product Owner
  • Beim Scrum Master
  • Beim oberen Management
  • Beim Entwicklungsteam

Was ist ein Sprint?

  • Ein Brainstorming-Meeting in Extreme Programming, bei dem neue Ideen entwickelt werden.
  • Ein Wettlauf zwischen zwei Entwicklern, bei dem ermittelt wird, wer ein Feature am schnellsten abschliessen kann.
  • Eine Iteration in der Scrum-Methodik.
  • Die letzte Iteration im Scrum-Projekt, in der das Team Überstunden macht, um das Projekt abzuschliessen.

Meetings in Scrum

Meetings in Scrum

In Scrum gibt es die obigen Meeting. Das Baclog Refinement Meeting haben Sie bereits kennen gelernt. Nachfolgend werden die weiterne Meeting näher vorgestellt.

Sprint Planing Meeting

Sprint Planning Meeting

Das Sprint Planning Meeting findet zu Beginn eines Sprints statt. An diesem Meeting nehmen alle Projektrollen teil.

Team und Product Owner entscheiden hierbei über die Inhalte des nächsten Sprints. Der Product Owner erläutert die am höchsten priorisierten Einträge des Product Backlogs und erklärt deren fachlichen Nutzen.

Das Team schätzt den Aufwand ab und nimmt die Anforderungen in Form von User Stories an.

Daily Scrum

Daily Scrum

Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem max. 15-minütigen Daily Scrum. Zweck des Daily Scrum ist der Informationsaustausch unter dem Team. Es sollten die nachfolgenden 3 Fragen beantwortet werden:

1. Was wurde seit dem letzten Meeting fertiggestellt?

2. Was wird vor dem nächsten Meeting fertiggestellt?

3. Welche Hindernisse stehen im Weg?


Die Moderation übernimmt der Scrum-Master.

Über die Anwesenheit des Product Owner entscheidet das Team. Der Product Owner ist nicht aktiv am Meeting beteiligt. 

Sprint Review Meeting

Sprint Review

Das Sprint Review steht am Ende des Sprints.

Hier überprüft das Scrum Team die Umsetzung des Spring Backlogs. Das Team präsentiert seine Ergebnisse dem Product Owner und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde.

Der Fokus liegt beim Produkt. 

Bei einer erfolgreichen Abnahme wird das erledigte Product Backlog Item auf „Done“ umgestellt.

Sprint Retrospective Meeting

Sprint Retrospective

Die Sprint-Retrospektive steht am Ende eines Sprints.

Hierbei überprüft das Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden.

Der Fokus liegt beim Vorgehen.

Während des Daily Scrum werden drei Fragen beantwortet. Welche ist eine dieser Fragen?

  • Welche Hindernisse stehen im Weg?
  • Wer sollte die nächste Aufgabe übernehmen?
  • Welche Kundenanforderungen sind eingegangen?

Welche der folgenden Aussagen beschreibt am besten die Rolle, die das Daily Scrum bei der Überwachung eines Scrum-Projekts spielt?

  • Das Daily Scrum hilft dem Scrum Master, das Burn-Down Chart zu aktualisieren.
  • Das Daily Scrum bietet dem Entwicklungsteam einen Einblick in den bisherigen Fortschritt und bestehende Schwierigkeiten.
  • Mit dem Daily Scrum kann der Product Owner den Fortschritt des Teams überprüfen.

Wie viel Zeit sollte ein Scrum-Team mit 5 Mitgliedern auf die Sprint-Planung für einen 3-wöchigen Sprint aufwenden?

  • 3 - 6 Stunden
  • 3 - 6 Tage
  • so lange wie nötig

Warum muss das Daily Scrum immer am selben Ort und zur selben Zeit stattfinden?

  • Die Buchung eines Raums muss vorab für die gesamte Dauer eines Sprints erfolgen.
  • Die gleichbleibenden zeitlichen und örtlichen Gegebenheiten bieten die besten Voraussetzungen für Kontinuität im Scrum-Framework.
  • Der Projektmanager muss jeden Tag zu einer bestimmten Zeit aktualisierte Informationen zum Status erhalten.

Ein Teammitglied eines Scrum-Teams meint, ein leitender Technologiearchitekt habe wertvolle Informationen und Feedback zum Produkt. Welches Ereignis ist am besten geeignet, um dieses Feedback einzuholen?

  • Daily Scrum
  • Sprint-Planung
  • Sprint-Retrospektive
  • Sprint Review

Zeit schätzen in Scrum

Fibonacci Estimation

Fibonacci Estimation

Die Fibonacci Estimation ist eine Zahlenreihe und wird häufig gewählt, um der zunehmenden Unsicherheit in der Schätzung schwererer Aufgaben gerecht zu werden.

Es werden folgende Zahlen verwendet: 1, 2, 3, 5, 8, 13, 21.

Es wird auf eine kontinuierliche Reihenfolge verzichtet um die Abstände deutlicher zu machen.

Schätzungen für grössere Werte werden immer ungenauer.

Beim Planungspoker und der Affinity Estimation wird mit dieser Zahlenreihe gearbeitet.

Planungspoker

Planungspoker

Beim Planungspoker erhält jeder Teilnehmer einen Satz Spielkarten. Diese sind mit Schwierigkeitsgraden oder Story-Points bedruckt.

Die Zahlenreihe der Karten entspricht der Fibonacc Estimation.

Das Planungsspiel läuft folgendermaßen:

1. Der Product Owner stellt die User Story vor, die es zu schätzen gilt.

Das Team klärt in der Diskussion mit dem Product Owner seine Fragen zu der Story.

2. Jedes Teammitglied wählt für sich eine Karte, die seiner Ansicht nach der Schwierigkeit der Story entspricht. Er legt diese verdeckt auf den Tisch.

3. Alle gewählten Karten werden gleichzeitig aufgedeckt.

4. Die Teilnehmer mit der niedrigsten und der höchsten Schätzung erklären ihre Beweggründe.

5. Je nach Ergebnis wird wie folgt weitergegangen:

     - Falls alle das gleiche schätzen, wird dieser Wert übernommen.

     - Falls die Schätzungen nahe beeiander liegen, wird der höchste Wert übernommen.

     - Falls die Werte weit auseinander liegen, muss die User Story eventuell weiter aufgeteilt werden.

Affinity Estimation

Affinity Estimation

Bei der Affinity Estimation werden eine grosse Anzahl von User Storys auf verschiedene Grössen verteilt.

Als Grössenangaben werden oftmals Kleidergrössen verwendet, XS, S, M, L und XL.

Es geht mehr darum abzuschätzen, ob eine User Story grösser ist als eine andere.

Somit können User Storys rascher geschätzt werden als z.B. im Planungspoker.

Im Anschluss werden dann die Grössen durch Zahlen ersetzt. Das weitere Vorgehen bzw. die Ermittlung des Mittelwertes wird dann Triangulation genannt.

Velocity

Velocity in Scrum

Velocity ist die Anzahl an erledigten Story Points in einer Iteration.

Die Idee ist es, aufgrund von Erfahrungswerten abschätzen zu können, wieviel ein Team schaffen kann und somit das Enddatum zu berechnen.

In die Berechnung der Velocity fliessen nur bereits abgeschlossene Story Points mit ein, da das Ende nur schwer abzuschätzen wäre.

Ein Scrum-Team nimmt Schätzungen für User Storys vor. Der Scrum Master schlägt dafür die Planning Poker-Technik vor. Wie wird beim Planning Poker vorgegangen?

  • Vergleichen der Story mit Referenz-Storys und anschließende Schätzung.
  • Vornehmen einer eigenen Schätzung mit anschliessendem Vergleich mit den Schätzungen anderer.
  • Sortierung aller Storys basierend auf dem relativen erforderlichen Aufwand.

Ein Scrum-Team nimmt Schätzungen für eine Story anhand der Planning Poker-Technik vor. Das Team entscheidet, 5 Story Points einer Story zuzuweisen, da die Entwickler 2 Points und die Tester 3 Points geschätzt haben. Welche Aussage ist richtig?

  • Points werden vom Scrum Master, nicht vom Entwicklungsteam zugewiesen.
  • Points werden für die gesamte Story zugewiesen; die Story wird nicht aufgeteilt.
  • Points werden nie geschätzt, sondern stets vorab festgelegt.
  • Das Entwicklungsteam muss zusätzlich auch den Product Owner zur Schätzung befragen.

Was ist die Definition von „Velocity“ (Geschwindigkeit) eines Teams?

  • Ein gemeinsames Verständnis darüber, wie schnell ein Sprint fertiggestellt werden muss.
  • Das optimale Work-in-Progress-Limit für jeden Sprint.
  • Die Anzahl an Story Points, die ein Team in einem Sprint abschliessen kann.
  • Die Summe aller abgeschlossenen Sprint Backlog-Einträge.

Monitoring in Scrum

Burn-up und Burn-down Chart

Burn-up und Burn-down Chart

Burn-up Chart oder Burn-down Chart zeigen den Fortschritt eines Sprints an. 

Beim Burn-down Chart wird die noch zu erledigende Arbeit ausgewiesen.

Beim Burn-up Chart die bereits erstellte Arbeit.

Niko-Niko Kalender

Niko-Niko Kalender in Scrum

Niko-Niko Kalender dient zum messen der Zufriedenheit.

Jedes Teammitglied zeigt pro Tag seine Stimmung mit einem Smiley auf.

So werden neben dem Arbeitsfortschritt auch Moral und Zufriedenheit gemessen.

Information Radiator

Information Radiator in Scrum

Information Radiator ist ein öffentlichkeits-wirksame Mittel, um Informationen zum Status des Projekts zugänglich und transparent zu machen.

Bei Scrum zeigt es auf einen Blick was erledigt wurde und was noch zu machen ist.

Welche der folgenden Antwortoptionen steht für eine Eigenschaft, die einen Information Radiator ausmacht?

  • Aktuell
  • Detailliert
  • Bedarfsbasiert bereitgestellt
  • Statisch

In den letzten 8 Sprints hat das Scrum-Team insgesamt 85 Story Points abgeschlossen. Das Scrum-Team wurde gebeten, ein neues Projekt zu bearbeiten, das geschätzte 64 Story Points umfasst. Wie viele Sprints sind zum Abschluss dieses Projekts erforderlich?

  • 5 Sprints
  • 7 Sprints
  • 8 Sprints
  • 10 Sprints

Der Fortschritt eines Sprints wird in einem Burn-Down Chart überwacht. Was wird im Burn-Down Chart dargestellt?

  • Wie viel Arbeit abgeschlossen wurde.
  • Wie viel Arbeit noch aussteht.
  • Die Velocity (Geschwindigkeit) des Entwicklungsteams.

Scrum Konzepte

Scrum-of-Scrum

Scrum-of-Scrum

Der Scrum-of-Scrum wird gebraucht, wenn mehrere Teams an einem Produkt arbeiten.

Es existiert dann 1 Product Backlog und 1 Product Owner sowie mehrere Teams mit je einem Scrum Master.

Alle Teams verstehen den Auftrag gleich.

Aufteilen von Scrum Teams

Aufteilen von Scrum Teams

Auch in Scrum müssen Änderungen an Teams vorgenommen werden.

Hierfür stehen die Methoden "Split and See" sowie "Grow and Split" zur Verfügung.

Ein Scrum-Team stellt fest, dass es nicht möglich sein wird, eine der Komponenten fristgerecht zu liefern, auf die ein anderes Scrum-Team wartet. Was bietet das beste Forum dafür, um darüber zu sprechen und eine Lösung zu finden?

  • Daily Scrum eines der Teams
  • Scrum-of-Scrums
  • Sprint Review
  • Sprint-Retrospektive