Die Definition von READY

Gestern habe ich auf der Integrating Agile Konferenz einen Vortrag über die Antworten gehalten, die ich auf das gefunden habe, was ich für das große schwarze Loch von Scrum halte: die Rolle des Product Owner. Aufgrund des Feedbacks möchte ich über dieses Thema bloggen und das Loch ein wenig entschwärzen... :-) Bearbeiten: Der Link zum zweiten Beitrag der Serie ist zu weit unten vergraben, daher füge ich ihn oben ein: Siehe Flow to Ready, Iterate to Done

Die Definition von Bereitschaft

Ich gebe CSM-Schulungen mit Jeff Sutherland, und vor etwa einem halben Jahr hatte er etwas in sein Material aufgenommen, das er "das dynamische Modell von Scrum" nannte. Das wesentliche Merkmal war die Hinzufügung eines READY-Zustands gegenüber dem DONE-Zustand. Die Idee dahinter ist, dass sich ein Team in einer stabilen, bekannten Situation befinden muss, um gute Leistungen erbringen zu können. Das hat mich sofort angesprochen: Ich hatte schon so viele Teams scheitern sehen , weil der Product Owner ihnen kein klares Ziel vorgeben konnte, und der READY-Zustand war genau das Ziel, auf das es hinzuarbeiten galt. Aber was war das eigentlich, und wie kommt man dorthin? Inzwischen glaube ich, dass ich einige gute Antworten auf diese Fragen habe.

Hier ist ein Bild aus meinem Scrum-Kursmaterial, um das Konzept zu veranschaulichen...

Was bewirkt der READY-Status?

In einem sich selbst organisierenden Team ist es sehr wichtig, ein klares Ziel festzulegen: Selbstorganisation gibt es nicht, wenn Sie nichts haben, zu dem Sie sich organisieren können. Der READY-Zustand verhindert, dass sich das Team verzettelt, indem er sicherstellt, dass die Voraussetzungen für eine gute Sprint-Ausführung gegeben sind.

READY definieren

READY wird durch die Definition von READY definiert. Sie ähnelt der Definition von DONE, allerdings mit den folgenden Unterschieden. Während bei der Definition von FERTIG der "Lieferant" das Team und der "Kunde" der Product Owner ist, ist es bei der Definition von BEREIT umgekehrt: Das Team ist der "Kunde" und der Product Owner ist der "Lieferant". Auch wenn ich die Definition von READY später noch genauer erläutern werde, läuft sie letztlich auf eine Aussage hinaus: BEREIT ist, wenn das Team sagt: "Ah, wir haben es verstanden". Auch wenn Sie jede beliebige Vorbedingung in die Definition von BEREIT aufnehmen können, überschattet die Notwendigkeit eines guten Backlogs alle anderen Überlegungen, so dass Sie sich definitiv mit zwei Punkten befassen müssen: Bereitschaft der User Stories und Bereitschaft des Backlogs.

Wann ist eine User Story READY?

Ich habe festgestellt, dass eine User Story fertig ist, wenn Sie drei Fragen beantwortet haben: Warum?, Was? und Wie? beantwortet haben, eine Schätzung vorgenommen wurde und sie klein genug ist.

• Und warum?: Was wollen die Beteiligten erreichen? Was sind ihre Ziele? Was ist der geschäftliche Kontext? Was ist der quantifizierte Wert?
• Was? Was ist die Ergebnisvision? Was ist das Endergebnis der User Story?
• Wie? Was ist die Implementierungsstrategie? Wie hoch sind die damit verbundenen Kosten (Story Points)? Ist die Story klein genug (Story Points vs. Team Velocity)?

Beachten Sie, dass ich mit der Beantwortung dieser Fragen nicht implizieren möchte, dass Sie eine große Menge an Dokumentation oder Artefakten benötigen. Auch hier gilt: Was immer das Team für nötig hält. Wenn die Rückseite einer Serviette ausreicht, dann machen Sie das. Wenn das Team mehr braucht, stellen Sie es zur Verfügung. Beachten Sie, dass der benötigte Detaillierungsgrad für jede User Story festgelegt werden muss. Einige werden ganz normal sein und Sie können sich mit einem einfachen "Ich möchte so etwas, aber diesmal in grün" zufrieden geben. Andere könnten sich zum Beispiel auf einen neuen Prozess auf der Intensivstation eines Krankenhauses beziehen. Da brauchen Sie vielleicht ein bisschen mehr... ;-) Ich verwende den Begriff " Implementierungsstrategie", um den erforderlichen Detaillierungsgrad zu verdeutlichen. Eine vollständige Spezifizierung des Wie? würde Sie zurück zum Wasserfallmodell führen, aber Sie können keine Punktschätzungen vornehmen, wenn das Team keine ungefähre Vorstellung davon hat, wie es die User Story angehen wird. Also gehen Sie bei der Spezifikation der Implementierung so weit, wie es für eine Punktschätzung erforderlich ist. Beachten Sie, dass dies ein natürlicher Nebeneffekt der Planung von Pokersitzungen ist. Am einfachsten ist es also, wenn Sie das Ergebnis dieser Diskussion zusammen mit der Schätzung festhalten. Und ich rate Ihnen wirklich dazu, denn ich habe schon zu viele Fälle erlebt, in denen sich das Team gefragt hat, warum es dieser User Story nur zwei Tage nach der Planungspokersitzung 5 Punkte gegeben hat... :-) Letztendlich ist eine User Story BEREIT, wenn ein Team sie implementieren kann und ein Product Owner sie priorisieren kann.

Wann ist der Backlog BEREIT?

Das Backlog ist BEREIT, wenn etwa 1,5-2 User Stories im Wert eines Sprints an der Spitze des Backlogs BEREIT sind, und diese User Stories sind klein genug, um einen guten Teamfluss zu ermöglichen.

Und schließlich, folgen Sie diesem Mantra

Lassen Sie nichts in Ihren Sprint, was nicht BEREIT ist, und lassen Sie nichts entkommen, was nicht ERFOLGT ist. Okay, jetzt wissen Sie, wie Sie BEREIT definieren. In einem nächsten Beitrag werde ich Ihnen sagen, wie Sie dorthin gelangen...