Agile Methode: User Story Workshop

Ein gerne vorgeschlagener Weg User Storys zu bekommen, besteht darin, die Anwender und Stakeholder in Einzelgesprächen zu fragen, was sie von einer neuen Leistung erwarten. Das kann in Einzelgesprächen gemacht werden – aber es ist für die meisten Stakeholder der schwierigere Weg.

Besser und durch den interaktiven Austausch der Teilnehmer effizienter sind User Story Workshops. In diesem Workshop soll kein vollständiger Satz von User Storys entwickelt werden. Es geht also nicht darum – wie im klassischen Projektmanagement – alle Anforderungen zu Erfassen und detailliert auszuarbeiten. Es geht darum, Richtungen festzulegen und auf einem hohen Abstraktionsniveau zu arbeiten.

Ein solcher Workshop muss sich nicht auf ein Release beziehen. Es kann durchaus sinnvoll sein, das Endergebnis über mehre Releases durchzudenken. Die Teilnehmer beschäftigen sich dann mit der Frage: Wie soll das Produkt in fünf Jahren genutzt werden?

Wie geht es?

In einer User Story Workshop werden der Product Owner, die Stakeholder, die Auftraggeber und das Entwicklerteam einbezogen. Häufig ist es sinnvoll, zusätzliche Experten einzuladen, die ihr spezifisches Wissen in die Entwicklung mit einbringen.

Die Dauer eines Workshops erstreckt sich über mehrere Stunden, bis hin zu 2 Tagen. Immer in Abhängigkeit der Teilnehmerzahl und der Komplexität der Aufgabenstellung. 

• Das Ziel von User Story Workshops besteht darin nach Geschäftsfeldern, bzw. Bereichen zu suchen, in denen ein Wert für die Auftraggeber geschaffen werden soll. 
• Danach werden die Benutzerrollen festgelegt. Es werden die Perspektiven entwickelt, unter denen die zukünftige Leistung betrachtet werden soll. („In meiner Rolle als …“). Diese Rollen lassen sich gut als Personas beschreiben.
• Top Down oder Botton Up: Die Workshop Teilnehmer entwickeln die User Stories dann ausgehend von einer hohen Metaebene hinab zu einem höheren Detailreichtum. Es gibt aber auch Gruppen, die genau mit dem umgekehrten Verfahren – also von dem Detailreichtum hin zu einem höheren Abstraktionsniveau besser zurechtkommen. Es gibt hier kein richtiges oder falsches Vorgehen. Typischer für das Vorgehen ist jedoch die Progressive Verfeinerung also das Top Down Verfahren.

Agile Methode: Sprint Ziele (Timebox Ziel)

Es hat sich als sinnvoll erwiesen für jeden Sprint, bzw. für jede Timebox ein Ziel zu formulieren, dass durch diese Timebox erreicht werden soll. 

Ein solches Ziel kann die Umsetzung einer User Story sein, oder das Erstellen von einer oder mehrerer Funktionalitäten. Es kann aber auch nur einen Teilbereich einer User Story oder eine Teilfunktionalität sein, die in einer Timebox fertig gestellt werden soll.

Das zentrale Element eines solchen Ziels ist der Aspekt des Wertes. Innerhalb einer Timebox muss etwas erstellt werden, dass einen Wert für den Product Owner, bzw. die Stakeholder darstellt. Dieses Inkrement muss einen selbständigen Wert darstellen. Der Wert muss also als solcher – unabhängig von allen Funktionalitäten die die Leistung sonst noch hat – entstehen. 

Am Ende der Timebox muss in einem Review von den Stakeholdern überprüft werden können, ob das Ziel erreicht wurde. 

 Gegenseitige Verpflichtung von Team und Product Owner

Das Sprint Ziel ist eine gegenseitige Verpflichtung zwischen dem Team, das die Leistung erstellt und dem Product Owner als Vertreter der Auftraggeber und sonstiger Stakeholder.

