Meine Notizen zu Scrum – Artefakte

Das Product Backlog

Das Product Backlog ist der Schreibtisch, das Product Owners, welches immer aktuell und sauber geführt werden muss. Es ist eine priorisierte Liste mit Anforderungen / Requirements. Es besteht aus den User Stories, welche eine Anforderung in einem Satz erklären, den Akzeptanzkriterien, Schätzung der Komplexität und den Epics (Grosse Anforderungen, welche noch in User Stories aufgeteilt werden müssen)

DEEP- Kriterien

  • Detailed Appropriately (angemessen detailiert)
  • Estimated (geschätzt)
  • Emergent (mehr als eine Summe der Einzelteile)
  • Prioritized (priorisiert)

User Stories

INVEST-Kriterien:

  • Independent (unabhängig)
  • Negitiable (verhandelbar – veränderbar bis in Sprint Backlog aufgenommen)
  • Valueable (werthaltig)
  • Estimable (schätzbar)
  • Small (klein genug)
  • Testable (testbar)

Akzeptanzkriterien

  • Was muss sonst noch beachtet werden (Filterung, Sortierung…)

Möglicher Aufbau:

Als @Rolle@ @möchte ich@ Ziel, so dass @Nutzen@

Nützliche Links

Meine Notizen zu Scrum – Events

Sprint Zero

  • Projektspezifische Aspekte
    • Gemeinsame Vorstellung / Vision erhalten des Produktes
    • Wann und wo werden die Stakeholder eingebunden
    • Risiken, ungefähre Dauer und Kosten
  • Teamspezifische Aspekte
    • Arbeitszeiten, Werte, was ist die Projektsprache
    • Erstellung der
      • Definition of Done (Wann ist eine Anforderunge Fertig?)
      • Definition of Ready (Wie muss der Product Owner eine Anforderung beschreiben?)
  • Organisationsspezifische Aspekte
    • Schlüsseltermine
    • Informationen rund um das Projekt
    • Zusammenkommen mit Stakeholdern

Sprint Planning

  • Dauer von 1 bis 4 Std.
  • Formulierung des Sprint-Ziels
  • Was wird in diesem Sprint Umgesetzt?
    • Wie viele User Stories können im Sprint umgesetzt werden
    • Übernehmen ins Sprint Backlog

Benötigte Vorarbeiten:

  • Vorbereitetes Product Backlog
  • Vorstellung der Anforderungen (User Stories) durch den Product Owner
  • Erstellung des Sprint Backlogs

Daily Scrum Meeting

Ist ein Event für das Development Team. Product Owner und Scrum Master sind nicht zwingend erforderlich. Die Praxis zeigt aber, dass es doch empfehlends Wert ist.

  • Time Box von 15 min.
  • Jeder beantwortet diese Fragen:
    • Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
    • Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
    • Sehe ich irgendwelche Hindernisse (Impediments), die mich oder das Entwicklungsteam vom erreichen des Ziels abhalten?

Sprint Review

Am Ende des Sprints stellt das Entwicklungsteam die umgesetzten Anforderungen vor. Der Product Owner nimmt die User Stories ab. Der Scrum Master organisiert und moderiert (bei Unstimmigkeiten Entwicklungsteam – Product Owner) das Review.

  • Wiederholung des Sprint-Ziels
  • Vorstellung der neu gewonnen Funktionalitäten
  • Vorstellung der umgesetzten User Stories
  • Abnahme durch den Product Owner
    • Bei Abnahme: Anforderung gilt als umgesetzt
    • Bei Ablehnung durch eine der Begründungen:
      • Akzeptanzkriterium nicht erfült
      • Punkt der Definition of Done verletzt

Sprint Retrospektive

Für den Scrum Master ist sie das Herzstück des Frameworks. Im Fokus steht hier die Zusammenarbeit im Team und soll aufzeigen, was noch optimiert oder verbessert werden kann. Es sollen nur Personen aus dem Scrum Team teilnehmen.

  • Wie gut haben wir Scrum als Framework bereits adaptiert?
  • Wie läuft unsere Zusammenarbeit?
  • Was hinder uns, Scrum noch besser zu nutzen?

Folgende Regeln sind Zwingend zu befolgen:

Egal was wir heute erkennen, wir sind fest davon überzeugt, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.

