ChatGPT 4: Ein Schnäppchen für Scrum-Praktiker? 🇩🇪

Als OpenAI letzte Woche sein neues LLM-Modell GPT-4 herausbrachte, konnte ich nicht widerstehen und habe mich für 20 Dollar pro Monat angemeldet. Ich wollte herausfinden, ob ChatGPT 4 seinem Vorgänger überlegen ist, der in den letzten Monaten einen guten Eindruck hinterlassen hat; siehe meine früheren Artikel zu Scrum, Agile und ChatGPT.

Ich habe mich für drei Vergleiche entschieden, bei denen die Antworten der neuen GPT-4- und der früheren GPT-3.5-Modelle über die identische Eingabeaufforderung ausgelöst wurden. Lesen Sie weiter und erfahren Sie, was dabei herausgekommen ist. Es war keine Selbstverständlichkeit.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 45.000 Abonnenten anschließen.

🎓 🇩🇪 Garantiert: Fortgeschrittenen Professional Scrum Master Online Schulung mit PSM II Zertifikat — 18. bis 21. April 2023.

📖 Lassen Sie sich benachrichtigen, wenn das Scrum Anti-Patterns Guide Buch verfügbar ist!

Einrichten der ChatGPT 4 Session

Ich habe die Session auf ChatGPT am Mittwoch, 15. März, von 5:40 Uhr MEZ bis 6:30 Uhr MEZ auf den Modellen GPT-3.5 und GPT-4 nach dem Upgrade auf ChatGPT Plus durchgeführt.

Ich habe Grammarly nicht auf die Antworten von ChatGPT angewendet. Zur Übersetzung habe ich Deepl.com Pro verwendet.

Die initiale Eingabeaufforderung von ChatGPT zur Erkundung des neuen Modus GPT-4

Ich habe die folgende Aufforderung verwendet, um ChatGPT zu starten: „Verwendest du die gleichen Trainingsdaten wie GPT-3.0 oder 3.5?„

ChatGPT-4.0:

Als GPT-4-Modell bin ich eine aktualisierte Version der früheren GPT-Modelle. Obwohl ich einige Ähnlichkeiten mit GPT-3 und GPT-3.5 habe, gibt es Unterschiede bei den Trainingsdaten, die für jedes Modell verwendet werden.

Der Hauptunterschied ist der Zeitraum, in dem die Daten verwendet wurden. GPT-3 und GPT-3.5 wurden mit Daten trainiert, die bis etwa 2020 bzw. 2021 verfügbar waren. In meinem Fall, als GPT-4, reichen meine Trainingsdaten bis September 2021. Das ermöglicht mir ein aktuelleres Verständnis der Welt, einschließlich neuerer Ereignisse und Entwicklungen.

Außerdem wurden wahrscheinlich zwischen den Versionen Verbesserungen bei der Datenkuration, der Vorverarbeitung und den Filtertechniken vorgenommen, was zu Unterschieden in der Qualität und dem Umfang der Trainingsdaten führt. Auch wenn die wichtigsten Datenquellen ähnlich sind, wie Bücher, Artikel und Websites, sind die Datensätze selbst nicht identisch.

Die Experimente

Nun, da wir die Hintergründe des Modells besser verstehen, wollen wir drei Experimente durchführen, um herauszufinden, welches Modell das Bessere ist. Ich werde drei Vergleiche oder A/B-Tests durchführen, bei denen ich die identische Eingabeaufforderung verwende, um die Antworten des neuen GPT-4 und des vorherigen GPT-3.5-Modells auszulösen:

1. Das erste Experiment vergleicht den Scrum Guide 2017 mit dem Scrum Guide 2020
2. Das zweite Experiment ist die Gestaltung einer Retrospektiven Übung
3. Das dritte Experiment soll einem neuen Scrum-Team helfen, eine Definition of Done zu entwerfen.

Erfahre mehr über das neue GPT-4 Modell im GPT-4 Developer Livestream vom 14. März 2023 von OpenAI oder im OpenAI GPT-4 Technical Report.

Experiment 1: Vergleich zwischen dem Scrum Guide 2017 und dem Scrum Guide 2020

Prompt: Ich möchte, dass du die Rolle eines Scrum Masters übernimmst. Sag mir: Was ist der Unterschied zwischen dem Scrum Guide 2017 und dem Scrum Guide 2020?

ChatGPT-3.5:

Als Scrum Master beantworte ich dir gerne deine Frage nach den Unterschieden zwischen dem Scrum Guide 2017 und dem Scrum Guide 2020.

