Ich schreibe User Stories für ein neues Projekt. Eines meiner Epen ist:
Als Firmeninhaber möchte ich ein grafisches Profil, damit ich meine visuelle Identität aufbauen kann .
Und dann gibt es mehrere User Stories, die mit diesem Epos verknüpft sind, um eine Farbpalette zu erstellen, ein Logo zu entwerfen und so weiter. Aber ich bin mir nicht sicher, welche Art von Details ich für das Epos selbst hinzufügen sollte. Was soll ich in die Beschreibung schreiben? Sollte das Epos Akzeptanzkriterien haben?
Eine Forderung ist, dass alle grafischen Elemente Vektoren sind; sollte das ein Akzeptanzkriterium für das Epos sein? Oder sollte es für alle User Stories dupliziert werden, die zu diesem Epic gehören?
Für mich ist ein Epic eine große User Story. Jedes Mal, wenn eine Anforderung an unser Team kommt und sie sehr groß erscheint (z. B. > 13 SP), ziehen wir es in Betracht, sie Epic statt Story zu nennen. Eine gute Metrik ist: Passt es in einen Sprint? Aber da die Anforderung an sich vollständig ist, würde eine einfache Aufteilung in kleinere Stories den Kontext verlieren. Man könnte also sagen, dass ein Epic eine Story ist, oder besser gesagt, es ist ein Container, der mehrere andere Storys enthält.
Atlassian beschreibt es so (1) :
Ein Epos ist ein umfangreiches Werk, das in mehrere kleinere Geschichten unterteilt werden kann. Zum Beispiel leistungsbezogene Arbeit in einem Release. Ein Epic kann mehr als ein Projekt umfassen, wenn mehrere Projekte in dem Board enthalten sind, zu dem das Epic gehört.
Ein Epic sollte im Vergleich zu Stories (die natürlich auch diese Elemente enthalten sollten) weniger technisch und mehr auf den Kundennutzen ausgerichtet sein. Versuchen Sie, Ihren Entwicklern so viele Anwendungsfallinformationen wie möglich zu geben. Ein Epic ist eher wie eine Vision, die Geschichten und Aufgaben sind die Dinge, um dorthin zu gelangen.
Sie entscheiden, ob Sie Akzeptanzkriterien für Ihr Epic benötigen und welche Details wichtig sind, um das gesamte Epic zu erledigen. In Ihrem Fall kann es sinnvoll sein, das Vektording hinzuzufügen, und es sollte beim Testen einer Story immer berücksichtigt werden. Alle Storys zusammen müssen die Anforderungen Ihres Epos erfüllen.
Vielleicht sind diese Antworten auch interessant:
Apropos JIRA: Das Erstellen eines Epic hat eine nette Unterstützung in JIRA und hilft Ihnen, auf einem höheren Niveau zu planen, als es mit mehreren Stories möglich wäre (z. B. Anzeigen des Epic-Berichts ) .
Was wird sich ändern, wenn Sie eine visuelle Identität haben? Wie misst man Erfolg?
Geschäftsziele erreichen, nicht nur Softwarefunktionen
Das Epic sollte sich um das Geschäftsziel drehen, nicht darum, was Sie bauen werden, um dieses Ziel zu erreichen. Es sollte erklären, warum und wie Sie das Erreichen des Ziels messen werden. Die Implementierungsdetails sind Teil der User-Stories.
Wann können Sie aufhören, Geschichten unter dem Epos zu implementieren? Muss man wirklich alle absolvieren? Ich denke, User-Stories sind lieferbare Optionen, um das Ziel zu erreichen, vielleicht liefert die erste Story schon genug Wert. Jetzt können Sie aufhören, die Optionen zu erstellen, und sich auf das nächste Epos konzentrieren.
Mir gefällt, wie Impact Mapping Ihnen dabei hilft, in messbaren Zielen und nicht in Ergebnissen zu denken.
Um Ihre Frage zu beantworten: Epics sollten messbare Ziele enthalten, keine Implementierungsdetails und / oder Optionen, um dies zu erreichen. Sicherlich sollte es keine doppelten Informationen enthalten. . Das Epic ist die Mission, auf der sich das Team befindet, es ist das Warum. Wo die User-Story das Was ist.
Im Idealfall kann das Team nun selbst entscheiden, wie es dieses Ziel am besten erreicht. Pro-aktive, selbstorganisierende Menschen liefern die besten Ergebnisse, sicherlich für kreative Prozesse wie Softwareentwicklung oder Designs.
Kurze Antwort:
Es gibt keine allgemein akzeptierte Definition eines Epos, also tun Sie, was für Ihr Team funktioniert. Sie sind kluge Leute, fragen Sie sie statt Fremde im Internet.
Etwas umstrittene Antwort:
Ich habe festgestellt, dass Epics am effektivsten sind, wenn sie ein Geschäftsziel und die Metriken angeben, die zur Bestimmung dieses Erfolgs verwendet werden.
Ex:
Steigerung der Klickrate auf unserer Homepage um 15 %
Beachten Sie, dass keine Anzeichen für ein Feature oder eine Geschichte in Sicht sind, die implementiert werden sollen? Es gibt nur ein wertvolles Geschäftsziel. Dies gibt Ihrem Team die Freiheit, Ideen zu sammeln, wie es dieses Ziel für Sie erreichen könnte. Jedes generierte Experiment kann anhand dieses Ziels ausprobiert und validiert werden. Das Epic ist fertig, wenn das Team das Ziel erreicht hat oder nahe genug gekommen ist, dass der PO entscheidet, dass es gut genug ist und andere, wichtigere Aufgaben für das Team zu erledigen sind.
Wie andere bereits betonten, gibt es keine universelle Definition eines Epos, daher basiert das Folgende auf meiner Arbeitserfahrung.
Was man nicht mit einem Epos machen sollte
In meiner Praxis kann ein Epic niemals direkt zu einem Sprint hinzugefügt werden.
Es ist zu weit gefasst, und eine komplexitätsbasierte Schätzung wäre viel zu ungenau, um überhaupt eine Chance zu haben, zu wissen, ob es in einen Sprint passen würde.
Es umfasst in der Regel mehrere User Stories, die jeweils unabhängig voneinander abgeschätzt und priorisiert werden müssen – nicht nur gegenüber anderen Stories als Teil dieses Epics, sondern auch gegenüber anderen Stories (aus anderen Epics).
Nur weil das Epos wichtig ist, heißt das nicht, dass jede Geschichte im Epos gleich wichtig ist. In Wirklichkeit werden es vielleicht nicht alle Geschichten, die als Teil eines Epos gedacht sind, jemals in das Projekt schaffen, wenn andere Prioritäten auftauchen.
Aus dem gleichen Grund ist es nicht sinnvoll, bei einzelnen Stories zu sehr ins Detail zu gehen, da zum Zeitpunkt der Erstellung des Epic noch nicht klar ist, welche Story es (wann) in einen Sprint und damit ins Produkt schafft.
Was tun mit einem Epos?
Ähnlich wie eine Story sollte ein Epic seine Existenz im Backlog rechtfertigen, indem es erklärt:
Da ein Epic mehr als eine Benutzerrolle umfassen kann, möglicherweise sogar mehr als eine Schnittstelle. Folglich ist es von Natur aus zu komplex, um es als eine lineare Geschichte aufzuschreiben.
Es muss schließlich in mehrere User Stories heruntergebrochen werden, denn nur gut gekapselte User Stories sollen es in einen Sprint schaffen.
Daher ist meine bevorzugte Art, ein Epic zu skizzieren, das Epic als eine entworfene Liste von User Stories zu schreiben, ohne bei jeder Story zu sehr ins Detail zu gehen.
Zum Beispiel:
Wenn Sie sich auf einen nächsten Sprint vorbereiten und es an der Zeit ist, das Epos anzugehen, können User Stories herausgebrochen und im vereinbarten Detail spezifiziert, priorisiert und für den Sprint geschätzt und/oder für den nächsten Sprint zurückgelassen werden, wenn die (erwartete) Geschwindigkeit nicht erreicht wird ausreichend, um alle Geschichten auf einmal anzugehen.
Meiner persönlichen Erfahrung nach ist das beste Epic dasjenige, das nicht mehr als eine breite Botschaft dessen vermittelt, worum es geht. Ein gutes Epic sollte weder den Spielraum haben, Vermutungen anzustellen, noch sollte es für jemanden, der gerade dem Projekt beigetreten ist, vage klingen.
Wenn ich ein Epos mache, versuche ich, mich von Zahlen und Lieferbarkeit fernzuhalten. Während der Planung würde mein ideales Epos so viele Diskussionen wie möglich innerhalb des Teams einladen, die dann in Geschichten dokumentiert würden. Wenn alle Geschichten mit ihren erwarteten Kriterien abgeschlossen sind, hat Epic seine Arbeit effizient erledigt.
Todd A. Jacobs
Andreas
pasler