• Das Team verpflichte sich am Ende der Timebox das Ziel zu erfüllen.
• Der Product Owner verpflichtet sich das Ziel nicht zu verändern und das Team zu unterstützen.

 Das Ziel muss also über den Zeitraum des Sprints konstant bleiben, damit das Team konzentriert auf dieses Ziel hinarbeiten kann. 

Zwischen „Änderung“ und „Klärung“

Das Ziel darf nicht verändert werden. Wenn ein Ziel verändert wird, dann bedeutet das, dass neue Tasks hinzu kommen, alte Tasks entfernt werden, Funktionalitäten geändert werden, User Stories neu geschrieben werden und insgesamt ein Neuplanung des Sprint stattfinden muss.

Eine Klärung bedeutet, dass z.B. eine User Story detaillierter erläutert wird, so dass das Team besser versteht, was damit gemeint ist. Dabei dürfen dann aber keine zusätzlichen Tasks auftauchen, Funktionalitäten zusätzliche Eigenschaften bekommen oder ähnliches Zusätzliches entstehen, dass über die geplante WIP (Work in Process) der Timebox hinaus geht. 

Entstehen bei der „Klärung“ solche zusätzlichen Arbeiten, dann sind sie in Form einer neuen User Story zu formulieren und werden Teil des Product Backlogs – und in einem späteren Sprint bearbeitet.

Abnormaler Abbruch

Natürlich gibt es immer die Möglichkeit, dass ein Sprint abgebrochen werden muss, weil das gesetzte Ziel seinen ökonomischen Wert verloren hat. Hierbei handelt es sich jedoch um eine äußerst seltene Ausnahme. Wie häufig kann es vorkommen, dass ein Product Owner innerhalb von 4 Wochen erkennt, dass ein von ihm festgesetztes, mit den Stakeholdern abgesprochenes Ziel seinen ökonomischen Sinn verliert?

Agile Methode: Daily Standup Meeting (Daily Scrum)

Das tägliche Treffen von fünf bis 20 Minuten Dauer für die Koordination des Teams innerhalb eines Tages gehört zum festen Bestandteil des agilen Arbeitens. Hier findet die Feinabstimmung des Arbeitsprozesses statt. Scrum Master und Product Owner können anwesend sein, um Fragen zu beantworten. Die Koordination und die Vorgehensentscheidungen liegen ausschließlich in der Hand des Teams.

Das Team verwendet zumeist ein Taks Board um sichtbar zu machen wer an welcher Aufgabe arbeitet.

Es hat sich eingebürgert, dass alle Teilnehmer bei diesen Treffen stehen.

Im Scrum sind drei Fragen festgelegt, die jedes Mitglied des Entwicklerteams zu beantworten hat:

1. Was habe ich seit dem letzten Daily Scrum für das Team geleistet?
2. An was möchte ich bis zum nächsten Daily Scrum arbeiten?
3. Welche Hindernisse behindern mich bei meiner Arbeit?

Was wird hier nicht besprochen?

Abstimmungen zwischen den einzelnen Teammitgliedern über technische Fragen, das Klären von internen und externen Konflikten und ähnliche komplexe Themen werden innerhalb des Daily Standup Meetings nichts besprochen. Dieses Meeting dient nur der Koordinination des Arbeitsprozesses. Für alle anderen Themen werden – auch auf diesem Treffen – andere Termine vereinbart.

Agile Methode: Sprint Backlog (Timebox Backlog)

Das Sprint Backlog ergibt sich aus der Sprint Planung. Das Sprint Backlog beinhaltet die Funktionalitäten, die innerhalb eines Sprints (bzw. einer Timebox) erstellt werden müssen und die Arbeiten (Tasks, Arbeitspakete), die zur Erstellung durchgeführt werden müssen. Zusätzlich werden die Schätzungen Arbeitsstunden, die für die Tasks vorgesehen sind, dargestellt. Wenn eine Umrechnung von Story Points in Arbeitsstunden oder Personentage erfolgt ist, können natürlich auch Story Points verwendet werden.

Dieses Product Backlog kann dann in Form eines Kanban Board zur Steuerung der Leistungserstellung weiter verwendet werden. Es ist gut mit einer Work Breakdown Structure kombinierbar.

