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.

2 Gedanken zu „In gemeinsames Verständnis von Anforderungen INVESTieren

  • 25. Februar 2018 um 22:08
    Permalink

    Das Denken in Aufwänden ist in Scrum eigentlich nicht „gewünscht“, schätzen wir Dich die Komplexität.

    Bei der Definition der INVEST Kriterien wird geschrieben der Aufwand einer User Story darf nicht mehr als die Hälfte des Sprints in Ansprich nehmen was bei einem 2W Sprint 1 W arbeitet bedeutet. Genau hier fängt es an spannend zu werden!!

    Hier habe ich Sie nun – die Zeitangabe die ich nicht mehr aus den Köpfen herausbekomme und selbst wenn – an diesem Punkt, hab ich ja nun vor Augen.

    Darüber hinaus wird es immer aufwendig wenn man Kunden Story Points verkaufen will – bzw. sich nicht auf auf den Featureumfang festlegen lassen will…

    Ich halte das Arbeiten mit Story Points für sehr sinnvoll, ABER muss auch konstatieren das es nicht überall OHNE Bauchschmerzen von statten geht und es wäre ein Artikel wert welche Erfolgsfaktoren es gibt für das Arbeiten mit Story Points!

    Antwort
    • 28. Februar 2018 um 21:45
      Permalink

      Hi,

      sorry, dass ich erst so spät auf deinen Kommentar antworte.

      Die Sache mit dem „Denken in Aufwänden“ ist eigentlich weniger, ob das gewünscht ist oder nicht, sondern welche Nachteile damit verbunden sind und ob die tragbar sind. Richtig ist auf jeden Fall: es *gibt* Nachteile (etwa dass sich Arbeiten gerne mal auf den geschätzten Zeitraum ausdehnen) aber eben auch den Vorteil, dass Zeitschätzungen leichter an Kunden zu verkaufen sind.

      So oder so hast du Recht: Wenn Methode auf Realität trifft, dann ist auf jeden Fall hin und wieder Anpassung erforderlich. 🙂

      Bezüglich der Größe von Aufgaben: ich habe hier unglücklicherweise Aufwand geschrieben, aber sinnvollerweise sollte man wohl von Schätzgröße sprechen. Im Großen und Ganzen geht es ja darum, dass man versucht, sich nicht zu übernehmen: Wenn man seine Velocity tracked (siehe auch http://chaosverbesserer.de/blog/2017/04/11/story-points-oder-auch-schaetzen-wie-man-bier-bestellt/), könnte man zumindest theoretisch auch bei der Planung des Sprints auf Zeitumrechnungen verzichten, weil die maximale Größe dann eben Velocity / 2 ist.

      Aber das ist natürlich ein Taschenspielertrick, der nur dann funktioniert, wenn man auch wirklich in relativen Größen schätzt und sich nicht schon vorab betuppt. Leider wird der Story Point in der Praxis gerne mal mit „grob ein Tag“ (oder vergleichbar) gleichgesetzt … und dann kann man das mit den Storypoints eigentlich auch gleich ganz sein lassen.

      Aber ich schätze, es sollten einfach mehr Leute das Buch „Agile Estimating and planning“ lesen (Affliate-Link http://amzn.to/2FDR5yL) …

      Antwort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.