Was ist der Gewichtungsunterschied zwischen Epic/Story/Task

Ich bin etwas verwirrt zwischen den dreien.

Meinem Verständnis nach:

Epic - Create a web site (T shirt size) (L)
Story - Create the Home page (1 point)
Task - Create a button on the home page that is red (1 hour)

Stimmt das und die Gewichtung?

Was Sie in der Frage erwähnt haben, ist ungefähr richtig. Mögliches Duplikat: Was sind Definitionen und Unterschiede zwischen: Theme vs. Epic vs. Feature vs. User Story vs. Task
Sollte ich also User Stories oder Tasks als Teil der Planung in einen Sprint packen? Wenn die User Story „Homepage erstellen“ lautet und die Homepage 50 Aufgaben hat, ist das dann eine sehr ineffiziente Vorgehensweise?

Antworten (7)

In Scrum ist hier die grobe Aufschlüsselung:

Epic - etwas so Großes, dass es wahrscheinlich nicht in einen Sprint passt, nicht klar in Bezug auf die Kundenanforderungen verstanden wird und in Stories heruntergebrochen werden sollte. Die Größenbestimmung von T-Shirts ist eine gängige Methode zur Größenbestimmung von Epics. Eine andere Möglichkeit ist zu sagen, dass wir denken, dass es X bis Y Iterationen dauern könnte, um diese Arbeit zu erledigen. Epics werden normalerweise während der anfänglichen Produkt-Roadmapping definiert und im Product Backlog in Stories zerlegt, wenn mehr gelernt wird.

Story – etwas Umsetzbares und klein genug, um in einen Sprint zu passen. Diese sind handlungsorientiert und anhand von INVEST-Kriterien definiert. Storys sollten dem Kunden ein vertikales Stück Funktionalität liefern, das am Ende einer Iteration wertvoll und vollständig ist. Storys werden normalerweise während der gesamten Produktentwicklung erstellt, insbesondere im Vorfeld der Iterationsplanung und auch während der Produkt-Roadmapping auf höherer Ebene.

Aufgaben - zerlegte Teile einer Geschichte, die darauf eingehen, WIE die Geschichte abgeschlossen wird. Aufgaben können auf Wunsch stundenweise geschätzt werden. Aufgaben werden normalerweise von den Personen definiert, die die Arbeit erledigen (Entwickler, QA usw.), während Stories und Epics im Allgemeinen vom Kunden oder dem Product Owner, der den Kunden vertritt, erstellt werden. Aufgaben werden im Rahmen einer Iteration erstellt, da sie kurzlebig sind. Es hat sehr wenig Wert, Geschichten herauszugeben, an denen in der kommenden Iteration nicht gearbeitet wird.

Epos

Ein Epos ist wie eine Supergeschichte. Wenn eine Geschichte zu groß ist, um bequem in einen Sprint zu passen, und/oder viele Unbekannte enthält, ist sie normalerweise besser als Epos geeignet. Epics eignen sich gut für das Product Backlog, aber wenn sie sich der Spitze des Backlogs nähern, werden sie normalerweise in mehrere Storys zerlegt. Wir bringen keine Epics in Sprints.

Geschichte

Eine Story ist eine funktionale Anforderung, die einen gewissen Geschäftswert bietet. Es muss auch klein genug sein, um bequem in einen Sprint zu passen.

Geschichten werden in einer Sprache geschrieben, die für den Product Owner und Geschäftsanwender leicht verständlich ist. Auf diese Weise können sie den Fortschritt nachvollziehen, der durch das Vervollständigen der Geschichte erzielt wurde.

Das Format einer Geschichte ist:

Als [Rolle] möchte ich [etwas], damit [Wert]

Aufgabe

Wenn ein Entwicklungsteam an einer Story arbeitet, fällt es ihnen oft leichter, sie in Aufgaben aufzuteilen. Die Aufgaben müssen für Fachanwender nicht mehr verständlich sein und können daher sehr technisch sein. Der Prozess, eine Story in Aufgaben aufzuteilen, hilft dem Entwicklungsteam auch, besser zu verstehen, was zu tun ist.

Es ist wichtig, sich daran zu erinnern, dass sich die Aufgaben auf das Entwicklungsteam und die Storys auf den Product Owner und die Geschäftsanwender konzentrieren. Wenn ein Entwicklungsteam eine Aufgabe erledigt, hilft es ihm zu verstehen, wie es in einem Sprint vorankommt. Aber es ist die Fertigstellung von Geschichten, die für den Product Owner wichtig ist, da er versteht, was die Geschichte bedeutet.

Beispiel

Ein Product Owner legt ein Epic ins Backlog, in dem es heißt: „Einfache Website für die Personalabteilung“.