Agile Methode: User Story, Funktion, Task, Inkrement

Die Begriffe User Story, Funktion, Tasks und Inkrement gehen in der Literatur ziemlich durcheinander und werden je nach Autor unterschiedlich verwendet. Ebenso unklar ist die Meinung über die Beziehung zwischen den verschiedenen Begrifflichkeit. 

Der einfachste – aber selten gegebene Zusammenhang besteht darin, dass eine User Story einer Funktion entspricht und diese Funktion wird in einem Task hergestellt. Es entsteht ein Inkrement, das von dem Kunden selbständig nutzbar ist.

Häufiger Zusammenhang besteht in einer 1:N Beziehung. Eine User Story kann durch mehrere Funktionen erfüllt werden. Zur Erstellung einer solchen Funktion sind mehrere Tasks notwendig. Die Erstellung von einigen Tasks ist für mehrere Funktionen notwendig. Mehrere Funktionen zusammen genommen, ergeben ein Inkrement.

Beachten wir zusätzlich, dass jede User Story in Story Points geschätzt wird und mit einem Akzeptanzkriterium versehen ist und dass die Funktionen, bzw. Funktionalitäten der Leistung erst zu findende Problemlösungen sind, die basierend auf der User Story entwickelt werden, wobei hier auch wieder eine Schätzung auf Basis von Story Points vorgenommen werden muss und dann für jede Funktionalität die Arbeiten ermittelt werden müssen, die getan werden müssen (Task) und diese Tasks auf höchstens einen Arbeitstag heruntergebrochen und dann geschätzt werden müssen, dann ist der Planungsaufwand in den Agilen Methoden nicht gering.

Agile Methode: Product Backlog

Ein Product Backlog ist eine priorisierte Liste der gewünschten Produktfunktionalitäten. Aus Sicht der Leistungsersteller ist es eine gemeinsame Vereinbarung, welche Leistung erstellt werden soll. Die Prioritäten legen fest, in welcher Reihenfolge diese Funktionalitäten gebaut werden sollen.

Das Product Backlog enthält die Leistungsbeschreibung, die erstellt werden soll. In Scrum ist der Product Owner für die Zusammenstellung, Organisation und Koordination des Product Backlogs zuständig. Er stimmt sich mit den Stakeholdern und dem Team ab.

Der Product Owner ist verantwortlich für das Product Backlog und er hat die letztendliche Entscheidungsgewalt darüber, was im Product Backlog steht – aber er erstellt und entwickelt das Product Backlog nicht alleine und bestimmt auch nicht exklusiv, was in ihm steht. Die Entwicklung des Product Backlog ist eine Gemeinschaftsaufgabe von Stakeholder, Auftraggebern, Entwicklern, Nutzern und anderen Menschen. Ohne die aktive Mitarbeit dieser Menschen ist der Product Owner nicht in der Lage, seine Aufgabe zu erfüllen.

Das Product Backlog wird ständig weiter entwickelt. Es ist ein living Document. Die Leistungsbeschreibungen werden verfeinert, ergänzt, ersetzt und entfernt. Natürlich werden sie auch priorisiert, bzw. geordnet. An diesem progressiven Prozess müssen sich alle oben genannten beteiligen. – Und zwar nicht nur einmalig, sondern über den gesamten Prozess der Leistungserstellung.

