Wofür nutzen wir das Sprint Planning 2? Für das Schreiben von Aufgaben zu den User Stories. Ähm, ja und noch wichtiger: Nein! Sicherlich formulieren wir auch die initialen Aufgaben für das Team zum Start des Sprints – es soll ja jeder starten können, ohne auf die anderen warten zu müssen. Allerdings ist das einzige nicht das wichtigste Ziel.

Was wollen wir mit dem Sprint Planning 2 erreichen?

Über allen Dingen, die wir im Sprint Planning 2 machen, steht das Abstimmen der Zusammenarbeit. Die Frage: “Wie machen wir es?” Um eine Antwort zu finden, benötigen wir ein gemeinsames Bild von den Geschichten, die wir bearbeiten möchten. Als Vorbedingung ist hier wichtig, dass wir das “Was” im Sprint Planning 1 bereits geklärt haben und nun an der Umsetzung des Bilds im “Wie machen wir es?” arbeiten können. Die Betonung liegt auf dem “Wie”.

Das “Wie” klären wir am besten, indem wir uns eine Arbeits- bzw. Diskussionsgrundlage schaffen: Ein Modell. In der Software-Entwicklung arbeiten wir hier mit Diagrammen, meist UML. Mit Modellen können wir unsere Ideen testen und stellen sicher, dass wir von der gleichen Sache reden, dass wir das gleiche Bild in unseren Köpfen haben. Wir schaffen mit Modellen einen gewissen Abstand, machen sichtbar und greifbar, was sonst nur in Köpfen und Worten steckt. Das wiederum ermöglicht es uns, unsere Schnittstellen abzustimmen, damit ermöglichen wir Zusammenarbeit. Kennen und vereinbaren wir unsere Schnittstellen, so können wir losgelöst voneinander einzelne Aufgaben lösen. Zudem befassen wir uns mit den unterschiedlichen Seiten der Schnittstellen und erfassen damit das Bild im Größeren. Haben wir nun ein gemeinsames Bild, so nehmen wir die Aufgaben zu jeder User Story auf, die wir initial erkennen. Auch das ist wichtig, unser Fundament muss das gemeinsame Verständnis sein.

Diagramme und Skizzen

“Diagrams capture the knowledge that all Team Developers must keep in their head in order to work efficiently.” (Robert C. Martin)

Der wahre Wert von Diagrammen liegt in der Kommunikation von Ideen anhand von einfachen Skizzen. Mit möglichst wenig Details Ideen auszutauschen und zu testen. Ein guter Weg, um eine User Story in Diagrammen abzubilden, ist der Weg über ein Verhaltensdiagramm (z. B. ein Sequenzdiagramm oder Aktivitätsdiagramm) hin zu einem Strukturdiagramm (z. B. ein Klassendiagramm oder ein Komponentendiagramm) und dann das sukzessive Verfeinern im gegenseitigen Wechsel in kleinen Zyklen (siehe Robert C. Martin in “Agile Principles, Patterns and Practices“).

Wann wird am besten ein Diagramm verwendet?

  1. Immer dann, wenn ein gemeinsames Bild notwendig ist.
  2. Immer bei wichtigen Punkten/Diskussionen.
  3. Immer dann, wenn etwas nicht klar oder strittig ist.
  4. Immer dann, wenn gleichzeitig an etwas gearbeitet werden soll.

Wann sollte man aufhören Diagramme zu zeichen? Auch hier bin ich mit Robert C. Martin einig: Immer dann, wenn das Coding ein besseres Ergebnis bringt und man sich um Details kümmern muss.

Was braucht das Team im Sprint Planning 2?

Vor allem Entscheidungen. Muss das Team auf eine Entscheidung warten, dann steigt das Risiko, dass der Sprint gerissen wird, dass es zu einer Blockade kommt. Entweder konnte man alles offen in der Zeit zwischen Sprint Planning 1 und 2 klären, oder man entscheidet die letzten offenen Punkte im Sprint Planning 2. Wenn niemand eine Entscheidung trifft, dann trifft die Entscheidung das Entwicklungsteam. Dank eines empirischen Prozesses haben wir die Möglichkeit, anhand des Ergebnisses auszusteuern. Zudem sind die geschaffenen Fakten genau das benötigte Mittel, das die meisten Menschen brauchen, um Entscheidungen zu treffen. Hier sind wir wieder bei Entdeckungen, die nötig sind, um Gedankengänge des Auftraggebers oder der Benutzer der Anwendung abzuschließen. Mit Entscheidungen über die Funktionen und die Details durch das Enwicklungsteam bringen wir letztlich den gesamten Prozess und die Produktentwicklung nach vorne.

Was braucht es noch? Zugriff auf den Source-Code ist wichtig, damit wir direkt nachsehen können und nicht auf Vermutungen und Befindlichkeiten basierend diskutieren müssen. Kennen Sie das auch:

A: “Das müsste doch nur eine Wenn-Dann-Klausel sein!”
B: “Nein, ich glaube da hängt ein echt kompliziertes Konstrukt dahinter!”

