Scrum

• Wasserfall: es startet mit Design, dann wird der Code geschrieben, darauf folgt der Test und am Ende kommt Deploy

• Agil: es startet mit Design, dann wird abwechselnd mehrmals Code geschrieben und der Test durchgeführt, bevor es mit Deploy schließt

• die Werte auf der linken Seite werden höher eingeschätzt, obwohl die Werte auf der rechten Seite wichtig sind

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

1. Kunden durch frühe und kontinuierliche Auslieferung wertvoller Leistung zufrieden stellen

2. Änderungen sind selbst spät in der Entwicklung willkommen

3. Die Lieferung funktionierender Leistung sollte regelmäßig innerhalb weniger Wochen oder Monate erfolgen

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten

5. Organisieren Sie ihre Arbeit rund um motivierte Individuen

6. Informationen werden am effektivsten durch persönliche Gespräche vermittelt

7. Funktionierende Leistung ist der wichtigste Maßstab des Fortschritts

8. Agile Prozesse fördern nachhaltige Entwicklung

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität

10. Einfachheit ist essenziell

11. Die Selbstorganisation der Teams bei Planung und Umsetzung führt zu den besten Anforderungen, Entwürfen und Architekturen

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an

• Courage

• Focus

• Commitment

• Respect

• Openness

• Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

• Das Scrum‐Rahmenwerk ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum.

Kurz gesagt fordert Scrum, dass Scrum Master ein Umfeld fördert, in dem

1. ein Product Owner die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;

2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;

3. das Scrum Team und Stakeholder die Ergebnisse überprüfen und für den nächsten Sprint anpassen;

4. diese Schritte wiederholt werden.

• Scrum Master

• Developer

• Product Owner

• ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist.

• ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Ein Scrum Master versetzt das Scrum Team in die Lage, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.

• dient dem Scrum Team auf unterschiedliche Weise:

• die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen.

• sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.

• sind ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.

• ist auch für ein effektives Product Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst:

• das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren;

• die Product Backlog‐Einträge zu erstellen und klar zu kommunizieren;

• die Reihenfolge der Product Backlog‐Einträge festzulegen; und

• sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.

• sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, in jedem Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.

• Die spezifischen Fähigkeiten, die von Developern benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Sie sind jedoch immer ergebnisverantwortlich dafür,

• einen Plan für den Sprint zu erstellen, das Sprint Backlog;

• Qualität durch die Einhaltung einer Definition of Done einzubringen;

• täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und

• sich wechselseitig als Fachwissende zur Verantwortung zu ziehen.

• wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

• der Kunde ist meistens Stakeholder

• Sprint Planning

• Sprint

• Daily Scrum

• Sprint Review

• Sprint Retrospective

• Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.

• Product Owner stellen sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind.

Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden. Es sind Events mit fester Länge von einem Monat oder weniger.

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.

Das Daily Scrum ist ein 15‐minütiges Event für die Developer des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten.

Falls Product Owner oder Scrum Master aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt man als Developer teil.

Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.

Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.

Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint.

Das Sprint‐Ziel, die für den Sprint ausgewählten Product Backlog‐Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.

• Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder vor.

• Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

• Der Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt.

Sprint Retrospektive:

• Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

• Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief.

• Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

• Product Backlog

• Sprint Backlog

• Increment

Ein Product ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder, eindeutig definierte Nutzende. Ein Product kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.

Ein Increment ist ein konkreter Schritt in Richtung des Product‐Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.

Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für ein Product erforderlichen Qualitätsmaßnahmen (u.a. die Anforderungen) erfüllt. -> Das Akzeptanzkriterium einer umgesetzten Anforderung wird als Definition of Done bezeichnet.

• Das Product Backlog ist eine geordnete Liste der Anforderungen (Requirements) an das Produkt. Product Owner sind ergebnisverantwortlich für das Product Backlog.

• Die Einträge (Product Backlog Items PBI) an Anfang des PB sind konkreter als die am Ende.

Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie). Das Sprint Backlog ist ein Plan von und für die Developer.

Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Das Sprint‐Ziel wird während des Sprint Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt.