Der Scrum Guide ist der offizielle Leitfaden für Scrum und bietet einen Rahmen für die Umsetzung und Verbesserung von Scrum-Praktiken. Die neueste Version des Scrum Guide wurde im November 2020 veröffentlicht und enthält mehrere Aktualisierungen gegenüber der Vorgängerversion aus dem Jahr 2017. Hier sind einige der wichtigsten Unterschiede zwischen den beiden Versionen:

1. Fokus auf das Scrum-Team: Der Scrum Guide 2020 legt mehr Wert auf das Scrum-Team und nicht nur auf das Entwicklungsteam. Der Product Owner und der Scrum Master werden jetzt als gleichberechtigte Mitglieder des Scrum Teams angesehen.
2. Empirische Prozesskontrolle: Der Scrum Guide 2020 hebt die Bedeutung der empirischen Prozesskontrolle und der drei Säulen Transparenz, Inspektion und Adaption hervor.
3. Aktualisierte Sprache: Die Sprache im Scrum Guide 2020 wurde aktualisiert, um inklusiver und geschlechtsneutral zu sein.
4. Vereinfachtes Rahmenwerk: Der Scrum Guide 2020 hat einige der präskriptiven Formulierungen aus der Vorgängerversion entfernt, um das Rahmenwerk flexibler und an verschiedene Kontexte anpassbar zu machen.
5. Verfeinerung statt Grooming: Der Begriff „Backlog Refinement“ wird jetzt anstelle von „Backlog Grooming“ verwendet, um den kontinuierlichen Verbesserungsaspekt der Praxis zu betonen.

Insgesamt zielen die Änderungen im Scrum Guide 2020 darauf ab, das Rahmenwerk zugänglicher zu machen und an ein breiteres Spektrum von Kontexten anzupassen, während die Kernprinzipien und Werte von Scrum erhalten bleiben.

Kommentar: Diese Antworten sind irrelevant oder Halluzinationen: Scrum Master und Product Owner sind jetzt „gleichberechtigte Mitglieder des Scrum Teams?“ Keine Erwähnung der Commitments, insbesondere des Produktziels? Hervorhebung der Bedeutung der empirischen Prozesskontrolle? Das war von Anfang an der Kern von Scrum. Die Antwort ist blamabel.

ChatGPT-4.0:

Als Sprachmodell kann ich dir die wichtigsten Unterschiede zwischen dem Scrum Guide 2017 und dem Scrum Guide 2020 nennen. Hier sind einige der bemerkenswertesten Änderungen:

Weniger präskriptiv und flexibler: Der Scrum Guide 2020 ist kürzer und konzentriert sich mehr auf die Kernkonzepte des Scrum Frameworks. Er hat den präskriptiven Charakter einiger Praktiken reduziert und ermöglicht den Teams mehr Flexibilität bei der Anwendung von Scrum je nach ihrem spezifischen Kontext.

Einführung des Product Goal: Die Version 2020 führt das Konzept des Produktziels ein, das eine langfristige Zielsetzung für das Produkt darstellt. Es gibt dem Team die Richtung vor, und alle Sprint-Ziele sollten auf das Product Goal ausgerichtet sein und zu ihm beitragen.

Vereinfachte Teamstruktur: Der Scrum Guide 2020 hebt die Unterscheidung zwischen Mitgliedern des Entwicklungsteams und anderen Rollen auf. Er bezeichnet nun das gesamte Team als „Scrum Team“, das aus dem Scrum Master, dem Product Owner und den Entwicklern besteht, die alle gemeinsam dafür verantwortlich sind, in jedem Sprint ein potenziell releasefähiges Inkrement zu liefern.

Ein größerer Fokus auf Commitment: Der Scrum Guide 2020 betont die Bedeutung des Commitments für jedes Artefakt. Das Produkt-Backlog enthält das Produktziel, das Sprint-Backlog das Sprint-Ziel und das Inkrement die Definition of Done. Diese Commitments helfen, Klarheit und Fokus für das Scrum Team zu schaffen.

Selbstverwaltend statt selbstorganisierend: In der Version 2020 werden Scrum Teams als selbstverwaltend bezeichnet, was ihre Autonomie bei der Entscheidung betont, wie sie das Sprint-Ziel erreichen und das Produktinkrement erstellen. Diese Änderung unterstreicht die Verantwortung des Teams, seine Arbeit selbst zu organisieren und zu verwalten, anstatt sich auf externe Anweisungen zu verlassen.

Abschaffung des Drei-Fragen-Formats der Sprint-Retrospektive: Der 2020 Scrum Guide schlägt nicht mehr das spezifische Drei-Fragen-Format vor („Was lief gut? Was könnt Ihr verbessern? Was werden wir im nächsten Sprint verbessern?“) für die Sprint-Retrospektive vor. Stattdessen wird die Notwendigkeit betont, Verbesserungen zu planen und eine Haltung der kontinuierlichen Verbesserung zu fördern.

