Epen sind tot. Folgendes sollten wir stattdessen tun.

Was wurde noch nicht für tot erklärt? Test Driven Development wurde vor Jahren begraben. Trotzdem breitet es sich weiter aus. Natürlich ist auch Agile tot. Aber auch traditionelle Unternehmen kommen mit Scrum in Kontakt. Die Toten leben weiter, aber etwas für tot zu erklären ist immer gut für eine bissige Schlagzeile. In diesem Sinne bezeugen Sie, wie ich Epen als agile Praxis zerstöre.

Was sind Epen?

Der Begriff ist vage. Das hat Vorteile. Epen dienen eher der Kommunikation als der Spezifikation. Die Unbestimmtheit macht sie vielseitig. Es besteht jedoch die Gefahr von Missverständnissen. Ich halte mich an die Definition von Mike Cohn:

Ein Scrum-Epos ist eine große User Story. (Quelle)

Ich benutze den Begriff so: Ein Epos ist eine Geschichte, die zu groß ist, um in einem Scrum-Sprint implementiert zu werden. Die Elemente oben im Product Backlog sind also keine Epen, sondern kleine Geschichten. Unten im Backlog finden Sie normalerweise Epen. Im Laufe der Zeit werden die Epen in Geschichten „geschnitten“, die in einen Sprint gezogen werden können.

Das habe ich jahrelang in meinen Schulungen gelehrt. Es scheint der allgemeine Konsens zu sein. Auf den ersten Blick intuitiv. Ich bin hier, um zu erklären, warum es nicht praktisch ist.

3 unpraktische Möglichkeiten, mit Epen umzugehen

Bisher bin ich auf drei Arten gestoßen, wie Unternehmen mit Epen umgehen. Keiner von ihnen ist praktisch. Nennen wir sie:

Auflösung

Links

Bäume

1. Auflösung

Das Prinzip der Auflösung ist einfach. Ein Epos ist vollständig in seine Bestandteile zerlegt, die einzelnen kleinen Geschichten.

Beispielsweise kann ein epischer „Flug buchen“ eines Online-Flugportals in die einzelnen Prozessschritte unterteilt werden. Also "Anmelden", "Flug suchen" und so weiter. Jeder Prozessschritt wird zur Geschichte. Das Team schätzt die Geschichte. Solange es zu groß ist, schneidet das Team es weiter. Sobald alle Geschichten klein genug sind, um in Sprints zu passen, löscht das Team das Epos und beginnt mit der Entwicklung der Geschichten.

Es ist die Grundidee der Vollständigkeit, die mich stört. Die Auflösung legt nahe, dass ein Thema mit einem vorgegebenen Umfang abgeschlossen werden kann.

Wenn jedoch während der Entwicklung Änderungen an den Storys möglich sind, können Sie nicht alle Storys im Voraus definieren.

Der Scrum Guide sagt:

Ein Product Backlog ist niemals vollständig. […] Die Anforderungen ändern sich ständig.

Wenn Sie einen festen Umfang liefern müssen, hören Sie auf, so zu tun. Vergessen Sie Epen und beschreiben Sie die detaillierten Anforderungen im Voraus. Dann behaupten Sie einfach nicht, agil zu sein.

2. Links

Wenn Sie Ihre Epen nicht vollständig auflösen, ist es sinnvoll, Links zu verwenden. Die Epen bleiben unten im Rückstand. Sie verknüpfen neue kleine Geschichten mit den Epen, aus denen sie stammen.

Das Risiko besteht darin, dass mit der Zeit die Anzahl der Epen zunimmt. Der Rückstand wird aufgebläht. Es enthält Epen, die Sie nicht mehr brauchen. Der Stakeholder ist nicht mehr im Unternehmen. Oder das Thema ist nicht mehr relevant.

Natürlich können Sie von Zeit zu Zeit Ihren Rückstand bereinigen. Ich betrachte dies als nicht wertschöpfende Arbeit. Und Sie können es vermeiden, wie ich später beschreiben werde.

3. Bäume

Ein anderer Weg ist die Darstellung von Epen und Geschichten als Baum:

Sie gruppieren die kleinen Geschichten nach Epos. Keine schlechte Idee. Was Sie jedoch verlieren, ist die geordnete Liste des Rückstands. Wie bestimmen Sie dann die Implementierungsreihenfolge?

Natürlich können Sie ein digitales Tool verwenden, das beide Ansichten unterstützt. Das Risiko: Sie investieren zu viel Zeit und Mühe in die Werkzeuge. Was sind die Ansichten? Was sind die Attribute? Was ist das zugrunde liegende Datenmodell? Interessante Fragen. In einem agilen Ansatz sollten sie jedoch keine hohe Priorität haben.

Zusammenfassend ist die Idee der Gruppierung gut. Aber es ist zeitaufwändig.

