Was sind die Unterschiede zwischen agilen Epen und User Stories? User Stories sind ein grundlegender Bestandteil jeder agilen Entwicklung. Es handelt sich um leichte Anforderungen, die neue Funktionen darstellen, die den Stakeholdern des Unternehmens einen Mehrwert bieten.einschließlich Endbenutzer. Sie sind die Bausteine, die für den Produktrückstand priorisiert und in Sprints gebracht werden, und sie konzentrieren das Entwicklungsteam auf die Bereitstellung von Geschäftswert.
Also, was ist ein Epos?,
Wenn Sie mit agilen Entwicklern herumhängen, werden Sie diesen Begriff von Zeit zu Zeit auch hören. Und sie klingen wie User Stories. Aber sind sie? In diesem Beitrag werde ich mich mit den Unterschieden zwischen Epen und User Stories befassen: Was sie sind, wie sie zusammenhängen und warum Sie beides für Ihre agilen Entwicklungsprojekte benötigen.
Was ist eine User Story?
Zuvor habe ich mir eingehend angesehen, was User Stories sind und wie sie erstellt werden.,
Zusammenfassend beginnt eine User Story mit einer einfachen Aussage in Form von:
Als , ich will , also ich
Zu dieser Aussage fügen wir eine Vielzahl von Details hinzu, bestehend aus den Akzeptanzkriterien und den Diskussionshinweisen des Entwicklungsteams.
Sobald diese Elemente alle vorhanden sind, gilt die User Story als produktionsbereit. Es kann dann in den nächsten Sprint aufgenommen werden… wenn es vom Product Owner hoch genug priorisiert wird.
Was ist ein Epos?
Ein Epos ist eine große User Story., Der Begriff wird oft verwendet, um unglaublich lange Geschichten zu beschreiben, wie Paradise Lost, geschrieben vom englischen Dichter John Milton aus dem 17. Miltons“ episches “ Gedicht bestand ursprünglich aus mehr als zehn Bänden mit mehr als zehntausend Versen.
In Bezug auf die Softwareentwicklung ist es jedoch umso wahrscheinlicher, dass Sie sich ein Epos ansehen, je größer die Geschichte ist. Dies ist der wichtigste Unterschied zwischen agilen Epen und User Stories.
Das war ‚ s. Nichts Besonderes hier. Keine Notwendigkeit, sich in Knoten zu binden, um herauszufinden, “ Sollte dies ein Epos oder eine Geschichte sein?,“Wenn es etwas ist, das Geschäftswert bietet und im Produktrückstand sein muss, ist es eine User Story. Aber es kann auch ein Epos sein, weil es groß ist.
Was bedeutet „groß“ eigentlich?, In den Jahren, in denen ich Scrum verwendet habe, sind die besten zwei Definitionen, die ich gefunden habe:
- Ein Epos ist eine Geschichte, die größer als 8 Story Points ist
- Ein Epos ist eine Geschichte, die nicht in einem Sprint abgeschlossen werden kann
Ich denke, die zweite Definition ist besser, da sie sich nicht auf die Verwendung von Story Points zur Schätzung stützt (obwohl Sie lesen können, warum ich Story Point estimating liebe) und unabhängig von der Geschwindigkeit Ihres jeweiligen Teams ist.
Epen können von Benutzergeschichten reichen, die fast klein genug sind, um in einen Sprint zu passen, bis hin zu riesigen „High Level“ – Epen, die große Funktionen umfassen.,
Schauen Sie sich mein Buch The Epic Guide to Agile, um mehr zu erfahren!
Beginnen Sie mit Epics Vor User Stories
Wenn Sie zum ersten Mal mit der Planung eines agilen Entwicklungsprojekts beginnen, sind alle Ihre User Stories wahrscheinlich in epischer Form. Wenn der Product Owner mit der Priorisierung beginnt, werden die wichtigsten Epen in viel kleinere User Stories unterteilt.
Der Product Owner priorisiert dann diese Storys und die Storys mit der höchsten Priorität gelangen in den nächsten Sprint.,
Einer der Hauptvorteile von Epics besteht darin, dass sie verhindern, dass Ihr Produktrückstand überladen wird. Überlegen Sie, was passieren würde, wenn Sie jede einzelne Ihrer Epen zu Beginn eines Projekts in sprintgroße User Stories zerlegen würden. Erstens wäre Ihr Produktrückstand unglaublich unhandlich, was die Aufgabe Ihres Product Owners, Prioritäten zu setzen, viel schwieriger macht. Zweitens wäre die Zeit, die es dauern würde, all diese User Stories zu schreiben und zu diskutieren, wie… nun, traditionelle Projektentwicklung.,
Indem Sie die meisten Ihrer User Stories in epischer Form aufbewahren, erleichtern Sie dem Product Owner die Verwaltung des Product Backlogs erheblich. Noch wichtiger ist, dass Sie Ihr Entwicklungsteam davon abhalten, seine Zeit damit zu verschwenden, eine große Anzahl von User Stories zu hashen, die möglicherweise überhaupt nicht priorisiert werden. Zu Beginn eines Projekts erstelle ich gerne einen Produkt-Backlog, der idealerweise aus 50 bis 75 Geschichten und nicht mehr als 100 am oberen Ende besteht.,
Wann Sie Ihre Epen aufschlüsseln
Es gibt nur einen geeigneten Zeitpunkt, um ein Epos in sprintgroße User Story-Chunks aufzuteilen: Wenn der Product Owner das Gefühl hat, dass sich ein Epos der Spitze nähert des Rückstands. Auf diese Weise ist die Bewegung eines Epos an die Spitze des Backlogs ein weiterer Unterschied zwischen agilen Epen und User Stories.
Bis das passiert, sind Ihre User Stories besser dran, in epischer Form zu wohnen. Aber sobald ein Epos in den Oberlauf Ihres Produkt-Backlogs klettert, ist es Zeit, es zu brechen.,
Sie müssen jedoch nicht das gesamte Epos in sprintgroße Teile aufteilen. In der Tat, sollten Sie nicht. Einige der user stories innerhalb dieser epischen gehen, um höhere Prioritäten als andere. Und einige der Benutzergeschichten, die Sie in diesem Epos finden, sind viel niedriger als andere Prioritäten auf Ihrer Liste.
Du willst an deinen Epen wegsplittern wie ein Bildhauer am Stein-nicht um etwas Neues zu schaffen, sondern um die wichtigen Teile zu enthüllen, die im Inneren verborgen sind. Wie Michelangelo einmal sagte: „Jeder Steinblock hat eine Statue darin und es ist die Aufgabe des Bildhauers, sie zu entdecken.,“
Auch Ihr Product Owner muss sich also an Ihren Epen orientieren, um die wichtigsten User Stories zu entdecken. Das-und nur diese-sind die User Stories, die konkretisiert, diskutiert und für einen Sprint bereit gemacht werden sollten.
Und nachdem Sie einige User Stories aus einem Epos herausgespielt haben, was passiert mit dem Rest? Nichts passiert damit… es bleibt als Epos im Produkt-Backlog. Nach dem nächsten Sprint kann Ihr Product Owner weitere User Stories daraus erstellen., Oder vielleicht verliert das Epos ohne diese wichtigen Teile an Relevanz und fällt weiter auf die Prioritätenliste.
In jedem Fall wird die Entscheidung, was mit einem Epic zu tun ist, auf der Grundlage der Position dieses Epic innerhalb des Produkt-Backlogs und sonst nichts getroffen.
Epics und User Stories: Ein Tandem Effizienz
So haben Sie es.
Was ist ein Epos? Es ist eine große User Story, die nicht bereit für einen Produktions – Sprint ist – und nicht in ihn passen kann., Sie speichern Epics in Ihrem Produkt-Backlog, weil sie Ihnen einen enormen Effizienzschub geben und Ihr Scrum-Entwicklungsteam von Ablenkungen mit niedrigerer Priorität fernhalten.
Und wenn sich ein Epos ganz oben auf Ihrer Prioritätenliste befindet, müssen Sie nicht das Ganze aufschlüsseln. Sie brechen einfach so viele Benutzergeschichten mit hoher Priorität aus, wie Sie benötigen. Dann priorisiert der Product Owner sowohl die abgeschlossenen User Stories als auch alles, was vom Epic im Produkt-Backlog übrig bleibt.
Auf diese Weise schafft die Kombination von Epen und User Stories ein Effizienztandem für Ihr Scrum-Entwicklungsteam., Während in der Natur ähnlich, Epen und ihre kleineren, Sprint-Größe User Stories dienen zwei deutlich unterschiedliche Zwecke.
Wenn Sie Probleme haben, mit Ihren Produktentwicklungsteams den Geschäftswert schnell zu realisieren, kontaktieren Sie uns noch heute.