Das I in INVEST – wie unabhängig können User Stories sein?

Heute hatte ich eine sehr spannende Diskussion. Es ging um das INVEST-Paradigma für User Stories, speziell um das I in INVEST. Das I steht für independent, also unabhängig.
Gute Stories sollen genau das sein: unabhängig.

Während der Diskussion ist mir bewusst geworden, dass das I in INVEST mindestens ebenso häufig falsch interpretiert wird, wie das zweite Wertepaar im Agilen Manifest.
Das I in INVEST – wie unabhängig können User Stories sein? weiterlesen

LaTeX Template für die Handelshochschule Leipzig

Für meine Master Thesis über den Goldstandard, die ich zum Abschluss meines Studiums an der Handelshochschule Leipzig schreibe, habe ich ein LaTeX-Template erstellt.

Es unterstützt den kompletten Umfang der „Guidelines for writing an academic assignment“ der HHL vom 11. Mai 2011. Inklusive der geradezu bösartigen Forderung, Römische Ziffern für die ersten Seiten zu verwenden und die Nummerierung am Ende der Arbeit, in der Bibliographie, fortzusetzen.

Das Grundgerüst habe ich vom LaTeX-Template der TU Chemnitz übernommen, das von Matthias Kupfer erstellt worden ist. Das komplette Template ist auf github allgemein verfügbar.

User Story Pattern: Teile und Herrsche

In meinem zweiten Artikel zum Thema Story Pattern möchte ich auf ein Problem eingehen, das mir vor kurzem bei einem Kunden begegnet ist.

Es gibt eine große Menge von auf den ersten Blick eher klein erscheinenden Änderungen an meinem Produkt, die bis zu einem bestimmten Zeitpunkt, z.B. einem Messeauftritt, fertig gestellt sein müssen. Die Liste der Änderungen kommt zu mir als Product Owner in Form einer Excel-Tabelle oder einer Powerpoint-Präsentation. Mit der Qualität der Beschreibungen können sowohl mein Team als auch ich gut leben. Wir wissen aber alle, dass die Menge der Änderungen zu groß ist, als dass sie bis zum gesetzten Termin umgesetzt werden können.
User Story Pattern: Teile und Herrsche weiterlesen

New, In Progress, Done – mehr nicht?

Ein Scrum Board kennt drei Zustände für Aufgaben, die im Sprint ausgeführt werden müssen. Nach dem Sprint Planning sind alle Aufgaben im Zustand „New“. Die so überschriebene Spalte des Scrum Boards repräsentiert das Sprint Backlog. Von links nach rechts sind die Aufgaben themenweise gruppiert und von oben nach unten sind die Themen priorisiert.
Sobald jemand eine Aufgabe beginnt, wandert diese Aufgabe in den Zustand „In Progress“. Ein guter Zeitpunkt um das zu machen ist das Daily Standup Meeting, aber natürlich kann man auch zu anderen Zeiten Aufgaben beginnen. Das Daily dient nur dazu, das Team zu informieren, was man an einem Tag alles tun möchte. „In Progress“ ist die Aufgabe erst, wenn man sie wirklich beginnt.
Den letzten Zustand „Done“ erreicht eine Aufgabe erst, wenn sie komplett abgeschlossen ist. Aufgaben von „In Progress“ nach „Done“ zu verschieben ist ebenfalls etwas, das im Daily Standup passieren sollte. Während es zumeist kein Problem ist, außerhalb des Daily Standup eine Aufgabe „In Progress“ zu nehmen, kann man mit dem Zustandswechsel auf „Done“ eigentlich problemlos bis zum nächsten Daily Standup warten.
New, In Progress, Done – mehr nicht? weiterlesen

Code-Reviews, ganz persönlich

Immer wieder begegne ich Entwicklern, die Tools für Code-Reviews benutzen. Ich tue das nicht mehr. Bisher ist mir kein einziges Review-Tool begegnet, das es mir ermöglicht, einen Review in der Qualität durchzuführen, die ich anstrebe. Weder Crucible, noch Jupiter oder mein Namensvetter Gerrit.
Code-Reviews, ganz persönlich weiterlesen

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.