In gemeinsames Verständnis von Anforderungen INVESTieren

Wie setzen wir die Anforderungen von Kunden richtig um?

Ob wir die Anforderungen unserer Kunden erfüllen, entscheidet sich nicht erst in der Umsetzung, nicht beim Design-Meeting mit dem Team, nicht im ersten Review und schon gar nicht in der QA-Phase.

Sondern viel früher.

Entscheidend ist nämlich, wie gut wir die Anforderung des Kunden verstehen.

Wir Agilisten gehen dabei davon aus, dass ein genaues Verständnis vom geforderten Endergebnis erst im Projektverlauf entsteht und sich dabei so manche Anforderung erst auf dem Weg ergibt. Umso wichtiger ist es, dass wir uns einer Vorgehensweise bedienen, in der wir mit den bestverstandenen Anforderungen starten und dann Zug um Zug (oder Sprint für Sprint) die weiteren Anforderungen aufdecken und unserer Verständnis davon verfeinern.

Der erste Schritt zum Verständnis der Anforderungen ist deren Erfassung: so könnten wir eine Reihe von User Stories gesammelt haben und in Kommunikation mit dem Kunden sowie in Refinement-Meetings verfeinert haben.

Doch wann ist ein Item in einem Pool an Aufgaben wie dem Product Backlog eigentlich reif für die Arbeitung?

Wann kann mit der Abarbeitung von Items begonnen werden?

Die INVEST-Eselsbrücke hilft für eine Einschätzung, ob ein Backlog-Item bearbeitet werden kann oder nicht:

• Independent: Eine User Story – oder allgemeiner: ein Backlog-Item -sollte so beschaffen sein, dass es möglich unabhängig von anderen Items umsetzbar ist. Natürlich gibt es immer zu berücksichtigende Abhängigkeiten, aber diese sollten möglichst durch die Reihenfolge der Abarbeitung berücksichtigt werden können.

• Negotiable: Solange eine User Story nicht bearbeitet wird, muss sie jeder Zeit angepasst, umgeschrieben, verfeinert und sogar verworfen werden können – abhängig von Business- und Marktanforderungen sowie technischen und allen sonstigen Anforderungen.

• Valuable: Die Umsetzung eines Backlog-Items sollte Wert für die späteren Anwender schaffen, sich also am Bedürfnis der Zielgruppe orientieren. Etwas nur deshalb zu tun, weil die Umsetzung spannend ist, aber nicht zum eigentlichen Ziel beiträgt, steht im Widerspruch zum agilen Prinzip der kontinuerlichen Auslieferung.

• Estimable: Wenn ein Item nicht quantifizierbar ist, kann es nicht eingeplant werden und somit letztlich niemals bearbeitet werden – schon gar nicht in einer Iteration. Darum sollte das Ziel darin bestehen, die Items in eine Form zu bekommen in der eine Aufwandsschätzung möglich ist, indem fehlende Informationen ergänzt werden. Auch weil sich daran letztlich ablesen lesen, wie gut das Team die Anforderung verstanden hat.

• Small beziehungsweise sized appropriately: Damit ein Item bearbeitet werden kann, muss es in einem planbaren Zeitrahmen bearbeitet werden können. Eine Faustregel ist, dass der Aufwand nicht mehr als 50% einer Iteration betragen sollte. Ansonsten haben wir das, was man ein Epic nennt, und sollten dieses in kleinere Items aufteilen.

• Testable: Letztlich muss die Anforderung überprüf- beziehungsweise testbar sein. Hier kommt die Definition of Done ins Spiel, die als Leitfaden dient, wann eine Aufgabe als erledigt betracht werden kann.

Refine, refine, refine und erst dann loslaufen

Wenn ein Backlog-Item oder eine User Story eines der obigen Kriterien nicht erfüllt, ist es nicht automatisch schlecht. In dieser Form kann es allerdings nicht in die nächste Iteration aufgenommen werden.

User Stories sollten solange einem Refinement unterzogen werden, bis die oben genannten Kriterierien erfüllt sind, und erst dann in eine Iteration aufgenommen werden.

Kurz gesagt: Erst verfeinern, dann loslaufen.

Weitere Informationen zu dem Thema finden sich im Originalartikel von Bill Wake, dem Erfinder dieser hilfreichen Eselsbrücke. Bill Walke hat sich vor allem der agilen Softwarentwicklung mit Xtreme Programming verschrieben und ist Autor einiger Büchern zur Methode aber auch zu Refactoring-Techniken ist.