Planning Pattern II – Test Driven Sprint Planning

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks
Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen
Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

Planning Pattern I – Planen für den Flow

In dieser Artikelreihe möchte ich einige Pattern vorstellen, die agilen Teams helfen können, die Ergebnisse ihrer Sprint Plannings zu optimieren. Die meisten der Pattern sind bei der Arbeit mit Scrum Teams entstanden, sie lassen sich aber auch gut für Extreme Programming oder Kanban adaptieren.

20 Tasks am Board
20 Tasks am Board

Vor einigen Jahren kam ich als neuer Scrum Master zu einem Team, das schon eine geraume Weile zusammenarbeitete. Das Team arbeitete mit 2-Wochen-Sprints, hatte ein dreispaltiges Scrum Board, also auf den ersten Blick nichts außergewöhnliches. Allerdings hatte das Team in den letzten drei Sprints sein Commitment nicht geschafft. Was mich erstaunte, denn Aufgaben erschienen mir durchaus im Bereich des Machbaren und das Team war fit.

Als neuer Scrum Master halte ich mich immer erst mal mit Kommentaren zurück und beobachte viel. Beim Sprint Planning war ich dann erstaunt, dass das Team fast einen ganzen Tag dafür aufwendete und am Ende lediglich 20 Tasks am Scrum Board klebten. Ich fragte das Team also, ob sie sich sicher seien, dass das so ok war. Das Team meinte, ja, das wäre OK so. Es kam, wie es kommen musste – der Sprint lief schief, weil sich die Teammitglieder die ganze Zeit nur gegenseitig auf den Füßen standen und Tasks ewig „In Progress“ waren.

In einer Retrospektive konfrontierte ich das Team mit der Idee, dass ein Task nicht länger als einen Tag dauern sollte. Diese Idee kommt ja nicht von ungefähr, sie ist der Garant für einen guten Flow während des Sprints. Wir diskutierten eine ganze Weile darüber und schließlich kam eine recht interessante Betrachtung dabei heraus:

  • 1 Task <= 1 Tag
  • 1 Sprint = 10 Tage
  • 1 Team = 7 Personen
  • 1 Person benötigt >=10 Tasks (folgt aus (1) & (2))
  • 7 Personen benötigen >=70 Tasks (folgt aus (3) & (4))

Eines der Teammitglieder war Physiker und konnte das auf diese Weise kompakt zusammenfassen. Ein Team mit sieben Personen benötigt für einen 2-Wochen-Sprint mit 10 Arbeitstagen mindestens 70 Tasks am Scrum Board, um sicherzustellen, dass ein Task nicht mehr als einen Tag in Anspruch nimmt.

Diese Erkenntnis ist auch bereits das erste Planning Pattern:

Schneide die Tasks so, dass ihre Anzahl mindestens der Anzahl der Arbeitstage im Sprint multipliziert mit der Anzahl der Teammitglieder entspricht.

200 Tasks am Board
200 Tasks am Board

Das Team nahm die Herausforderung an und beim nächsten Planning befanden sich statt 20 plötzlich fast 200 Tasks auf dem Scrum Board. Nach einer Weile hat sich die Menge der Tasks auf 90 bis 120 Tasks pro Sprint eingependelt. Die kleinen Aufgaben führten zu einer sehr entspannten und kontinuierlichen Abarbeitung während des Sprints – das Team hatte seinen Flow gefunden. Ein angenehmer Nebeneffekt war, dass das Sprint Planning sich drastisch verkürzte.

Dieser Artikel erschien zuerst im adesso Blog.

Vertraue der Macht – Schätzen ohne Bezugssystem

Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.
Vertraue der Macht – Schätzen ohne Bezugssystem weiterlesen

Einheit Story Points?

Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.
Einheit Story Points? weiterlesen

User Stories der Größe 1

Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.
User Stories der Größe 1 weiterlesen

Schätzereien

Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.
Schätzereien weiterlesen

Vortrag auf den Agile Testing Days 2013

Gestern hielt ich einen Vortrag auf den Agile Testing Days.
Das Thema war: Planning Pattern for Agile Testers.

