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.
In Scrum glaubt man an selbstorganisierte Teams. Daher wird Mikromanagement schnell zu einem großen Problem für Scrum Teams. Mit drei einfachen Fragen kann man diesem Problem entgegentreten.
Die offensichtlichste Aktivität in einem Sprint Review Meeting ist die Demonstration von Funktionalität, die im vorhergehenden Sprint gebaut wurde. Ein gutes Sprint Review ist jedoch mehr als eine reine Demonstration. Schauen wir uns gemeinsam eine Agenda für ein Review Meeting an.
Wenn man in Agile bzw. Scrum einen Sprint oder eine Iteration plant, ist es wichtig, sich zu überlegen, wie groß die einzelnen Tasks sein sollten. Sowohl zu große, als auch zu kleine Tasks bringen Probleme mit sich. Erfahren Sie hier, wie Sie die optimale Größe für Tasks finden.