Die Alternative zu Epen

Es gibt schon lange eine Alternative. Es wird sogar in demselben Blog-Beitrag von Mike Cohn erwähnt, den ich oben verlinkt habe.

Ich spreche über Themen .

Ein Thema kann als zusätzliches Attribut der Geschichten betrachtet werden. Normalerweise haben mehrere Geschichten dasselbe Thema. Die Geschichte "Flug suchen" könnte das Thema "Flug buchen" haben. Ein Ausschnitt aus dem Backlog könnte folgendermaßen aussehen:

Themen werden nicht als separate Backlog-Elemente verwaltet. Dadurch entfällt die im Kapitel Links beschriebene Bereinigungsarbeit. Das ist gut.

Was Sie jedoch verlieren, ist der Prozess der schrittweisen Verfeinerung von den großen Epen zu den Geschichten, die in einem Sprint implementiert werden können. Das ist schlecht.

Glücklicherweise gibt es Praktiken, die es ermöglichen, diese Verfeinerung außerhalb des Rückstands durchzuführen. Eine Möglichkeit, Themen zu identifizieren, ist ein Anwendungsfalldiagramm:

Das Schöne an solchen Diagrammen ist, dass sie aufgrund des hohen Abstraktionsgrades und der grafischen Darstellung das „Gesamtbild“ zeigen. Dafür ist ein Rückstand ungeeignet.

Die Anwendungsfallnamen werden später zu Themen im Backlog. Aber wie kommt man von den Anwendungsfällen zu den Geschichten? Dafür passt Jeff Pattons Story Mapping gut:

Die beiden oberen Zeilen der Beispielkarte zeigen die Anwendungsfälle "Flug buchen" und "Profil verwalten" sowie deren grundlegenden Ablauf. Unter den einzelnen Schritten hängt das Team die Alternativen auf: andere Prozesse, Fehler und so weiter. Diese gelben Notizen werden als Benutzeraufgaben bezeichnet.

In Backlog Refinement leitet das Team die Storys aus den Benutzeraufgaben ab. Eine Aufgabe kann als Titel der Geschichte dienen. Das Team fügt den Geschichten Details wie Akzeptanzkriterien hinzu.

Die Konsequenzen

Die Anwendung dieses alternativen Ansatzes hat Konsequenzen. Beispielsweise enthält das Product Backlog nur Storys für die nächsten 1–2 Sprints. Also vielleicht 10–20 Geschichten.

Alle Aktivitäten wie die weitere Priorisierung, Schätzung und Ausarbeitung der Akzeptanzkriterien finden nur mit diesen Geschichten statt. Wie das 10. agile Prinzip sagt:

Einfachheit - die Kunst, den Arbeitsaufwand zu maximieren - ist unerlässlich.

Wenn das Management Einblicke in den Entwicklungsfortschritt erhalten möchte, ist dies auf drei Ebenen möglich:

  • Anwendungsfalldiagramme oder -themen bieten die langfristige Perspektive für das Management. Für 1 Jahr oder sogar darüber hinaus. Aber: Sie eignen sich nicht zur Angabe von Details.
  • Story Maps bilden die Grundlage für die Release-Planung. An der Veröffentlichung interessierte Stakeholder erstellen mit den Teammitgliedern die Story Map. (Aufgrund neuer Erkenntnisse kann sich der Umfang während der Entwicklung ändern.)
  • Diejenigen, die einen tiefen Einblick haben und die Details während der Entwicklung beeinflussen möchten, nehmen an Sprint Review und Backlog Refinement teil .

Nur in geringer Höhe sehen wir die Details. Und das Product Backlog ist im Grunde wie eine Einkaufsliste. Würden Sie aufschreiben, was Sie in einem Jahr kaufen möchten?

Last but not least kündigt der Tod von Epen das Sterben des Konsums an. Wenn Sie etwas wollen, müssen Sie dem Team zustimmen und eng zusammenarbeiten.

Post mortem

In der Diskussion mit Kollegen wiesen sie darauf hin, dass auch nach der Auflösung eines Epos kleine Geschichten hinzugefügt werden können. Das ist richtig und für mich ist es eine akzeptable Lösung. Was in diesem Fall jedoch verloren geht, ist das „Gesamtbild“, das ich im Anwendungsfalldiagramm gezeigt habe.

Letztendlich bestimmt die Eignung eines Produkts für Benutzer seinen Erfolg. Nicht wie es gemacht wurde. Dies gilt für alle Entwicklungspraktiken, einschließlich Epen.

Vielleicht haben Sie einen vernünftigen Weg gefunden, um mit Epen umzugehen?

In meinem Online-Kurs erfahren Sie, wie Sie Ihr Product Backlog effektiv verwalten können. Dieser Artikel wurde erstmals auf HOOD Blog in deutscher Sprache veröffentlicht.