Ein Product Backlog hat nicht zwangsweise eine bestimmte Form. Insbesondere ist es nicht zwangsweise eine Sammlung von Moderationskarten auf einem White Board. – Und wer einmal versucht hat, ein Product Backlog für ein umfangreicheres Produkt auf einem Whiteboard zu erstellen, wird sehr schnell an die „Kapazitätsgrenzen“ dieses Mediums gestoßen sein. Der zur Verfügung stehende Platz reicht einfach nicht aus. Ein Product Backlog kann eine Vielzahl von umfangreichen ergänzenden Dokumenten haben. Beispiel: Der Anforderer formuliert: „Ich erwarte, dass das Haus einen Dachstuhl hat.“ Soweit, so unklar. Es gibt mehrere Möglichkeiten mit dieser Unklarheit umzugehen. Wir können den Anforderer bitten, diese User Story so umzuformulieren, dass alle gesetzlichen Bestimmungen, bautechnischen Notwendigkeiten, statischen Voraussetzungen, etc. in der User Story genannt werden. Ich vermute, die meisten Bauherren werden damit überfordert sein. Und die meisten Whiteboards auch. Der andere Weg besteht darin einen Statiker und einen Architekten und andere Fachleute zu bitten, die Din Normen, gesetzlichen Vorschriften, etc. zusammenzustellen und von der User Story auf diese „Anhänge“ zu referenzieren. Damit erhalten wir dann einfaches Product Backlog und mehrere Ordner an Unterlagen, die alle Bauvorschriften, statische Berechnungen, Architekturzeichnungen, etc. enthalten. Das Leistungserstellungsteam erhält so eine genaue Anweisung was es erstellen soll – diese ist allerdings nicht mehr „Leichtgewicht“,

Es gibt keinen bestimmten Zeitpunkt, an dem eine Weiterentwicklung des Product Backlogs erfolgt. Sowohl das Team, das die Leistungserstellung umsetzt, als auch alle anderen Beteiligten arbeiten „immer mal wieder“ an dem Product Backlog. Aber bevor eine neue Timebox beginnt, müssen die zu bearbeitenden Product Backlog Items einer Definition of Ready entsprechen, damit das Team mit der Leistungserstellung beginnen kann.

Ein Product Backlog besteht aus Product-Backlog-Elementen (Product Backlog Items, PBIs) Ein solches PBI kann eine User Story sein, soweit User Stories von den Beteiligten und insbesondere von den Leistungserstellern als ideal für die Beschreibung der Aufgabenstellung angesehen werden.

• Ein PBI kann eine Funktion sein.
• Es kann aber auch eine Änderung an einem bestehenden Produkt
• oder ein Defekt der behoben werden soll,
• oder eine technische Verbesserung,
• oder eine Wissenserweiterung sein,
• oder was auch immer von den Leistungserstellern getan werden soll.

Die Product Backlog Items müssen keine User Stories sein. Es kann auch jede anderer Form der Anforderungsbeschreibung gewählt werden. Auch wenn hier von User Stories gesprochen wird. Diese sind nur ein Beispiel für eine Vielzahl an Möglichkeiten. Hauptsache alle Beteiligten haben ein gemeinsames Verständnis.

Ein Product Backlog enthält alle funktionalen Anforderungen. Die nicht funktionalen Anforderungen können Teil des Product Backolgs sein, oder Teil der Definition of Done. Die nicht funktionalen Anforderungen müssen auf jeden Fall in einem dieser beiden Dokumente aufgeführt sein.

Das Product Backlog ist am Anfang wenig detailliert. Es entwickelt sich im Zeitverlauf in einem interaktiven Prozess der Diskussion zwischen Entwicklerteam, Product Owner und Stakeholdern. Aus einer recht oberflächlich formulierten kleinen Zahl an Anforderungen entwickelt sich mit der Zeit eine große Zahl an kleinstrukturierten detaillierten Anforderungen. In der nachfolgenden Grafik wird davon ausgegangen, dass die Backlog Elemente als User Stories formuliert sind. Das ist nicht zwingend. Jedes andere Format für die Beschreibung der Anforderungen kann ebenso gewählt werden.

Backlog Items werden mit zunehmender Zeit, durch die Gespräche zwischen Stakeholdern, Product Owner und Entwicklerteam detaillierter. Der Detaillierungsgrad wächst mit der zunehmend klareren Vorstellung der Beteiligten über das erwünschte Endergebnis des Entwicklungsprozesses.

DEEP-Kriterium für gute Product Backlogs

Für gute User Stories gibt es das INVEST-Kriterium. Für das Product Backlog wurde das DEEP-Kriterium entwickelt. DEEP bedeutet:

• Detailed aporopiately (ausreichend detailliert),
• Emergent (emergent),
• Estimated (geschätzt),
• Prioritized (priorisiert).

