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:

Mike Cohn: User Stories Applied

Mike Cohn: User Stories Applied
Mike Cohn: User Stories Applied

User Stories Applied ist nach wie vor das Standard-Werk, wenn es um das Erstellen, Verwalten und Schätzen von User Stories geht. Mike Cohns Buch ist für Anfänger, die gerade beginnen, sich mit User Stories zu beschäftigen, ebenso gut geeignet wie als Inspriration für alte Hasen.

Im ersten, einführenden Teil erklärt der Cohn, was User Stories und Akzeptanztests eigentlich sind. Dabei erklärt er das Schreiben von Stories anhand des INVEST Paradigmas von Bill Wake. Wichtig fand ich das Kapitel 3 über die Benutzerrollen, denn das ist in meinen Augen der ideale Einstieg in einen Story-Workshop. Der Story-Workshop wird in Kapitel 4 als eine Möglichkeit vorgestellt, zu Ideen für User Stories zu kommen. Andere beschriebene Alternativen sind Fragebögen, Interviews und Beobachten von Benutzern. In Kapitel 5 erklärt Cohn, welche Rollen als User Proxy zum Einsatz kommen können und welche Stärken und Schwächen diesen Rollen anhaften. Ein wichtiges Kapitel, denn leider gibt es zu häufig keinen Kontakt zwischen den Entwicklungsteams und den Nutzern. Wie man Akzeptanztests für die User Stories erstellt, wie viele man benötigt und was sie beinhalten sollten wird im darauf folgenden Kapitel erklärt. Beendet wird der erste Teil des Buches einem Kapitel, das zusammenfasst, wie man gute User Stories schreibt. Man sollte mit klaren Zielen anfangen, große Stories aufteilen, das User Interface erst sehr spät beschreiben und noch einiges mehr.

Der zweite Teil des Buches beschäftigt sich mit Fragen rund um das Planen mit und das Schätzen von Stories. Zunächst geht Mike Cohn auf die Idee der Story Points ein. Er erklärt, warum es wichtig ist, dass das Team die User Stories gemeinsam schätzt. In Kapitel 9 wird erklärt, wie man ein Release mit User Stories plant. Kapitel 10 macht deutlich, wie die Arbeit mit User Stories in Interationen erfolgen kann (z.B. Sprints in Scrum). Zum Abschluß des zweiten Teils erklärt Cohn noch, wie die Velocity gemessen werden kann, wie sie bei der Planung hilft und wozu Burn Down Charts eingesetzt werden können.

Alle Themen, die nicht in die beiden ersten Teile passen, aber wichtig sind, werden im dritten Teil „Frequently Discusses Topics“ besprochen. Das erste dieser Themen ist in Kapitel 12 die Frage, was User Stories nicht sind, gefolgt von einem Kapitel zur Frage, warum man User Stories benutzen sollte. Kapitel 14 stellt einige Story Smells vor, die leider immer wieder passieren und in Kapitel 15 geht Cohn kurz auf das „Dream-Team“ User Stories mit Scrum ein. Abgeschlossen wird der dritte Teil mit verschiedenen Randthemen wie der Frage, nach den Zusammenhängen von Bugs und User Stories aus Anforderungs- und Planungssicht.

Das Buch wird durch einen vierten Teil abgerundet, in dem in mehreren Kapiteln ein Beispiel durchgesprochen wird. Dieser Teil ist im Wesentlichen für Einsteiger interessant, die Orientierung für das Handwerk benötigen.

Wie eigentlich alles, was Mike Cohn schreibt, kann ich auch dieses Buch wärmstens empfehlen.

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

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

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.