Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03375.jsonl.gz/2866

In my current project I had to write a short explanation how our development team could work with epics, stories and task. Sorry, this article is currently just in german. I will translate it as soon as i have more time.
EPIC
Wenn eine Aufgabe, ein Requirement viele offene Fragen hat, wird das Problem in kleinere Probleme aufgeteilt und Stories werden gebildet. Wenn das Requirement klar ist, jedoch nicht in einen Sprint passt, sollte auch hier das Requirement in mehrere Stories aufgeteilt werden. Das Requirement bildet dann das EPIC. Je mehr in einem Epic oder Story gemacht werden muss, desto schwieriger wird es für das development team, den Aufwand zu schätzen und somit wird dann auch die Planung wesentlich schwieriger für den Product Owner oder das Management.
Kleinere Probleme sind leichter zu schätzen als grössere und erleichtern die Planung auf längere Sicht.
Beispiel: Requirement 1: Erstelle 3 GUI’s für Overview, Detail, Login.
Das Epic wäre hier das Requirement 1, die Stories wären dann jeweils:
Story 1: Erstelle Overview GUI
Story 2: Erstelle Detail GUI
Story 3: Erstelle Login GUI
Dies macht aus mehreren Gründen Sinn:
- Man reduziert das Problem in kleinere Probleme was einfacher zu schätzen ist
- Der Task breakdown wird einfacher oder unnötig.
- Das Business erhält mit jeder Story schon einen Value mit dem man etwas anfangen kann.
- Wie in der Softwareentwicklung, sollten wir mit dem Seperation of Concern arbeiten. Jede Story sollte / darf nur ein Problem lösen wollen. Wenn beispielsweise beim Login UI ein Problem auftritt, die anderen zwar abgeschlossen sind, ist die Story nicht DONE!
Story
Eine Story behandelt immer nur ein Problem welches möglichst klein ist. Man sagt sogar, dass eine Story in 4-16 Stunden abgearbeitet werden können muss. Aber auf jeden Fall muss die Story innerhalb eines Sprints gelöst werden können. Das Problem, wenn auch die Stories zu gross sind, wird allenfalls zu wenig gemacht.
Beispiel: Das development team kann z.B. 21 Story points in einem Sprint machen. Wenn dann Story 1 – 3 je 8 Storypoints gross sind, schafft das development team dann aber nur 2 Stories und commited zu diesen. Heisst also, wir vergeuden die Zeit für 5 Storypoints. Wenn wir aber z.B. die Stories in 3 und 5 Points aufteilen (Storypoints folgen der Fibonacci Reihe) dann können wir volle 21 Punkte in einem Sprint erarbeiten.
Natürlich sollte das Team dann selbständig sagen, hey, wir könnten mehr machen, müssen aber die Stories aufteilen, wenn das nicht genügend gemacht worden ist. Man sollte aber immer darauf achten dass die Stories einen Value für das Management zurückgeben.
Es können dann noch Tasks erstellt werden welche nicht grösser als 4h – 8h sein sollten. Jeder Task sollte innerhalb eines Arbeitstages abgearbeitet werden können. Wenn die Story genügend klein ist, braucht man manchmal nicht mal mehr Tasks.
Es gibt auch ein gutes Template wie man Stories beschreibt:
As a <type of user>,
I want <to perform some task>
so that I can <achieve some goal/benefit/value>
Template ausgefüllt könnte so sein:
As a customer,
I want to withdraw cash from an ATM
So that I don’t have to wait in line at the bank.
Der nächste schritt wäre dann noch BDD (Behaviour Driven Development) um die Acceptance Kriterien zu beschreiben, so dass der PO / REQ / Management sieht ob auch alles so läuft wie man will. Zudem kann man das auch als Dokumentation benutzen (Tools in Microsoft und .NET wären wohl SpecFlow: http://www.specflow.org/). Der PO / REQ kann diese dann Prosa mässig erstellen, die Entwickler müssen dann den Code dazu schreiben. Am besten keiner der auch die Story implementiert hat. Unit test müssen aber dennoch gemacht werden und am besten mittels TDD (Test Driven Development).
Acceptance Critteria 1:
Given that the account is creditworthy
And the card is valid
And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned.
Acceptance Critteria 2:
Given that the account is overdrawn
And the card is valid,
When the customer requests the cash
Then ensure the rejection message is displayed
And ensure cash is not dispensed.
Jede Story besitzt auch ein DoD (Defintion of Done). Im normal fall haben alle Stories das gleiche DoD. Hier wird definiert was der PO, REQ oder der Abnehmer alles Erwartet. Beispiele wären:
- Alle Acceptance Criteria lauffähig
- Release Notes nachgeführt
- SAD dokument upToDate mit neuen klassen diagrammen, schnittstellen beschreibungen
- …
Eine Story kann aber auch ein DoR (Definition of Ready) haben. Das sind dann die Anforderung die das Development team an den PO oder den REQ stellt. Fragen die geklärt werden müssen bevor die Story als machbar gilt.
Task
Tasks sollten nicht grösser als 4h – 8h sein. Jeder Task sollte innerhalb eines Arbeitstages abgearbeitet werden können.
Wenn die Story genügend klein ist, braucht man manchmal nicht mal mehr Tasks.
Abschluss
Wenn man sich einwenig an die Best-Practices haltet, kann man die Qualität und die Planung enorm verbessern. Habe auch oft gesehen dass dann auch die Motivation steigt wenn das verständnis höher ist und die defects klein bleiben. Zudem wird auch das Management / der Kunde glücklicher sein wenn er jede Story als Value sieht und gleich seine Meinung und Änderungswünsche anbringen kann. Dies reduziert das Risiko dass am ende etwas geliefert wird, was nicht ganz den Wünschen entsprach. Das feedback zum Kunden ist sehr wichtig dabei.
Dies kann man auch in einem nicht Agilen Umfeld machen. Dafür ist Scrum oder Kanban nicht unbedingt notwendig.