Aktualisierung der Definition of Done: Der Scrum Guide 2020 stellt klar, dass die Definition of Done eine formale Beschreibung des Zustands des Inkrements ist, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt. Außerdem wird betont, dass die Definition of Done verwendet wird, um zu beurteilen, wann die Arbeit an dem Produktinkrement abgeschlossen ist.

Dies sind einige der Hauptunterschiede zwischen dem Scrum Guide 2017 und dem Scrum Guide 2020. Die Version 2020 zielt darauf ab, ein einfacheres, flexibleres und fokussierteres Rahmenwerk für Scrum-Praktiker zu bieten, das die Bedeutung von Teamzusammenarbeit, Engagement und kontinuierlicher Verbesserung betont.

Kommentar: Wir haben einen klaren Sieger! Die Antwort von GPT-4 ist besser und gehaltvoller als die des Vorgängermodells.

Zwischenstand: ChatGPT-4 — ChatGPT-3.5: 1-0.

ChatGPT 4 Experiment 2: Entwerfen einer Retrospektiven-Übung

Prompt: Ich möchte, dass du die Rolle eines erfahrenen Scrum Masters übernimmst.

Dein Scrum Team hatte einen problematischen Sprint und hat das Sprint-Ziel nicht erreicht. Einige Teammitglieder hatten unerwartet eine Lebensmittelvergiftung. Die Einkaufsabteilung hat es versäumt, die Kreditkarteninformationen für einen wichtigen Dienst, den dein Team nutzt, zu erneuern, und dieser Dienst war nicht mehr verfügbar. Außerdem ist das Scrum-Team auf unerwartete technische Schulden gestoßen, die im Legacy-Teil der Codebasis versteckt sind. Die Spannungen im Team sind groß; Streitigkeiten sind häufiger geworden. 

Als Scrum Master möchte ich, dass du dein Wissen über Scrum, iterative und inkrementelle Produktentwicklung, gewaltfreie Kommunikation, Zusammenarbeit, Teambildung, Scrum-Werte, Psychologie und Liberating Structures einsetzt, um eine Retrospektive zu gestalten, die dem Scrum-Team hilft, die jüngsten Rückschläge zu überwinden und die Beziehungen untereinander zu verbessern.

ChatGPT-3.5:

Es tut mir leid zu hören, dass dein Scrum-Team einen schwierigen Sprint hatte. Als erfahrener Scrum Master bin ich hier, um dir zu helfen, diese schwierige Situation zu meistern und eine Retrospektive zu gestalten, die dem Team hilft, die jüngsten Rückschläge zu überwinden und die Beziehungen zwischen den Teammitgliedern zu verbessern.

Zunächst ist es wichtig, anzuerkennen, dass Rückschläge und Herausforderungen ein natürlicher Teil des Scrum-Prozesses sind. Unser Ziel ist es nicht, Probleme zu beseitigen, sondern aus ihnen zu lernen und sie als Chance für Wachstum und Verbesserung zu nutzen.

Um die Retrospektive zu beginnen, müssen wir einen sicheren und respektvollen Raum schaffen, in dem sich die Teammitglieder ehrlich und offen äußern können. Eine Liberating Structure, die uns dabei helfen kann, ist die „1-2-4-All“-Struktur, bei der jeder Einzelne im Stillen nachdenkt, sich mit einem Partner austauscht, sich einer Vierergruppe anschließt, um seine Gedanken zu diskutieren, und dann die Ideen der Gruppe mit dem gesamten Team teilt.

Zunächst bitten wir das Team, über den vergangenen Sprint nachzudenken und herauszufinden, was gut gelaufen ist und was nicht wie geplant. Dann konzentrieren wir uns auf die Herausforderungen, die während des Sprints aufgetreten sind, wie z.B. unerwartete technische Schulden, Probleme mit der Kreditkarte und die Erkrankung von Teammitgliedern.

Wenn wir die Herausforderungen identifiziert haben, nutzen wir die Liberating Structure „TRIZ“, um mögliche Lösungen zu erkunden. TRIZ steht für „Theory of Inventive Problem Solving“ (Theorie des erfinderischen Problemlösens) und ist ein strukturierter Ansatz, um kreative Lösungen für komplexe Probleme zu finden. Wir bitten das Team, die Ursache für jedes Problem zu identifizieren und dann mit Hilfe der TRIZ neue Ideen für die Lösung dieser Probleme zu entwickeln.