In den letzten Jahren habe ich bei einger ganzen Reihe von Teams einige Pattern entdeckt, die bei der Integration von Testern in agilen Teams hilfreich sind.
Sehr oft stehen Teams vor dem Problem, dass die üblicherweise gelehrten Ansätze der Testplanung und des Testmanagements im agilen Kontext nicht funktionieren.
Um Teams diesbezüglich zu helfen, habe ich die Verhaltensweisen, die ich mit einger ganzen Reihe von Teams entwickelt habe, als Pattern beschrieben.

Die Folien stehen wie üblich auf Slideshare:

User Story Pattern: Teilen nach Schnittstellen

Dass User Stories dem INVEST-Prinzip genügen sollen, ist keine Neuigkeit und leicht zu verstehen. Wie man es in der Praxis erreichen kann, dass Stories diesen Prinzipien entsprechen, ist schon schwieriger. Sucht man bei Google nach Pattern für Story Schnitt findet man eine ganze Reihe von Ideen und Empfehlungen.
Ich möchte in einigen kurzen Artikeln einige Pattern vorstellen, die mir in Projekten begegnet sind – oder die ich mir gewünscht hätte 🙂

Beginnen möchte ich mit dem Pattern Teilen nach Schnittstellen (Split along interfaces).

Eine Änderung im System bedingt, dass eine Reihe von Schnittstellen, z.B. Web Services, angepasst werden müssen. Das kann z.B. bei Anpassungen am Datenmodell der Fall sein, wenn die gleichen Daten von verschiedenen Web Services für unterschiedliche Kontexte oder Anwendungsfälle benutzt werden.

Hier würde ich für jede Schnittstelle immer eine separate Story erstellen. Das wirkt vielleicht zunächst sehr aufwändig, weil vielleicht jede Story die gleiche Änderung beschreibt. Tatsächlich vereinfacht es aber meine Aufgaben als Product Owner.

Der Vorteil einer Story pro Schnittstelle liegt darin, dass ich als Product Owner die Möglichkeit habe, zu priorisieren. Habe ich nur ein Entwicklungsteam, kann ich entscheiden, welche Schnittstellen am wichtigsten sind und die Stories in eine entsprechende Reihenfolge zu bringen. Habe ich mehr als ein Team zur Verfügung kann ich bei getrennten Stories eine höhere Parallelisierung erreichen.

Ein gutes Schnittstellen-Design vorausgesetzt, sind sämtliche Stories isoliert voneinander testbar. Neben der Priorisierung schafft dieses Pattern auch Transparenz für mich als Product Owner. Ich kann jederzeit erkennen, wie weit mein Team mit den Änderungen fortgeschritten ist.

Schätzungen im Sprint-Planning

Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.

Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.
Schätzungen im Sprint-Planning weiterlesen

Was zwischen Planning I und Planning II passiert

Die meisten Teams, denen ich bisher begegnet bin, teilen das Sprint Planning in einen ersten und einen zweiten Teil. Im ersten Teil stellt der Product Owner die Items aus dem Backlog vor, die im den nächsten Sprint entwickelt werden sollen. Das Team hat die Möglichkeit fachliche Fragen zu stellen und der Product Owner antwortet. Im Planning II zerlegt das Team die Stories in Tasks. So weit, so gut.

Die fachlichen Fragen des Teams hat der Product Owner im Planning I beantwortet. Aber was ist mit den technischen Fragen? Über diese stolpern die meisten Teams während des Planning II. Oft passiert es dann, dass sich einzelne Teammitglieder vor ihren Computer setzen und in den Tiefen des Quellcodes abtauchen – nur, um dann für den gesamten Rest des Plannings nicht mehr aufzutauchen. Das ist ärgerlich für den Rest des Teams.

Manche Teams lösen das über ein Pre-Planning der Stories im Sprint davor. Allerdings das Pre-Planning zu verschwendeter Zeit führen, nämlich dann, wenn Stories doch nicht in den nächsten Sprint kommen.

Um diese Situationen zu vermeiden, habe ich mit meinen Teams eine Phase zwischen Planning I und Planning II eingeführt.
Was zwischen Planning I und Planning II passiert weiterlesen