Norman Kerth, 2001

Was auch immer in Vegas passiert, bleibt in Vegas.

Vegas-Regel

Sprint

  • Für den Scrum Master ist die Impediment-Liste das zentrale Artefakt für die allgemeine Organisation des Sprints
  • Der Scrum Master ist für einen reibungslosen Verlauf des Sprints verantwortlich
  • Der Product Owner sollte für den Rest des Teams zuallersrt als Ansprechpartner immer zu Verfügung stehen
  • Das Development Team sollte sich zuallererst während des Sprints Komplett aus sich selbst und sein Sprint Backlog konzentrieren

Nüztliche Links

Meine Notizen zu Scrum – Kurzüberblick

Meine Notizen zu Scrum – Rollen

Product Owner

Dem Product Owner gehört das Produkt, an dem gearbeitet wird. Er trägt die komplette Verantwortung hinter dem Wert des Produktes. Er ist die Schnittstelle zwischen dem Scrum Team und allen anderen Stakeholdern.

Wichtige Punkte:

  • Mit welchen Anforderungen kann ich den Wert des Produktes für alle Anwender maximieren?
  • Wann wird das Produkt / Inkrement ausgeliefert?

Scrum Master

Scrum Master ist ein Vorbild beim Scrum Prozess, er ist quasi der Motor des Scrum Prozesses.

  • Scrum Experte – Muss immer auf dem neusten Stand sein
  • Change Agent – Bei Einführung von Scrum trägt er eine wichtig Rolle mit
  • Facilitator – Kümmert sich um alle Probleme im Team und löst diese
  • Prozesswächter – Überwacht den Prozess / Rahmen – Events müssen korrekt durchgeführt werden
  • Coach – Moderiert, führt Gespräche

Development Team

Ist eigenverantwortlich für die Umsetzung des vom Product Owner gesetzten Anforderungen. Es muss für die Umsetzung alle benötigten Kompetenzen besitzen – es muss crossfunktional sein.

Nützliche Links:

Meine Notizen zu Scrum – Kurzüberblick

Meine Notizen zu Scrum – Kurzüberblick

Agiles Framework für die Produktentwicklung. Dabei ist das Framework ein leichtgewichtiges Framework und gibt nur einen groben Rahmen vor, lässt jedoch viel Spielraum offen.

Die 5 Prinzipien von Scrum:

  • Kurze Iterationen
  • Selbstorganisation
    • Team kann sich selbstorganisieren
    • Technischeumsetzung liegt in der freiheit des Teams
  • Inspect and Adapt (Überprüfen und Anpassen)
    • Stetige Überprüfung und massnahmen zur Verbesserung
  • Regelmässige Lieferung
    • Dadurch regelmässiges Feedback des Kunden
    • Entwicklung kann immer wieder bestmöglichst angepasst werden
  • Transparenz
    • Alle Aspekte müssen für alle beteiligten transparent sein

Der Rahmen des Framwork besteht aus:

  • Events (regelmässiges Zusammenkommen)
    • Sprint Planning
    • Daily Scrum (Daily Standups ca. 15 min.)
    • Scrum Review
      • Prüfung ob die Anforderungen / Inkremente wirklich umgesetzt wurden
      • Entsprechen sie dem gemeinsamen Verständnis von fertig (Done)
    • Scrum Retrospektive
      • Schliesst den Sprint ab
  • Rollen
    • Scrum Master
      • Coaching Rolle für den Product Owner, Development Team und Organisation, um Scrum zu verinnerlichen
      • Einen Rahmen zu schaffen, in dem jede Person seine Aufgabe bestmöglich ausüben kann
    • Product Owner
      • Für die fachlichen Anforderungen zuständig
      • Pflege des Product Backlog
    • Developmet Team
      • Zuständig für die Umsetzung der fachlichen Anforderungen
  • Artefakten
    • Product Backlog
      • Sammlung aller möglichen Anforderungen (User Stories, Epics) und Inkrementen
    • Sprint Backlog
      • Enthält alle Anforderungen, welche umgesetzt werden
      • Darf sich nie während einem sprint verändern

Nützliche Links

Meine Notizen zu Scrum – Rollen

Meine Notizen zu Scrum – Events

Meine Notizen zu Scrum – Artefakte

wikipedia: Scrum