Best Practices zur Vereinfachung des agilen Anforderungsmanagements - Epics vs. Stories vs. Tasks

Navigation überspringen

Von der Vision über Epics hin zu Stories und Tasks – Agiles Anforderungsmanagement vereinfacht

/ February 26, 2019
epics, stories, tasks blog background image

Eine der Herausforderungen bei der agilen Entwicklung ist die Erfassung von Anforderungen. Idealerweise ist agiles Anforderungsmanagement einfach, weil der Kunde bereits weiß, was er will. Außerdem weiß der Entwickler, wie man es baut und die Anforderungen ändern sich nach Beginn nicht mehr. Aber wie viele Projekte haben Sie durchgeführt, die auf diese ideale Weise vorangekommen sind? Meiner Erfahrung nach lautet die Antwort „null“.

Die Realität ist, dass der Kunde erst im Lauf des Prozesses entdeckt, was er eigentlich will und die Entwickler dann herausfinden müssen, wie es sich umsetzen lässt. Darüber hinaus wird sich auf dem Weg zur fertigen Anwendung vieles ändern. Veränderung ist das Einzige, was im Leben sicher ist. Wir können uns entscheiden, sie zu bekämpfen oder wir können lernen, wie wir sie managen und für uns nutzen können.

Erste Schritte mit agilem Anforderungsmanagement

Um mit der Verwaltung agiler Anforderungen zu beginnen, empfehle ich Ihnen das Webinar von Sr. UX Designer Willem Gorisse über die erfolgreiche Integration von UX in Mendix Projekte als Vorbereitung. In diesem Webinar lernen Sie, wie Sie die Product-Vision-Vorlage verwenden und Nutzer-Personas entwerfen.

Warum sollten Sie mit der Product Vision beginnen? Weil sie den Grund für das zu bauende Produkt aufzeigt. Während Sie die Lösung entwickeln, sollte die Vision die treibende Kraft sein, die alle auf Spur hält, besonders wenn der „Scope Creep“ einsetzt. Der Product Owner sollte die Vision vorantreiben und die Anforderungen der Stakeholder verwalten. Betrachten Sie die Vision als den Grund, WARUM Sie die Lösung entwickeln. Die Epics, Stories und Tasks werden das sein, WAS Sie bauen.

Epics vs. Stories vs. Tasks

Sobald die Vision klar ist, können Sie mit der Erstellung von Epics und der Aufschlüsselung der Anforderungen beginnen. Epics sind umfassende Features und Funktionalitäten, die mehrere Sprints umfassen können. Sie werden in Stories aufgeteilt, die wiederum weiter in Tasks aufgeteilt werden können. Während Epics mehrere Sprints umfassen können, sollten die Stories innerhalb des aktuellen Sprints erledigt werden. 

Stories sollten priorisiert und auf der Grundlage von Stakeholder-Feedback erstellt werden. Der Product Owner sollte bei Bedarf die Prioritäten setzen und das Team anleiten. Bei der Erstellung von Stories sollte immer diese Vorlage verwendet werden: Als <Nutzerrolle> möchte ich <was Sie wollen>, damit ich <Business Value Added>.

Wenn es keinen Geschäftswert für eine Story gibt, warum bauen Sie sie dann? Die Frage nach dem Geschäftswert ist auch ein guter Weg, um den „Scope Creep“ zu managen und zu erkennen, wann Stakeholder viele Items anfordern, ohne klar zu definieren, warum. Jede Story kann mehrere Tasks haben, die die Story weiter aufschlüsseln.

Best Practices zur Verwaltung agiler Anforderungen

Das Tolle an Mendix ist, dass bei agilem Management alles an einem Ort vereint ist. Sie können Sprints erstellen, Stories und Tasks verwalten und verschiedene Labels hinzufügen, um alle erforderlichen Anforderungen zu erfüllen. Dies alles finden Sie im Abschnitt Stories Ihrer App.

Es gibt auch einen agilen Sprint-Planungsabschnitt, in dem Sie den gesamten Release-Plan verwalten können.

sprint planning for agile requirements management

Die Anforderungen sind in eine Entwicklungsumgebung unter der Ansicht Stories integriert. Beachten Sie, dass in der Ansicht Stories nur der aktuelle Sprint angezeigt wird. Der Grund dafür ist, dass die Entwickler engagiert bleiben und am aktuellen Sprint arbeiten sollen.

Wenn ein Entwickler an einer Story arbeitet, kann er sie als Running markieren und als Done, wenn er fertig ist. Sobald er mit der Story fertig ist, sollte er sie an jeden Code Commit anhängen, den er macht.

Sprintr Feedback Screenshot

Fazit

Wenn das Team irgendwelche Hindernisse sieht oder wenn der Scrum Master etwas bemerkt, das einen zukünftigen Roadblock darstellen könnte, sollten sie dies so schnell wie möglich ansprechen. In der agilen Entwicklung bleibt keine Zeit dafür, Dinge unter den Teppich zu kehren. Obwohl Sie nicht alle Probleme berücksichtigen können, ist es wichtig zu wissen, dass jede Änderung an der App während einer Iteration Kosten verursacht.

Je komplexer ein Projekt, desto länger dauert es und desto mehr Probleme entstehen. Bei der Bewältigung komplexer Anforderungen ist es wichtig, dass das Entwicklungsteam (zusammen mit dem Scrum Master und dem Product Owner) die Lösung so gut wie möglich plant und gestaltet. Das bedeutet, dass komplexe Anforderungen in kleinere Stories zerlegt und im Laufe der Zeit wiederholt werden. Das Feedback der Stakeholder ist eines der wichtigsten Bindeglieder zwischen Business- und IT-Abteilung und sollte dementsprechend genutzt werden.

Guide to Digital Execution Free eBook Download

Copy link