Als Nächstes verwenden wir das Liberating Structure „Celebrity Interview“, um Empathie und Verständnis unter den Teammitgliedern zu fördern. Jedes Teammitglied schlüpft in die Rolle eines „Prominenten“, der bestimmte Werte oder Eigenschaften verkörpert, und das Team stellt ihm Fragen dazu, wie er mit den jüngsten Rückschlägen umgehen würde.

Während der Retrospektive betonen wir die Bedeutung von gewaltfreier Kommunikation und Zusammenarbeit und erinnern das Team an die Scrum-Werte Commitment, Mut, Fokus, Offenheit und Respekt.

Am Ende der Retrospektive ist es unser Ziel, konkrete Schritte zu identifizieren, die das Team unternehmen kann, um die Herausforderungen, die während des letzten Sprints aufgetreten sind, anzugehen und die Beziehungen untereinander zu verbessern. Wir erstellen einen Aktionsplan, der diese Schritte beschreibt und weisen jeder Aufgabe Verantwortliche zu, um sicherzustellen, dass sie auch wirklich umgesetzt wird.

Kommentar: Klingt zunächst gut, nicht wahr? Schade, dass der Vorschlag den Test nicht besteht. Natürlich könntest du 1-2-4-All verwenden, um die Retrospektive zu starten. Wenn aber jedes Teammitglied zu Wort kommen soll, wäre eine Struktur wie das „Conversation Café“ besser geeignet. Anstelle von TRIZ würde ich „Nine Whys“ oder „What. So What. Was jetzt?“ wählen; TRIZ ist für den beabsichtigten Zweck unbrauchbar. Schließlich ist das „Celebrity Interview“ für den beabsichtigten Zweck ungeeignet. Wenn Empathie dein Hauptanliegen ist, wäre „Heard, Seen, Respected“ die bessere Wahl.

ChatGPT-4.0:

Als erfahrener Scrum Master würde ich eine Retrospektive entwerfen, die nicht nur auf die Rückschläge eingeht, sondern sich auch darauf konzentriert, das Vertrauen wiederherzustellen, die Kommunikation zu verbessern und ein kollaboratives Umfeld innerhalb des Teams zu fördern. Die Retrospektive wird folgende fünf Schritte beinhalten:

1. Einleitung: Beginne die Runde, indem du die Herausforderungen, denen das Team während des Sprints begegnet ist, anerkennst und betonst, wie wichtig es ist, aus Rückschlägen zu lernen. Ermutige alle, sich in einer sicheren, offenen und respektvollen Umgebung zu beteiligen. Nutze eine kurze Eisbrecher-Aktivität, um das Team zu entspannen und auf die Sitzung vorzubereiten.
2. Daten sammeln: Beginne damit, dass du die Teammitglieder bittest, auf Haftnotizen zu notieren, was gut gelaufen ist, was nicht gut gelaufen ist und welche Ereignisse während des Sprints überraschend waren. Verwende eine Zeitleiste, um die Ereignisse zu visualisieren und Muster zu erkennen. Bitte das Team, offen über seine Erfahrungen zu sprechen und dabei die Grundsätze der gewaltfreien Kommunikation zu beachten.
3. Einblicke gewinnen: Verwende die „5 Whys“-Technik oder das „Fishbone“-Diagramm, um die Ursachen der Probleme zu analysieren. Ermutige das Team, sich auf den Prozess und nicht auf einzelne Personen zu konzentrieren. Betone die Scrum-Werte wie Mut und Offenheit, während du die Probleme besprichst. Moderiere eine Diskussion über die Auswirkungen der unerwarteten technischen Schulden und darüber, wie man sie in Zukunft angehen kann. Besprich auch, wie die Kommunikation mit der Beschaffungsabteilung verbessert werden kann, um zukünftige Serviceunterbrechungen zu vermeiden.
4. Entscheide, was zu tun ist: Leite das Team dazu an, gemeinsam Maßnahmen zu erarbeiten, um die Ursachen der Probleme zu beseitigen. Setze Prioritäten, indem du das Team über die wichtigsten Punkte abstimmen lässt. Ermutige das Team dazu, sowohl kurzfristige als auch langfristige Maßnahmen zu entwickeln. Eine kurzfristige Aktion könnte zum Beispiel die Erstellung einer Checkliste für Beschaffungsprozesse sein, während eine langfristige Aktion die Implementierung von automatisierten Tests zur Aufdeckung versteckter technischer Schulden beinhalten könnte.
5. Schließen Sie die Retrospektive: Beenden Sie die Sitzung mit einer teambildenden Aktivität, die die Scrum-Werte stärkt und die Zusammenarbeit fördert. Bitte die Teammitglieder, etwas Positives über ihre Kollegen zu erzählen oder sich für etwas zu bedanken, das ein Teamkollege während des Sprints getan hat. Das wird dazu beitragen, die Beziehungen zu verbessern und Spannungen zwischen den Teammitgliedern abzubauen. Schließe die Retrospektive ab, indem du die wichtigsten Erkenntnisse und die vereinbarten Aktionspunkte zusammenfasst und die Bedeutung von kontinuierlicher Verbesserung und Zusammenarbeit betonst.