Detailed aporopiately (ausreichend detailliert)

Oben wurde ja bereits dargestellt, dass sich die Product Backlog Items im Zeitverlauf entwickeln. Die PBI sind nicht alle zum gleichen Zeitpunkt gleich detailliert. PBI, die in der nächsten Zeit abgearbeitet werden sollen, stehen im Product Backlog weiter oben und sind detaillierter. PBI´s, die erst zu einem späteren Zeitpunkt bearbeitet werden, können weiter unten stehen und können wesentlich unspezifischer sein.

Es ist sinnvoll, die später zu bearbeitenden PBI zunächst unspezifisch zu lassen. Je geringer die Detailtiefe, umso geringer ist der Änderungsaufwand. Bevor mit der Bearbeitung begonnen werden kann, muss das PBI allerdings der Definition of Ready entsprechen. Vorher darf es nicht in den Sprint Backlog aufgenommen werden. Erfolgt die Aufnahme in das Sprint Backlog, bevor der Detailierungsgrad ausreichend ist, kommt es während der Leistungserstellung ständig zu Rückfragen zwischen Anforderer und Leistungserstellungsteam. Das verhindert einen effizienten Arbeitsfluss (Flow). Im schlimmsten Fall erstellt das Entwicklerteam etwas, das an den Bedürfnissen der Anforderer vorbei geht. Das kann dazu führen, dass die gesamte Arbeitsleistung eines Sprints verloren geht. Die Team Velocity wird extrem negativ beeinflusst.

Emergent (emergent)

Emergent wird hier in der Bedeutung „ständig aktualisiert und gepflegt“ verwendet. Das Product Backlog soll basierend auf einem ständigen Fluss von wirtschaftlich wertvollen Informationen weiterentwickelt werden. Wenn sich Kundenwünsche, Konkurrenzverhalten, etc. verändern, muss das Product Backlog angepasst werden. Neue Elemente müssen hinzugefügt und alte ständig verfeinert werden. Die Prioritäten passen sich ständig den veränderten Verhältnissen an.

Estimated (geschätzt)

Für jedes Product Backlog Element findet eine Größenschätzung statt. Diese Schätzung spiegelt den Aufwand wieder, der notwendig ist um das Element zu entwickeln. Basierend auf dieser Schätzung und dem geschätzten Wert des Inkrements wird die Priorität und damit die Position des PBI im Product Backlog ermittelt.

Die Schätzung erfolgt meisten in Story Points oder Idealtagen. Diese Größenschätzungen sollten relativ richtig, aber nicht extrem genau sein. Je weiter an der Spitze des Product Backlogs ein Element steht, umso weiter werden die Elemente in kleine Einheiten unterteilt und umso genauer muss auch die Schätzung werden.

Prioritized (priorisiert)

Auch die Priorisierung der Elemente muss genauer werden, je weiter sie nach oben rücken. Die Priorisierung der Elemente, die erst nach vielen Timeboxes erarbeitet werden sollen, kann eher grob bleiben

Agile Methode: Abstimmen auf einer Linie oder im Raum

Wenn verschiedene Meinungen oder Meinungsverteilungen sichtbar gemacht werden sollen, dann ist die „Abstimmung auf einer Linie“ ein gutes Verfahren. Es geht schneller und ist dynamischer, also das übliche „Heben der Hand“, wie es in den normalen Besprechungen üblich ist. Außerdem bekommt das Wort „Standpunkt“ hier wieder einer reale Bedeutung.

Wie geht es?

Der Moderator markiert mit einem Seil oder einem Klebeband eine Linie innerhalb eines Raumes. Eine Zustimmungs-Ablehnungsskala – oder verschiedene Meinungen werden auf dem Boden, z.B. mit Moderationskarten sichtbar gemacht. Die Teilnehmer ordnen sich entsprechend ihrer Meinung in dem Raum.

Variante

Wenn sich die verschiedenen Meinungen nicht eindeutig auf einer Skala anordnen lassen, können auch Bereiche im Raum gekennzeichnet werden, denen sich die Teilnehmer dann zuordnen.