Verschiedene, wie…

• Burn‐Down‐Charts,

• Burn‐Up‐Charts oder

• Cumulative‐Flow‐Diagramme.

• maximal 10 Personen

• kleine Teams kommunizieren besser

• kleine Teams sind produktiver

• das Team bleibt flink

• ist aber groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertig zu stellen

• Team in mehrere zusammengehörende Scrum Teams reorganisieren

• alle konzentrieren sich auf das selbe Produkt

• deshalb Produktziel, Produkt Backlog und Product Owner:in teilen

Backlog

• Wir formulieren den geschäftliche Nutzen primär

• Wir vermeiden, Details zu früh einzuführen, die Designoptionen verhindern und Entwickler unangemessen auf eine Lösung festlegen

• Wir vermeiden Darstellung von nicht vorhandener Vollständigkeit und Übersichtlichkeit

• Wir schaffen hinreichend kleine Teile, die für Verhandlung und Bewegung im Backlog sorgen im weiteren Verlauf

• Wir überlassen technische Funktionen dem Architekt, Entwicklern, Testern, …

Sie definiert “eine kurze Beschreibung (Story) dessen, was ein Benutzer (User) will.” [https://scrumguide.de/user-story/; 24.11.2022]

Erstellung: Kunde, Kunden-Proxy, Product Owner und andere Benutzer, die einen Bedarf für das Produkt identifizieren, können zu User Storys beitragen.

Eigentum und Wartung: Der Product Owner ist Eigentümer der User Storys und für das Erstellen, Erfassen, Verwalten und Priorisieren verantwortlich.

Verwendung: Entwickler, Tester und technische Redakteure verwenden User Storys, um zu wissen, was sie implementieren müssen und wann sie fertig sind.

Product Owners verfolgen den Gesamtfortschritt basierend auf dem Status der User Storys nach. Das Management verfolgt User Storys üblicherweise zusammengefasst als Epic Storys oder nach Funktionen.

Als <Benutzer> will ich <Aktion>, um <Ergebnis> zu erzielen.

• Kriterien von 2003 nach Bill Wake, die eine gute User Story erfüllen soll:

  • Independent (of all others)

  • Negotiable (not a specific contract for features)

  • Valuable to the customer (keep the essence of the story)

  • Estimable (to a good approximation)

  • Small (so as to fit within an iteration)

  • Testable (in principle, even if there isn’t a test for it yet)

Tipp 1: Fokussieren Sie sich auf den Benutzer

Tipp 2: User Stories Schreiben ist Teamwork!

Tipp 3: Akzeptanz-Kriterien nicht vergessen!

Tipp 4: Machen Sie Ihre User Stories einfach, knapp, präzise und sichtbar

Tipp 5: Es gibt nicht nur User Stories!

• ID

• Wert oder Reihenfolge

• Name

• Inhalt

• Preis

• Definition of Ready

• Definitions of Done

ID ein eindeutiger Identifikator, einfach eine automatisch hochgezählte Zahl. Das dient dazu, die Spur der Storys nicht zu verlieren, wenn wir sie umbenennen.

Wert oder Reihenfolge - die meisten Backlog-Tools (auch Excel) erlauben drag&drop Sortierung womit ein expliziter Wert nicht mehr so wichtig ist

Name - ein kurzer, beschreibender Name der Story. Zum Beispiel „Sieh Deine Transaktionshistorie“ ... Aussagekräftig genug, damit Entwickler und Product Owner ungefähr verstehen, worüber sie reden und aussagekräftig genug, und es von anderen Storys zu unterscheiden. Normalerweise 2 bis 10 Wörter.

Inhalt - unsere eigentliche User Story (vgl. oben)

Preis – der Aufwand muss geschätzt werden, z.B. in Story Points (relativ) oder PT

Definition of Ready - die User Story mit seinen Attributen ist „abgezeichnet“ von Scrum Team und bereit in den Sprint einzugehen

Definitions of Done und die Akzeptanz-Kriterien - werden zu den Tests und beschreiben schon was im Sprint Review angeschaut werden soll