„Das stand nicht in den Akzeptanzkriterien, das musste ich nicht machen.“ „Es stand doch in den Akzeptanzkriterien, dass der Styleguide gilt. Und der sagt ganz klar auf Seite 12, dass Buttons linksbündig floaten müssen.“ „So kann ich nicht anfangen, da fehlen ja noch alle Details.“ „Da versucht das Product Management uns mal wieder zu erklären, wie Technik geht.“
Akzeptanzkriterien und andere Details
Wir alle kennen die Schmerzen, wenn es um die Formulierung von User-Storys geht. Je nach Unternehmen, Abteilung und Person ist alles möglich: Zwischen Akzeptanzkriterien, die aus einem einzigen Wort bestehen, und seitenlangen Dokumenten mit hunderten Querverweisen, von denen ohnehin niemand davon ausgeht, dass sie wirklich gelesen oder geprüft werden können, ist alles denkbar.
Es gibt einen Grund, warum wir heute User-Storys und nicht Use Cases verwenden, warum wir den Nutzer und seine Absicht explizit machen und warum wir die User-Story nicht als Vertrag, sondern als „Promise of Conversation“ bezeichnen.
Agile Missverständnisse
Agile Methoden haben eine klare Intention: Sie wollen die Wertschöpfung bei der Entstehung von Software steigern. Sie bieten zu diesem Zweck gleich einen ganzen Stapel von Werten, Prinzipien und Methoden an, die dabei unterstützen.
In der Praxis sind die Intentionen hinter diesen Werkzeugen oft nicht mehr so klar, und manchmal gehen sie ganz verloren; die Methode bleibt, mit ihren Umständlichkeiten und Haken, nur ohne den erwünschten Effekt. Über diese Art von agilen Missverständnissen will ich hier berichten – und wie man mit ihnen umgeht.
Freiheitsgrade erzeugen
Auf diese Weise wollen wir Freiheitsgrade erzeugen: Was tue ich, wenn ich mit einer kleinen Abweichung eine fertige Komponente für meine Story benutzen kann und mir dabei Tage Arbeit sparen kann? Was mache ich, wenn ich ohnehin schon weiß, dass die Nutzer ein bestimmtes Feature so nicht nutzen werden? Was, wenn ich einen schöneren, eleganteren Weg finde, um das gleiche Nutzerziel besser zu bedienen?
Dann sollte ich das Bessere auch dann tun, wenn die User-Story etwas anderes vorschlägt oder naheliegt. Kann ich das ohne Abstimmung machen? Klar, wenn es ohnehin nicht wahrscheinlich ist, dass ich etwas übersehe. Natürlich nicht, wenn ich die Kundendomäne und die Nutzerwelt zu wenig kenne.
Vorschlag Akzeptanzkriterium
Akzeptanzkriterien sind, wenn sie nicht gesetzliche oder vertragliche Auflagen darstellen, als Vorschlag zu betrachten. Und als Aufforderung, eine bessere Lösung zu finden, die Zeit spart oder den Kundennutzen erhöht.
Damit ich alles im Auge behalte, diskutiere ich jede Änderung mit dem Product Owner. Denn deshalb gibt es ihn – und deshalb steht er im Gegensatz zum echten Stakeholder zu meiner Verfügung.
— Agile Anti-Pattern —
Diese und andere Anti-Pattern findest Du auf unseren Anti-Pattern Cards, die Du kostenlos bei uns bestellen kannst. Übrigens: Zu den Anti-Pattern gibt es auch eine PO-Edition!
Unsere Serie Agile Missverständnisse
Schreibe einen Kommentar