Wenn es sich der Spitze des Rückstands nähert, wird es in Geschichten unterteilt, die Folgendes beinhalten:

Als Mitarbeiter möchte ich die neuesten Nachrichten aus der Personalabteilung sehen, um auf dem Laufenden zu bleiben.

Als Mitarbeiter möchte ich die Kontaktnamen aller Personen in der Personalabteilung wissen, damit ich weiß, an wen ich mich wenden kann, wenn ich eine Frage habe.

Als Mitarbeiter möchte ich Zugang zu HR-Richtliniendokumenten haben, damit ich sicher sein kann, dass ich mich an die Richtlinien halte.

Der Product Owner führt diese Geschichten mit dem Team durch und beschreibt, wie sie diese Informationen sehen, die auf der Homepage der Website angezeigt werden.

Das Team nimmt die erste Geschichte und unterteilt sie in Aufgaben:

Erstellen Sie ein grundlegendes Homepage-Layout

Erstellen Sie ein CSS, das dem Styleguide des Unternehmens folgt

Führen Sie die Aktualisierung der Nachrichtenliste aus einer Datei durch, die vom HR-Team bearbeitet werden kann

usw.

Sollte eine Karte in meinem Projektplanungstool (ich verwende Trello) eine Geschichte oder eine Aufgabe sein? Derzeit erledige ich Aufgaben, da es für das Entwicklerteam einfacher zu verstehen ist. Geschichten sind auch viel mehrdeutiger (Erstellen einer Homepage) und erfordern viele Aufgaben, die erledigt werden müssen
Die einfache Antwort ist, das zu tun, was für Ihr Team am besten funktioniert. Eine Sache, die ich gesehen habe, ist, die Geschichten sehr klein zu machen, und sie werden für die Entwickler viel einfacher zu bearbeiten und können die Notwendigkeit von Aufgaben beseitigen. Beispielsweise könnte die Homepage-Story in mehrere kleinere Storys unterteilt werden.
Dann wird es keine Geschichte mehr, sondern eine Aufgabe?
Könnten Sie mir ein kurzes Beispiel für eine aufgeschlüsselte Geschichte mit Home zeigen? Danke
Ich habe die Antwort mit einem Beispiel aktualisiert.
Danke, statt User Stories, wäre es nicht viel einfacher, wenn ich nur Aufgaben erstelle. Zum Beispiel habe ich einen Designer geleitet, die Trello-Karten waren , erstellte Assets, erstellte Mockups, erstellte ein Moodboard, das Aufgaben innerhalb der Aufgabe hatte. Ich könnte eine User Story schreiben und sagen: „Als Projektmanager brauche ich meinen Designer, um Mockups zu erstellen, damit ich dem Kunden zeigen kann, wie die Website vor der Implementierung aussehen wird“. Aber das ist ein sehr umständlicher Weg.
Wir versuchen, die Geschichten immer auf Endbenutzer auszurichten. „Als Projektmanager …“ ist keine User Story. Es ist nur eine Aufgabe, die im User-Story-Format geschrieben ist. Verwenden Sie, wie bereits erwähnt, Aufgaben, wenn dies für Ihr Team besser funktioniert. Aber versteht Ihr Product Owner die Aufgaben und kann er daraus den Fortschritt abschätzen?
@bobo2000 Ich weiß, dass dies eine alte Frage ist, aber wenn Sie immer noch Trello verwenden, würde ich empfehlen, Karten für Geschichten und Checklisten auf der Karte für die Aufgaben zu verwenden. Die Aufgaben können mehrere Personen umfassen, aber der Wert (Karte/Geschichte) kann nicht geliefert und als „erledigt“ bezeichnet werden, bis alle diese Aufgaben erledigt sind. Indem Sie die Aufgaben auf eine Karte schreiben, können Sie sicherstellen, dass sich das Team darauf konzentriert, den Wert zu liefern, anstatt nur seine individuellen Aufgaben zu erfüllen.

Im Allgemeinen gibt es keine Regeln, sondern das, was Sie machen. Ihr Product Owner würde definieren, was dies für ihn bedeutet, dann dokumentieren und teilen.

Wenn Sie sich einige der verfügbaren Skalierungsframeworks ansehen, gibt es eine allgemein akzeptierte Hierarchie:

  • Bei einer Aufgabe geht es um das Wie, und niemand außer dem Team sollte sich darum kümmern
  • Eine Story ist etwas , das in einen einzigen Sprint passen kann
  • Ein Feature ist etwas , das nicht in einen Sprint passt, aber in ein Release passt
  • Ein Epos ist etwas , das über Veröffentlichungen hinausgeht
  • Ein Thema ist ein Querschnittsthema , das nicht in eine Was-Hierarchie passt

