Im agilen Projektmanagement hört man oft die Begriffe Epic, Features, User Stories und Task. Wenn Sie den Scrum Guide lesen, werden Sie keinen dieser Begriffe darin finden. Wie kann das sein und was ist der Unterschied zwischen diesen Begriffen? Wenn Sie den Unterschied verstehen und Ihren Blickwinkel erweitern möchten, dann lesen Sie weiter und erfahren Sie mehr!
Was der Scrum Guide definiert
Ich sage es gleich zu Beginn: Der Scrum Guide definiert die Begriffe Epic, Features, User Stories und Task nicht. Auch den Begriff Anforderung (Requirements) werden Sie im Scrum Guide nicht finden. Überrascht? Ich war überrascht, als ich den aktuellen Scrum Guide gelesen habe. Der Scrum Guide erhebt den Anspruch, auf alle Arten von Projekten anwendbar zu sein, nicht nur auf IT-Projekte, und vermeidet daher bewusst Begriffe, die nur in bestimmten Bereichen oder Branchen vorkommen, wie etwa Features in der Softwareentwicklung. Scrum verwendet nur die neutralen Begriffe “Work” und “Backlog Items”. Ganz einfach!
Das ist das Schöne an Scrum. Der Scrum Guide behauptet auch: “Scrum ist einfach. Probieren Sie es so aus, wie es ist, und stellen Sie fest, ob seine Philosophie, Theorie und Struktur dazu beitragen, Ihre Ziele zu erreichen und Werte zu schaffen.” Scrum ist auch in einer skalierten Version als Scrum@Scale relativ einfach. Scrum skalieren ist notwendig, sobald Sie mit mehreren Teams an grossen Projekten arbeiten oder wenn in einem grösseren Unternehmen sinnvollerweise die ganze Softwareentwicklung agil arbeitet.
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve your goals and create value.
The Scrum Guide
Ergänzende Praktiken zu Scrum
Kehren wir zurück zu Epic Features, User Stories und Task. In Scrum verwenden Sie normalerweise “Epic” und “Theme” anstelle von “Feature”. Ein “Theme” ist eine Sammlung von thematisch zusammenhängenden User Stories. Wenn eine von Ihnen geschätzte User Story nicht in einem einzigen Sprint abgeschlossen werden kann, sollten Sie sie stattdessen als “Epic” bezeichnen. Das heißt, Sie sollten die Epic in kleinere User Stories aufteilen. Ein Theme kann in zwei oder mehr Sprints bearbeitet werden. Sie müssen also Prioritäten setzen und User Stories für einen Sprint auswählen, solange Sie am Ende des Sprints ein potenziell nutzbares Produktinkrement haben.
Konzepte wie Epic, Feature, Theme, User Stories, Tasks, etc. sind nicht Teil des Scrum-Frameworks, sondern “ergänzende Praktiken”. Das heißt, Sie können diese verwenden, wie Sie es für richtig halten. Letztendlich sind sie alle Product Backlog Items, so dass nur die Regeln des Scrum Frameworks für Product Backlog Items für sie gelten.
Das Product Backlog listet alle Features, Functions, Requirements, Enhancements und Fixes auf. Die meisten von ihnen können in User Stories zerlegt werden. Der Name, den Sie ihnen geben, ist nicht so wichtig. Es ist nur wichtig, dass Ihre Governance die zu verwendenden Begriffe festlegt, und dass jeder im Projekt weiß, was diese bedeuten. Entscheidend ist, dass Sie die Elemente des Product Backlogs so zerlegen, dass sie klein genug sind, um in einem Sprint gemäß der Definition of Done und den festgelegten Abnahmekriterien geliefert zu werden.
The Product Backlog is an emergent, ordered listof what is neededto improve the product. It is the single source ofworkundertaken by the Scrum Team.
The Scrum Guide
Kehren wir zum Feature zurück. Ein Feature ist definiert als ein Service oder eine Funktion des Produkts, die einen Geschäftswert (Business Value) liefert und die Bedürfnisse des Kunden erfüllt. Jedes Feature wird in mehrere User Stories aufgeteilt, da es meist zu groß ist, um direkt bearbeitet zu werden. Ein Feature wird normalerweise innerhalb einer Iteration (Sprint) geliefert. Wenn ein Feature nicht in einer einzigen Iteration fertiggestellt werden kann, sollte es in kleinere Features aufgeteilt werden.
Um Sie noch mehr zu verwirren, werde ich Ihnen den Begriff Capabilities vorstellen. Nach SAFe verhalten sich Capabilities genauso wie Features. Sie befinden sich jedoch auf einer höheren Abstraktionsebene und unterstützen die Definition und Entwicklung von großen Lösungen. Sie haben eine bestimmte Größe und werden in mehrere Features aufgeteilt, um ihre Implementierung in einer einzigen Version zu erleichtern.
Im allgemeinen Verständnis, und wenn man es ganz einfach haben will, dann werden Epics als rohe Stories gesehen, die heruntergebrochen werden müssen mit mehr Wissen für das, was nutzbar und schnell überprüfbar ist.
Was ich bisher noch nicht erklärt habe, sind die nichtfunktionalen Anforderungen (Nonfunctional Requirements NFR). Die NFRs definieren Systemattribute wie Sicherheit, Zuverlässigkeit, Leistung, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Sie dienen als Rahmenbedingungen oder Restriktionen für den Entwurf des Systems über das gesamte Backlog hinweg.
Von Features zu User Stories
Am Ende dieses Artikels gebe ich Ihnen ein einfaches Beispiel für Features und wie man diese in User Stories aufteilt. Hier möchte ich eine Website erstellen, die Bücher verkauft. Die Features könnten sein:
- Anzeige eines informativen Startbildschirms
- Benutzer-Registrierung
- Benutzer-Login
- Produkte anzeigen
- Einkaufswagen anzeigen
- Produkte zum Einkaufswagen hinzufügen
Daraus würden dann User Stories entwickelt werden:
Informativen Startbildschirm anzeigen:
- Als Benutzer möchte ich auf den Startbildschirm zugreifen können, damit ich die Website betreten kann.
- Als Benutzer möchte ich in der Lage sein, Sonderangebote zu sehen, so dass ich die aktuellen Angebote sehen kann
Benutzer-Registrierung:
- Als Benutzer muss ich mich als neuer Benutzer registrieren können, damit ich mehr Zugang zur Website habe.
- Als Nutzer möchte ich mich mit meinem Google-Konto anmelden können.
Mein Tipp für Sie: Halten Sie das herunterbrechen der Arbeit, die Hierarchie und die Granularität in der agilen Produktentwicklung so einfach wie möglich und sorgen Sie dafür, dass in Ihrer Organisation immer die gleichen Begriffe verwendet werden und jeder weiß, was sie bedeuten.
Hier gibt es noch mehr Wissen
Möchten Sie mehr erfahren, wie Sie mit agilem Projektmanagement und Scrum Ihre Projekte noch erfolgreicher machen?Mein Buch Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Artikel auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!