Hier heißt es, Fakten schaffen und nachsehen. Das spart Zeit und führt schneller zu einer Lösung. Unabdingbar für einen Software-Entwickler ist das Whiteboard. Wir diskutieren mit Hilfe von  Diagrammen, die wir immer wieder durch unser “Testen” im Dialog verfeinern. Zudem benötigen wir alle User Stories aus dem Sprint Planning 1, am besten in einer visualisierten Form auf einem Flipchart. Auf dem Flipchart finden wir bspw. die Punkte wie technische Constraints, Abhängigkeiten zu anderen Komponenten und Teams, unsere geplanten Akzeptanztests und die Akzeptanzkriterien.

Fazit

Wenn Sie alle diese Punkte beachten, dann sind Sie auf den Weg zu einem guten Sprint Planning 2 und einem Sprint, der erfolgreich mit gemeinsamer Interaktion durchgeführt werden kann. Es kann sein, dass Ihr Team noch Unterstützung im gemeinsamen Umgang mit UML braucht. Hier hilft es, eine Study Group einzurichten und etwas Freiraum für das Lernen von UML zu schaffen.

Viel Erfolg und Spaß im nächsten Sprint Planning 2! (Lächeln)

Avatar of Sven Winkler
Sven spricht viele Sprachen: Von Java und Perl über C# bis XML - sogar ein wenig Japanisch kann er. Der erfahrene ScrumMaster, Product Owner und Software-Architekt aus Nürnberg gibt unumwunden zu, dass er gerne und viel redet, vor allem über Agile Softwareentwicklung im Allgemeinen und Scrum im Speziellen. Aber es gibt immer wieder einen Moment, in dem es ihm vor Freude die Sprache verschlägt: Wenn er erlebt, wie die Menschen, die er auf ihrem Weg mit Scrum unterstützt, plötzlich den Wert ihrer Arbeit spüren.
  • http://yascrum.blogspot.com/ Sebastian Radics

    Wieder ein super Post. Danke dafür!
    Wir haben auch schon viel mit dem SP II experimentiert. Bzgl. der Verwendung von Code, um Fragen wirklich zu klären, kann ich Dir nur zustimmen. Mir fällt auf, dass wir noch zu wenig mit Diagrammen arbeiten … da helfen uns die Tipps (bis wohin es sinnvoll ist und das evtl. noch mehr Wissen aufgebaut werden sollte, um mit Diagrammen effektiv und effizient zu arbeiten).

    Womit ich im SPII auch sehr gute Erfahrungen gemacht habe, war der Schritt nur wirklich die Stories in Tasks aufzuteilen, die als erstes abgearbeitet werden (und dann im Sprint die nächsten Stories mit “kleinen” SPII’s in Tasks zu zerlegen). Dass hält den Fokus sehr gut auf den wichtigsten Stories und ist aus meiner Sicht sehr schlank, da nur das erfasst wird, was gerade notwendig ist…

    • http://twitter.com/svnwnk Sven Winkler

      Hi Sebastian,

      vielen Dank, das höre ich gerne! :-)

      Zu deinem Punkt mit den “ersten Stories” fällt mir eine Daumenregel ein:
      Das Hauptaugenmerk immer auf den Start legen, aber in jede Story einmal reingesehen haben. Je länger der Sprint, desto mehr Zeit auf die Stories am Anfang des Sprints verwenden. Soll heißen bei zwei Wochen nehme ich mir die Zeit über alle Stories ordentlich drüber zu gehen (Fokus auf den TOP-Stories). Bei einem längeren Sprint möchte ich mit meinem Team die TOP-Stories geklärt haben und in jede Story einmal reingesehen haben, damit ich Synergie, Konflikte und Risiken erkenne. Vielleicht findet das Team noch eine versteckte Abhängigkeit zu einem anderen Team oder benennt eine Schlüsselfrage (fachlich wie technisch). In jedem Fall steigt mit der Länge des Sprints auch die Gefahr, dass ich beim Sprint Planning 2 Zeit beim initialen Planen verschwende, da sich nach 2 Wochen keiner mehr an alle Details erinnern kann und ich von neuem Zeit dafür aufwenden muss. Daher lieber kurz einen Blick reinwerfen und dann nachplanen.

      Die Scrum-Meetings sind ja immer ein Anlass um Gespräche zu fördern und Gesprächs- und Klärungsbedarf hochzuspülen. Verfeinern passiert immer auch auf dem Weg.

      Als ScrumMaster würde ich zusammen mit meinem PO auch einmal ausprobieren womit das Team besser klar kommt. Mit kleinen Stories am Anfang des Sprints und Plannings oder eher mit großen. Zumindest einmal beobachten wenn das der Fall ist, wenn man keine homogene Größe im Sprint hat.

      Vielleicht noch eine persönliche Erfahrung. Ich habe schon viele Sprint Plannings von den unterschiedlichsten Teams und Organisationen gesehen. Die besten Plannings waren die, die ein gemeinsames Bild und eine gemeinsame Sprache erzeugt haben – über Code, über UML. Mittlerweile bin ich so weit: “Zeig mir dein Taskboard und ich sag dir wie dein Sprint Planning 2 aussieht und umgekehrt” ;-)

      Viele Grüße,
      Sven :-)

  • Thomas G.

    Basteln mag ich ja nicht so, aber der Blog ist gut ;-)