Nein sagen, kann äußerst schwierig sein. Die meisten von uns wollen andere Menschen zufriedenstellen. Wenn wir aber „Nein” sagen, enttäuschen wir denjenigen, der uns um etwas gebeten hat.
Nein zu sagen, ist jedoch ein wichtiger Teil des Jobs eines jeden Product Owners. Der Product Owner hat die Aufgabe, den Wert eines zu liefernden Produkts zu optimieren, und zwar indem er nicht zu jedem Wunsch eines Kunden Ja sagt.
Ihr agiles Team durchläuft eine Reihe von Sprints mit den vom Product Owner am höchsten priorisierten Items. Nach diesen Sprints schauen Sie sich an, was Ihr Team geschafft hat, und das ist nicht besonders zufriedenstellend. Alles, was das Team scheinbar tat, war einen Notfall nach dem anderen zu beheben. Was ist passiert? Sie sind in die Falle getappt, die Priorisierung anhand dessen vorzunehmen, was am Anfang des Sprints am dringendsten erscheint – eine häufige Nebenwirkung der iterativen und inkrementellen Arbeit in Agile. Aber da gibt es einen besseren Weg.
Schon lange vor Agile war das Fixen von Bugs eine Herausforderung in der Softwareentwicklung. Die kurzen Iterationen in Agile machen es den Teams nicht unbedingt einfacher, zu entscheiden, welche Bugs gefixt werden müssen und welche noch warten können.
Ein wichtiges Prinzip in Agile ist es, Arbeit in Phasen zu vermeiden (Wasserfall). In agilen Projekten gibt es keine Analyse-Phase gefolgt von einer Design-Phase gefolgt von einer Coding-Phase und schließlich einer Test-Phase. Stattdessen bedient man sich der sogenannten simultanen Entwicklung, bei der sich die Arbeiten überschneiden.
Ein häufiges Problem mit User Stories ist das Hinzufügen der richtigen Menge an Details, damit die Story in die nächste Iteration bzw. den nächsten Sprint aufgenommen werden kann.
Das ist ein wichtiger Balanceakt. Nimmt man eine Story in eine Iteration auf, bevor sie wirklich verstanden wurde, wird es zu viele offene Fragen für das Team geben, sodass die Story nicht innerhalb einer Iteration fertiggestellt werden kann. Versucht man jedoch, jede kleine Unklarheit und jede Einzelheit vorab zu klären, braucht die Funktionalität schließlich viel zu lange bis sie in den Händen der Nutzer landet.
User Stories sind zu Anfang oft bewusst noch relativ unkonkret formuliert. Die Teams haben gelernt, dass es wenig Sinn macht, weit im Voraus viele Details zu den Stories hinzuzufügen, wenn an einer Story in den nächsten Iterationen noch nicht gearbeitet werden soll. Jedoch ist es bei jeder Story irgendwann an der Zeit, mehr Einzelheiten hinzuzufügen.