Fahre in den kommenden Sprints mit dem Team nach, um sicherzustellen, dass die Aktionspunkte umgesetzt werden und um die Wirksamkeit der Verbesserungen zu beurteilen. Ermutige das Team zu einer offenen Kommunikation und zur gegenseitigen Unterstützung bei der Arbeit an den Zielen.

Folgefrage: Ist es notwendig, die Retrospektive auf diese strenge, präskriptive Weise durchzuführen?

ChatGPT-4.0:

Die von mir vorgestellte Fünf-Schritte-Struktur ist zwar eine beliebte und effektive Methode zur Durchführung von Retrospektiven, aber es ist nicht zwingend notwendig, ihr strikt zu folgen. Als Scrum Master solltest du flexibel sein und das Format je nach den Bedürfnissen, Vorlieben und der spezifischen Situation deines Teams adaptieren.

Es ist wichtig, die Grundprinzipien einer Retrospektive beizubehalten. Dazu gehören die Schaffung eines sicheren und offenen Umfelds für Diskussionen, die Reflexion des vergangenen Sprints, die Gewinnung von Erkenntnissen, die Identifizierung von Verbesserungen und die Förderung eines Gefühls der Zusammenarbeit und kontinuierlichen Verbesserung im Team.

Um diese Ziele zu erreichen, kannst du mit verschiedenen Techniken und Aktivitäten experimentieren, und erfahrene Scrum Master passen die Retrospektiven häufig an die Dynamik ihres Teams an. Einige alternative Ansätze sind:

1. Lean Coffee: Ein strukturiertes Meeting ohne Tagesordnung, bei dem die Teilnehmer demokratisch über die Themen entscheiden können, die sie besprechen wollen.
2. World Café: Eine Technik, die rotierende Kleingruppendiskussionen nutzt, um von allen Teammitgliedern Input zu verschiedenen Themen zu erhalten.
3. Starfish: Eine visuelle Methode, um festzuhalten, womit das Team beginnen, aufhören, weitermachen, mehr tun und weniger tun sollte.

Das Wichtigste ist, dass du für das Feedback deines Teams offen bist und den Retrospektivprozess kontinuierlich verbesserst, damit er für alle Beteiligten wertvoll und interessant bleibt.

Kommentar: Der erste Vorschlag war lediglich eine Standardanwendung des Modells von Esther Derby und Diana Larsen, bei dem die zusätzlichen Informationen zur Situation aus dem Prompt ignoriert wurden. Wenn wir auch die Antwort auf die Folgefrage berücksichtigen, wird die GPT-4-basierte Leistung etwas besser, obwohl sie nach wie vor bestenfalls mittelmäßig ist. Eine solche Leistung ist jedoch manchmal ausreichend, wenn die Antwort des Wettbewerbers noch schlechter ist.

Zwischenstand: ChatGPT-4 — ChatGPT-3.5: 2-0.

Experiment 3: Hilf einem neuen Scrum-Team, eine Definition of Done zu entwerfen

Prompt: Ich möchte, dass du die Rolle eines erfahrenen Scrum Masters übernimmst.

Die Definition of Done ist entscheidend für den Erfolg eines Scrum-Teams. Sie definiert den Qualitätsstandard, den die Stakeholder und die Governance-Gremien von jedem Inkrement erwarten. Das Qualitätsniveau muss nicht in allen Situationen perfekt oder erstklassig sein. Entscheidend ist jedoch, dass ein Inkrement, sobald es „done“ ist, ohne rechtliche, ethische oder finanzielle Auswirkungen an die Kunden ausgeliefert werden kann. 

Ich möchte, dass du dein Wissen über Scrum, iterative und inkrementelle Produktentwicklung, Zusammenarbeit, Produktmanagement, Zusammenarbeit mit Stakeholdern, Qualitätsmanagement, Innovation und geschäftliche Agilität im Allgemeinen einsetzt, um einen Prozess vorzuschlagen, wie ein neues Scrum-Team eine erste Definition of Done erstellen und sie dann entsprechend pflegen kann.

ChatGPT-3.5:

Sicher, ich helfe dir gerne dabei.

Eine erste Definition of Done erstellen:

1. Kooperiere mit dem Team: Als Scrum Master musst du mit dem Team zusammenarbeiten, um eine Definition of Done zu erstellen, mit der alle einverstanden sind. Du kannst eine Diskussion während einer Sprint Retrospektive oder eines speziellen Definition of Done-Workshops moderieren, um sicherzustellen, dass alle Stimmen gehört werden.
2. Die Erwartungen der Stakeholder verstehen: Es ist wichtig zu verstehen, was die Stakeholder von dem Produkt erwarten und welche Qualitätsstandards sie im Sinn haben. Das Team sollte diese Erwartungen in die Definition of Done einfließen lassen, um sicherzustellen, dass das Produkt die Erwartungen der Stakeholder erfüllt.
3. Identifiziere Qualitätsmetriken: Lege die Metriken fest, mit denen du die Qualität messen kannst. Metriken wie Code Coverage, Leistung und Sicherheit können helfen, die Definition of Done zu bestimmen. Das Team sollte sich bemühen, diese Metriken zu erfüllen, wenn es ein potenziell veröffentlichungsfähiges Inkrement abliefert.
4. Berücksichtige technische Schulden: Teams sollten die technischen Schulden berücksichtigen, die sie bei der Entwicklung eines Features in Kauf nehmen wollen. Technische Schulden sind die Kosten für Nacharbeiten, die durch z. B. qualitativ minderwertige Lösungen oder die Verzögerung von Erhaltungsarbeiten entstehen. Das Team sollte den Grad der technischen Schuld festlegen, den es bereit ist, zu akzeptieren, und dies den Stakeholdern mitteilen.
5. Keep it simple: Die Definition of Done sollte prägnant, klar und leicht verständlich sein. Sie sollte in einer Sprache verfasst sein, die für alle Teammitglieder und Stakeholder verständlich ist.

Die Definition of Done pflegen:

1. Regelmäßige Überprüfung und Aktualisierung der Definition of Done: Die Definition of Done sollte regelmäßig überprüft und aktualisiert werden. Das kann während Sprint-Retrospektiven oder speziellen Definition of Done-Workshops geschehen. Das Team sollte das Feedback der Stakeholder berücksichtigen und die notwendigen Änderungen an der Definition of Done vornehmen.
2. Kommuniziere die Änderungen an die Stakeholder: Wann immer die Definition of Done geändert wird, sollte das Team dies den Interessengruppen mitteilen. So wird sichergestellt, dass alle Beteiligten auf derselben Seite stehen und das Produkt den Erwartungen entspricht.
3. Benutze die Definition of Done während der Sprint Reviews: Während der Sprint Reviews sollte das Team die Definition of Done verwenden, um festzustellen, ob das Inkrement bereit für die Veröffentlichung ist. Wenn es nicht der Definition of Done entspricht, sollte das Team die Lücken identifizieren und daran arbeiten, sie im nächsten Sprint zu schließen.
4. Fortschritt verfolgen und melden: Die Teams sollten den Fortschritt anhand der Definition of Done-Metriken verfolgen und melden. Dies kann helfen, Bereiche zu identifizieren, in denen Verbesserungen notwendig sind, und die kontinuierliche Verbesserung voranzutreiben.
5. Feedback zur Verbesserung nutzen: Das Team sollte das Feedback der Beteiligten nutzen, um die Definition of Done zu verbessern. Das kann geschehen, indem es das Feedback in die Definition of Done einbezieht oder die Messgrößen zur Qualitätsmessung anpasst.

Gesamt gesehen ist die Erstellung und Pflege einer Definition of Done entscheidend für den Erfolg eines Scrum-Teams. Wenn das Team diese Schritte befolgt, kann es sicherstellen, dass es qualitativ hochwertige Inkremente abliefert, die die Erwartungen der Stakeholder erfüllen und ohne rechtliche, ethische oder finanzielle Auswirkungen freigegeben werden können.

Kommentar: Wow, wer hätte gedacht, dass ChatGPT-3.5 auf einem so guten Niveau arbeiten kann? Der Ansatz ist gemeinschaftlich und integrativ, technische Schuld ist Teil der Überlegungen, und die Definition of Done soll einfach sein und regelmäßig inspiziert und adaptiert werden, wobei das Feedback der Stakeholder genauso wertvoll ist wie die Daten aus der Verfolgung geeigneter Metriken.

ChatGPT-4.0:

Als erfahrener Scrum Master empfehle ich einem neuen Scrum-Team den folgenden Prozess, um eine erste Definition of Done (DoD) zu erstellen und zu pflegen:

1. Inputs sammeln: Beginne damit, Inputs vom Scrum-Team, den Stakeholdern, den Leitungsgremien und allen bestehenden organisatorischen Standards oder Richtlinien zu sammeln. Diese Informationen helfen dabei, die grundlegenden Qualitätserwartungen und -einschränkungen für das Produkt festzulegen.
2. Aufklärung des Teams: Stelle sicher, dass alle Teammitglieder den Zweck und die Bedeutung der DoD verstehen. Erkläre, wie sie dazu beiträgt, Transparenz zu schaffen, Erwartungen zu steuern und ein potenziell veröffentlichungsfähiges Produktinkrement zu gewährleisten.
3. Kollaborativer Workshop: Organisiere einen Workshop mit dem Scrum-Team, dem Product Owner und den relevanten Stakeholdern, um gemeinsam das erste DoD zu erstellen. Moderiere Diskussionen über die Qualitätsstandards und Akzeptanzkriterien, einschließlich funktionaler und nicht-funktionaler Anforderungen, Leistung, Sicherheit, Benutzerfreundlichkeit und Compliance.
4. Entwirf die Definition of Done: Erstelle auf der Grundlage der Workshop-Ergebnisse einen Entwurf der DoD mit einer klaren und präzisen Liste von Kriterien, die erfüllt sein müssen, damit ein Inkrement als „done“ gilt. Achte darauf, dass die Kriterien messbar und erreichbar sind und mit der allgemeinen Produktvision übereinstimmen.
5. Überprüfen und verfeinern: Präsentiere den Entwurf der DoD dem Scrum-Team, dem Product Owner und den Stakeholdern zur Überprüfung und zum Feedback. Nimm alle notwendigen Anpassungen auf der Grundlage ihrer Beiträge vor und überarbeite ihn, bis ein Konsens erreicht ist.
6. Kommunizieren und veröffentlichen: Sobald die erste DoD fertiggestellt ist, solltest du sie allen Beteiligten mitteilen und sie gut sichtbar im Arbeitsbereich des Teams oder auf einer gemeinsamen Online-Plattform aushängen. So wird sichergestellt, dass jeder die Erwartungen kennt und bei Bedarf auf die DoD verweisen kann.
7. Regelmäßige Überprüfung und Aktualisierung: Integriere eine Überprüfung der DoD in die Retrospektiven des Teams oder plane regelmäßige Überprüfungen, um sicherzustellen, dass sie relevant bleibt und mit der Entwicklung des Produkts übereinstimmt. Aktualisiere die DoD bei Bedarf auf der Grundlage der gemachten Erfahrungen, der sich ändernden Anforderungen, des Feedbacks der Stakeholder und aller Änderungen der organisatorischen Standards oder Vorschriften.
8. Überwachung der Einhaltung: Als Scrum Master überwachst du die Einhaltung der DoD durch das Team während jedes Sprints. Unterstütze und leite das Team bei der Einhaltung der festgelegten Kriterien und gehe alle auftretenden Herausforderungen an.

Mit diesem Prozess kann ein neues Scrum-Team eine anfängliche Definition of Done erstellen und diese beibehalten, um während des gesamten Lebenszyklus der Produktentwicklung eine gleichbleibende Qualität und die Übereinstimmung mit den Erwartungen der Stakeholder zu gewährleisten.

Kommentar: Das ist unerwartet. Es klingt wie eine PMI-Broschüre.

Folgefrage: Dein Vorschlag enthält zu viel Projektmanagement-Denken und ignoriert die Bedeutung von Zusammenarbeit und Teamwork in einem Scrum-Team. Zum Teil ist er schlichtweg falsch: Scrum Master erstellen nicht die anfängliche Definition of Done. Sie sorgen auch nicht dafür, dass die Vorgaben eingehalten werden; das ist die Aufgabe der Entwickler. Erstelle die Antwort auf der Grundlage der ersten Prinzipien von Scrum – Selbstmanagement und Servant Leadership – neu. 

ChatGPT-4.0:

Ich entschuldige mich für etwaige Missverständnisse in meiner vorherigen Antwort. Als Scrum Master ist es deine Aufgabe, das Team bei der Erstellung und Aufrechterhaltung der Definition of Done (DoD) zu unterstützen und anzuleiten und dabei die Bedeutung von Zusammenarbeit, Teamwork und Selbstmanagement zu betonen. Hier ist ein aktualisierter Ansatz, der auf den ersten Prinzipien von Scrum basiert:

1. Kontext schaffen: Stelle sicher, dass das Scrum-Team, einschließlich des Product Owners, den Zweck und die Bedeutung des DoD versteht. Erkläre, wie sie dazu beiträgt, ein gemeinsames Verständnis von Qualitätsstandards zu schaffen, Erwartungen zu steuern und ein potenziell releasefähiges Produktinkrement sicherzustellen.
2. Fördere die Zusammenarbeit: Ermutige das Scrum-Team, mit Stakeholdern, Leitungsgremien und bestehenden organisatorischen Standards oder Richtlinien zusammenzuarbeiten, um Inputs zu sammeln, die dabei helfen, die grundlegenden Qualitätserwartungen und -einschränkungen für das Produkt festzulegen.
3. Autorisiere das Team: Unterstütze die Entwickler bei der Organisation eines Workshops oder einer Reihe von Diskussionen, in denen sie gemeinsam die erste DoD erstellen können. Ermutige sie, funktionale und nicht-funktionale Anforderungen, Leistung, Sicherheit, Benutzerfreundlichkeit und Compliance zu berücksichtigen.
4. Verbesserung und Konsens: Während die Entwickler die DoD entwerfen, kannst du Diskussionen und Feedbackschleifen zwischen dem Team, dem Product Owner und den Stakeholdern fördern. Hilf ihnen dabei, die DoD so lange zu überarbeiten, bis ein Konsens über die Kriterien erreicht ist, die erfüllt sein müssen, damit ein Inkrement als „done“ angesehen werden kann
5. .
6. Fördere die Transparenz: Sobald die anfängliche DoD fertiggestellt ist, solltest du die Entwickler/innen dazu ermutigen, sie allen relevanten Parteien mitzuteilen und sie gut sichtbar im Arbeitsbereich des Teams oder auf einer gemeinsamen Online-Plattform auszuhängen. So wird sichergestellt, dass jeder die Erwartungen kennt und bei Bedarf auf die DoD verweisen kann.
7. Fördere die kontinuierliche Verbesserung: Erinnere das Team während der Retrospektiven daran, die DoD zu überprüfen und mögliche Verbesserungen oder Anpassungen zu besprechen, die sich aus den gemachten Erfahrungen, geänderten Anforderungen, dem Feedback der Stakeholder oder Änderungen der organisatorischen Standards oder Vorschriften ergeben.
8. Einhaltung der Vorschriften unterstützen: Als Servant Leader hilfst du den Entwicklern bei der Einhaltung der DoD in jedem Sprint. Ermutige eine offene Kommunikation und sprich alle Herausforderungen an, die sich ergeben. Denke daran, dass die Verantwortung für die Einhaltung der DoD-Kriterien bei den Entwicklern liegt, nicht beim Scrum Master.

Mit diesem Ansatz kannst du das Scrum-Team in die Lage versetzen, eine Definition of Done zu schaffen und zu pflegen, die auf Zusammenarbeit, Selbstmanagement und kontinuierlicher Verbesserung beruht und gleichzeitig den Prinzipien der dienenden Führung treu bleibt.

Kommentar: ChatGPT-4.0 spricht viel über Zusammenarbeit, Selbstmanagement und kontinuierliche Verbesserung. Es scheint aber immer noch so, als ob der Scrum Master dafür zuständig ist, die Entwickler in die richtige Richtung zu drängen. Ehrlich gesagt, gefällt mir die Antwort von ChatGPT-3.5 besser. PS: Der Product Owner ist auch Mitglied des Scrum Teams.

Endstand: ChatGPT-4 — ChatGPT-3.5: 2-1.

Fazit

ChatGPT, das auf dem GPT-4-Modell basiert, hat Vorteile gegenüber dem „alten“ GPT-3.5-Modell. OpenAI hat eine verbesserte Argumentation und Prägnanz versprochen und dies mit GPT-4 auch eingehalten. Nach den drei kurzen Alltagsexperimenten zu urteilen, ist der Vorteil des neuen Modells jedoch nicht so überzeugend wie erwartet. Warten wir also auf GPT-5. Trotzdem werde ich mein Abonnement fortsetzen.

Was ist Ihre Meinung als Scrum-Praktiker: Ist ChatGPT-4.0 es wert, im Vergleich zu ChatGPT-3.5 $20 pro Monat auszugeben? Bitte teile Sie uns Ihre Meinung in den Kommentaren mit.

📖 ChatGPT 4 — Weitere Lektüre

Der Stoische Scrum Master

Club Scrum: ChatGPT, was machst Du den ganzen Tag als Scrum Master?

ChatGPT-Prompts für Scrum Master, Product Owner und Entwickler

Agile Transformation mit ChatGPT oder McBoston?

Ein ChatGPT Jobinterview für eine Scrum-Master-Position

Generative KI: ChatGPT von OpenAI über Business Agilität und Scrum

What Is ChatGPT Doing … and Why Does It Work?

✋ Nicht versäumen: Lernen Sie mehr über ChatGPT 4 in der 12.000-köpfigen „Hands-on Agile“ Slack-Community

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel ChatGPT 4: Ein Schnäppchen für Scrum-Praktiker? wurde zunächst auf Berlin-Product-People.com veröffentlicht.