Während das Scrum-Team sich wünschen kann, was das alles bedeutet, muss eine Einigung zwischen dem Scrum-Team und den Stakeholdern erzielt werden, damit alle verstehen.

Der erste, der das Scrum- Framework nicht ignoriert .

1]

Epics – Große Projekte, an denen viele Menschen über einen langen Zeitraum beteiligt sind.

Stories – Kleinere Projekte innerhalb eines Epic, die abgeschlossen werden müssen, bevor das Epic als „fertig“ betrachtet werden kann.

Aufgaben – Die alltäglichen Dinge, die Sie tun müssen, um eine Story abzuschließen. Aufgaben sind einzelne Aufgaben, die mit relativ wenig Aufwand erledigt werden können, wie zum Beispiel telefonieren, eine E-Mail schreiben oder ein Meeting abhalten.

https://leankit.com/blog/2013/12/breaking-work-epics-stories-tasks/

Warum sind sie alle Elefanten?? 😂 Wie sollten Aufgaben nicht Ameisen oder so sein.

Eine abgekürzte Antwort:

Epic : Dauert im Allgemeinen mehr als eine Iteration, enthält mehr als eine User Story und ist in einem User Story -Format geschrieben.

User Story : Wird im Allgemeinen in einer Iteration abgeschlossen, enthält mehrere Aufgaben und ist in einem User Story -Format geschrieben.

Aufgabe : Im Allgemeinen eine Arbeitsaufgabe/Aktion, die zum Abschließen einer User Story erforderlich ist, die vom Dev-Team erstellt wurde und zwischen einigen Minuten und einigen Tagen dauert, bis sie abgeschlossen ist. Erscheint in einer Checkliste.

User-Story-Format: Das Formular, das der Product Owner und das Dev-Team gemeinsam verwenden, um zu definieren/zu verstehen, was getan werden muss. Es umfasst in der Regel mindestens:

  • Zusammenfassung: „Als __ will ich (oder a) __, damit ich __ kann.“
  • Erfüllt INVEST-Kriterien: ( Unabhängig , Verhandelbar, Wertvoll , Schätzbar , Klein , Testbar )
  • Akzeptanzkriterien: Eine bis wenige boolesche Bedingungen

Es gibt eine Menge Ressourcen, um dieses Gespräch zu fördern. Wählen Sie eine aus, um den Prozess Ihres Teams zu starten. Nach einer Weile überprüfen und bei Bedarf anpassen.

In deinem Kommentar fragst du nach der Planung und wie sie mit Epics, User Stories und Tasks zusammenhängt.

Wie @WBW betonte, ist ein Epos etwas sehr Hohes, wahrscheinlich mehrere Sprints lang. Zum Beispiel ein Zahlungsmodul für Ihre Webanwendung.

Eine User Story ist konkreter, passt in einen Sprint, ist mit anderen Sprints verbunden, wenn sie unter dem gleichen Epic stehen. Eine User Story kann auch alleine stehen. Zum Beispiel die Paypal-Integration für das zuvor erwähnte Zahlungsmodul.

Eine Aufgabe ist sehr konkret, kann in 1-2 Tagen erledigt werden und gehört immer zu einer User Story. Zum Beispiel das Hinzufügen der Paypal-Schaltfläche zu Ihrer Webseite.

Normalerweise besteht ein Planungsmeeting aus zwei Teilen: Sprint Commitment und Task Breakdown. Im Sprint Commitment-Teil wählst du das nächste Epic aus und wählst die verbleibenden wichtigsten User Stories aus und bereitest das Sprint Back Log vor. Wenn Sie nicht mit Epics arbeiten, wählen Sie einfach die User Storys aus.

Im nächsten Abschnitt unterteilen Sie die User Storys in Aufgaben. Während des Sprints wählen Sie die Aufgaben aus, nicht die User Stories. Eine User Story ist abgeschlossen, wenn alle damit verbundenen Aufgaben abgeschlossen sind. Falls Sie bei der Planung etwas vergessen haben, können Sie ungeplante Aufgaben hinzufügen.

Zusamenfassend

Episch - Ist einfach eine Geschichte, wird aber als so umfangreich angesehen, dass sie in mehrere Geschichten aufgeteilt werden muss.

Story – Ist im Wesentlichen eine Anforderung, die so detailliert ist, dass sie geschätzt werden kann.

Aufgabe – Entwickler und Tester können die Geschichte weiter in Aufgaben unterteilen, damit sie sie einschätzen, entwickeln und testen können. (Wenn eine Geschichte viele Aufgaben hat, könnte es sich lohnen, sie als Epos zu klassifizieren und in mehrere Geschichten aufzuteilen.)

Was ist der Gewichtungsunterschied zwischen Epic/Story/Task
AntwortenHierDatenschutz-Bestimmungen1y, 0v