Traditionelle SRS in User Stories umwandeln?

Viele traditionell gemanagte Projekte beginnen mit einer Software Requirements Specification (SRS). Irgendwann im Laufe des Projekts wird dann entschieden, auf einen agilen Ansatz umzusteigen. In diesem Fall kommt natürlich die Frage auf, ob eine SRS als der neue agile Product Backlog dienen kann. Einige Teams ziehen sogar in Erwägung, die SRS in einen Product Backlog mit User Stories umzuschreiben. Aber ist das wirklich nötig?

Bevor wir uns dieser Frage widmen, möchte ich noch kurz erläutern, was genau ich mit Requirements Specification bzw. SRS meine. Ich habe festgestellt, dass sich diese Dokumente in verschiedenen Unternehmen stark unterscheiden können. Grundsätzlich beziehe ich mich jedoch auf ein typisches Dokument, das Aussagen beinhaltet wie „Das System sollte…”.

Mein Rat passt aber im Grunde genommen zu fast allen traditionellen Spezifikationsdokumenten. Das gilt natürlich für jedes Dokument mit integrierten und nummerierten Anforderungen, egal ob alle Statements tatsächlich als „Das System sollte…” formuliert wurden.

Einige Nachteile bei der Verwendung einer SRS als Product Backlog

Bei einem agilen Produkt hat der Product Backlog zwei wichtige Aufgaben:
- Er dient als Archiv für alle Arbeiten, die erledigt werden müssen
- Er erleichtert die Priorisierung der Arbeit

Der Product Backlog sagt einem Team also, welche Arbeiten erledigt werden müssen, und kann außerdem als Planungstool für die Sequenzierung der Arbeit genutzt werden. Im Gegensatz dazu gibt eine traditionelle SRS lediglich an, welche Arbeiten bei einem Projekt erledigt werden müssen.

Eine SRS zielt weder darauf ab, Anforderungen zu schreiben, die in einen Sprint eingebunden werden können, noch darauf, diese zu priorisieren. Unabhängige Anforderungen zu schreiben, ist bestenfalls ein untergeordnetes Ziel, was man gut an der hierarchischen Organisation der meisten SRS-Dokumente mit ihren nummerierten Anforderungen (1.0, 1.1, 1.1.1 usw.) erkennen kann.

Solange eine SRS als reines Anforderungsdokument gesehen wird, bringt das keinerlei Probleme mit sich. Wenn die Items einer SRS jedoch als Product Backlog Items dienen sollen und priorisiert werden, wird das zu Problemen führen.

Mit einer SRS ist es einem Team oft nicht möglich, die Anforderung 1.1.1 zu entwickeln, ohne auch gleichzeitig Anforderung 1.1.2 und 1.1.5 zu entwickeln. Diese Abhängigkeiten machen es einem viel schwerer, als wenn man einfach eine Story nach der anderen von einem gut ausgearbeiteten Product Backlog auswählen und abarbeiten würde.

Die Priorisierung untergeordneter Items ist bei einem SRS ebenso schwierig wie das Identifizieren untergeordneter Features zur Erschaffung eines Minimum Viable Products.

Eine Software Requirements Specification ist gut als Anforderungsspezifikation geeignet. Sie ist gut dafür, darzustellen, was ein System oder Produkt tun soll. (Natürlich geht sie nicht auf all die agilen Aspekte von neu aufkommenden Anforderungen (Emergent Requirements), Zusammenarbeit, Erkenntnissen usw. ein. Ich gehe aber dennoch davon aus, dass diese Dinge vorkommen.)

Meine Empfehlung zu SRS im Sprint

Grundsätzlich würde ich nicht empfehlen, seine Zeit dafür zu opfern, eine einwandfreie SRS umzuschreiben. Natürlich könnte es im Hinblick auf die eben genannten Probleme durchaus hilfreich sein, die SRS in User Stories und einen schönen Product Backlog umzuschreiben, jedoch lohnt sich die Mühe meistens einfach nicht.

Jemand müsste sich Zeit nehmen, um das zu tun, aber derjenige kann diese Zeit im Normalfall wesentlich sinnvoller nutzen. Ich würde besonders davon abraten, eine SRS umzuschreiben, wenn andere Teammitglieder auf den neu geschriebenen Product Backlog warten müssten, um mit ihrer Arbeit beginnen zu können.

Der Scrum Master oder ein anderes Teammitglied muss eine Möglichkeit finden, auch bei einer SRS den Fortschritt messen zu können, und sicherstellen, dass keine Anforderungen darin untergehen. Normalerweise ist es eine gute Idee, die Qualitätssicherung einzubeziehen, um zu gewährleisten, dass alles in der SRS erledigt bzw. im Backlog aufgelistet wurde.

Zusätzlich ist es wichtig, dass man denjenigen, die an der Erstellung der SRS-Dokumente beteiligt sind, vermittelt, dies in zukünftigen Projekten auf eine Art und Weise zu tun, die besser mit Agile kompatibel ist. Wenn Sie das schaffen, können Sie in Ihrem nächsten Projekt die Probleme vermeiden, die durch eine Diskrepanz zwischen Agile und einem traditionellen SRS-Dokument entstehen.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Product Owner Seminar

=> Lerne mehr über die Aufgaben eines Product Owners in unseren zertifizierten Trainings.

Nichtfunktionale Anforderungen

=> Erfahre hier, wie du nichtfunktionale Anforderungen in User Stories überführst.

Commitment orientiertes Sprint Palnning

=> Hier erfährst du, warum ich commitment orientiertes Sprint Planning gegenüber dem velocity orientiertem Sprint Planning bevorzuge.