Ich arbeite für eine Webentwicklungsagentur. Ich übernehme die Verantwortung für die Verwaltung der Arbeit, die die Entwickler in unserem Unternehmen für unseren Kunden erledigen. Wir verwenden JIRA für die Aufgabenverwaltung.
Agile Methoden schlagen vor, Epics für User Stories zu verwenden, die in kleinere zerlegt werden können. Das Problem ist, dass die Arbeit mit dem Kunden wahrscheinlich eine lang anhaltende Partnerschaft sein wird, also gibt es immer Feature Creep. Mein Punkt ist, dass Epics endlich sein sollten, aber in meinem Fall neigen sie dazu, nie fertig zu werden, weil dem System immer neue Funktionen hinzugefügt werden.
Beispiele für Epics, die ich verwende, sind:
Vertragsliste
Als Benutzer muss ich in der Lage sein, Verträge aufzulisten und zu filtern, damit...
Vertragsredakteur
Als Benutzer muss ich Verträge bearbeiten können, damit..
Diese Epen scheinen, als würden sie Jahre dauern. Wie können wir den Umfang dieser Epics verwalten?
Stellen Sie sich Epics nach Möglichkeit als Platzhalter für detailliertere Product-Backlog-Einträge vor, nicht als immergrüne Geschichten. Es ist besser, dem Product Backlog neue Storys hinzuzufügen, sobald sie entdeckt oder angefordert werden, anstatt Scope Creep einzuladen, indem Epics als permanente Arbeitsgeneratoren für das Product Backlog missbraucht werden.
In agilen Methoden liefern Sie keine Epics oder Themen; Sie liefern Geschichten und Aufgaben. In Scrum sollten Sie auch in gut definierten Iterationen arbeiten, bei denen die Arbeit klein genug ist, um in einen einzigen Sprint zu passen.
Wenn du ein Epos hast wie:
Als Benutzer muss ich in der Lage sein, Verträge aufzulisten und zu filtern, damit...
es ist nicht wirklich umsetzbar, da es genau keines der INVEST-Kriterien erfüllt . Stattdessen sollten Sie Ihre Backlog-Refinement- und Sprint-Planning-Zeremonien nutzen, um bestimmte Funktionen in separate User Stories zu zerlegen.
Auch wenn Ihr Epic ein immergrünes Element ist, bei dem Sie Listen und Filtern immer neue Funktionen hinzufügen, sollte jede Story innerhalb des Epics klar abgegrenzt und klar definiert sein, bevor sie in den Sprint aufgenommen wird. Während der Backlog-Verfeinerung könnten Sie sich beispielsweise einige aktuelle Anfragen zu Ihrem Epic ansehen und eine Geschichte hinzufügen wie:
Als Benutzer
möchte ich alle nicht abgelaufenen Verträge nach Ablaufdatum auflisten
, damit ich sehen kann, welche demnächst ablaufen.
oder:
Als Benutzer
möchte ich alle abgelaufenen Verträge aus der To-Do-Liste herausfiltern,
damit ich nur noch gültige Verträge sehe.
Während diese beiden Geschichten durchaus in Ihr Epos passen könnten, sind sie wahrscheinlich klein genug, um in einen einzigen Sprint zu passen, sind wahrscheinlich testbar und beschreiben ein konkretes Wertversprechen.
Der Product Owner sollte aktiv daran beteiligt sein, Stakeholder dazu zu bringen, Arbeit als eigenständige Merkmale zu identifizieren. Das gesamte Scrum-Team sollte daran beteiligt sein, die größeren Epics und Stories zu zerlegen, damit der PO sie priorisieren kann.
Konzentrieren Sie sich auf die Bereitstellung kleiner, funktionaler Slices und nicht auf unschätzbare oder offene Arbeitsaufgaben. Wenn Sie Ihren Fokus ändern, werden Sie feststellen, dass Sie Funktionen liefern und jeden Sprint wertschätzen, anstatt einen episch geformten Albatros um den Hals zu tragen.
Wenn Sie zu viele epische Probleme haben, würde ich vorschlagen, sich Ihre Geschichten anzusehen und sie erneut zu untersuchen.
Die Ursache scheint darin zu liegen, dass Sie keine Werte liefern, indem Sie an User Stories arbeiten, sondern nur, indem Sie Epics liefern. (ich gehe davon aus)
Wenn das der Fall ist, müssen Sie mit Ihrem Kunden zusammenarbeiten, um wertvolle und kleine User Stories zu erstellen, was brutal schwierig ist. Andernfalls befinden Sie sich in dieser Endlosschleife für immer weiter und weiter und ...
Todd A. Jacobs