Agile Methode Portfolio Backlog

 

Agile Methode: Portfolio Backlog

Das Portfolio Backlog ist eine Ideensammlung für neue Produkte, die erstellt werden könnten. Die Ideen, die hier enthalten sind, sind nach Prioritäten bewertet. Die Bewertung erfolgt nach wirtschaftlichen Kriterien. Neben der Priorität wird auch der Aufwand abgebildet, der für die Umsetzung der Produkte geschätzt wird.

Wenn ein Produkt in den Leistungserstellungsprozess übernommen wird, rückt das nächste Produkt eine Priorität nach oben.

Wenn wir das Vorgehen als agilen Prozess verstehen, dann wandert das Produkt jetzt in die Release Planung und wird dann mit Release Backlog weiter verarbeitet.

 

Agile Methode: Unternehmensplanung auf mehrere Ebenen

Agile Methode: Agile Unternehmensplanung auf mehreren Ebenen

Wenn wir die agilen Planungsprinzipien betrachten, dann wird deutlich, dass Planung auf mehreren Ebenen ansetzt. Die meisten agilen Systeme beschäftigen sich primär, mit einer sehr niedrigen Planungsebene, etwa auf der Ebene eines einzelnen Projektes, das mit einem kleinen Team realisiert wird. Diese Perspektive verschleiert, das Agil auf allen Unternehmensebenen angewendet werden kann.

Leider herrscht hier die übliche Begriffsverwirrung und Mehrdeutigkeit, wie sie in der Betriebswirtschaftslehre üblich ist.

AgileEbenenderLeistungserstellung

Beginnen wir also oben, bei der Unternehmensstrategie. Ich möchte hier nicht weiter darauf eingehen, ob und wie diese Agil gestaltet werden kann oder sollte. Wichtig ist für mich an dieser Stelle nur, dass aus dieser Unternehmensstrategie abgeleitet wird, welches Unternehmensportfolio an Produkten erstellt werden soll.

Das Portfolio enthält die Leistungen, die neu erstellt werden sollen oder an denen umfangreiche Veränderungen vorgenommen werden sollen. Diese Begriffsauffassung weicht von einer Reihe an anderen Definitionen von Produkt Portfolio ab. Im Marketing würde ich eine andere verwenden. Nach meiner Auffassung sind agile Methoden ideal für eine Neuentwicklung von Leistungen geeignet. Für eine kontinuierliche Weiterentwicklung eines Produktes sind andere Methoden besser geeignet. Z.B. ein Lean Management-Ansatz.

Die agile Methode die hier dafür vorgestellt wird, ist das Portfolio Backlog.

Mit Hilfe dieser Methode werden die Fragen beantwortet:

  • Welche Produkte werden in der Zukunft in unserem Unternehmen mit höchster Priorität und möglichst bald entwickelt werden?
  • Welchen Aufwand erwarten wir für die Entwicklung dieser Produkte?
  • Welche Haupteigenschaften sollen diese Produkte haben?

Betrachten wir die Ebene der einzelnen Produkte, dann treffen wir hier auf das nächste Abgrenzungsproblem. Nehmen wir das Beispiel Microsoft Office. Sind die Komponenten des Office Paketes (Word, Excel, Powerpoint, etc.) Komponenten eines Produktes oder sind es eigenständige Produkte? Ist das Produkt Word 10 ein eigenständiges Produkt oder nur ein weiteres Release von Word 7? Wie auch immer dieses philosophische Problem gelöst wird, wichtig ist hier, dass die meisten komplexen Produkte nicht in einem Zyklus entwickelt werden, sondern in mehreren Releases.

Das kann mit der Methode des Release Backlogs geplant und in der zeitlichen Abfolge in der Produkt Roadmap dargestellt werden.

Eine Ebene tiefer betreten wir die Betrachtungsebene von Scrum. Hier geht es um die Planung und Umsetzung eines Release oder eines kleinen Produktes mit einem Team. Natürlich gibt es auch agile Vorgehensweisen um auch Scrum Projekte mit mehreren Teams zu organisieren. Die Scrum Guide betrachtet diese aber nur am Rande.

Zur Planung der Leistungserstellung wird hier das Product Backlog verwendet. Mit dieser Methode werden die Timeboxes oder in der Scrum Terminologie „Sprints“ geplant. Aus dem Product Backlog werden die Leistungen ausgewählt, die in den einzelnen Sprints erstellt werden sollen.

In dem Product Backlog werden die gleichen Fragen beantwortet, wie in den vorhergehenden Backlogs, nur auf einer niedrigeren Ebene:

  • Welche Funktionalitäten sind von dem größten Wert und bekommen so eine höhere Priorität?
  • Welchen Aufwand erwarten wir für die Entwicklung der Funktionalitäten?
  • Welche Eigenschaften sollen die Funktionalitäten haben?

Erst auf Ebene der Timeboxes, bzw. Sprints nähern wir uns der Ebene der Leistungserstellung. Aber wir haben sie noch nicht ganz erreicht. Auch bei der Planung der Sprints wird nur geplant. Während des Sprint Planing wird festgelegt, was innerhalb einer Timebox geleistet werden soll und mit welcher Priorität – natürlich wieder unter Berücksichtigung des geschätzten Aufwandes. Gesteuert wird der Sprint über ein Kanban Board.

Bisher wurde nur geplant. Erst nach dem Sprint Planing beginnt die eigentliche Leistungserstellung. Hier erfolgt die Steuerung dann über und in dem Daily Standup Meeting.

 Wieviel Planung ist in Agil?

Wenn ich das oben gesagte im Zusammenhang lesen, dann liegt der Schluss nahe, dass agilem arbeiten ein mehrstufiger Planungsprozess vorausgeht, der sehr komplex ist. Auf jeder Planungsstufe werden die gleichen Fragen beantwortet – nur immer bezogen auf kleinere Einheiten:

  • Was ist von größtem Wert und sollte zuerst gemacht werden?
  • Welche Anforderungen werden an die Leistung gestellt?
  • Welchen Aufwand erwarten wir bei der Leistungserstellung?

Die präferierte agile Methode ist dabei das Backlog. In diesem Backlog werden allerdings nur die Ergebnisse festgehalten. Es ist also ein reines Tool zur Abbildung von Ergebnissen. Mit welchen Methoden die Ergebnisse entstehen, z.B. mit einer klassischen Risikoanalyse oder einer Schätzung des Kapitalwertes sind von den agilen Methoden nicht vorgegeben.

Die präferierte Methode für Feststellung von Anforderungen ist die User Story. Jede andere Methode zum Beschreiben der Anforderung ist aber auch möglich.

Die Basis für die Schätzung des Aufwandes erfolgt in Story Points. Die Schätzung erfolgt nicht in absoluten Kosten oder Zeitwerten, sondern in einer Schätzung der relativen Größenverhältnisse der User Stories. Wobei das natürlich nicht zwingend vorgeschrieben ist. Die Story Points können in Personentage und darüber in Kosten umgerechnet werden. Die Leistungsfähigkeit eines Teams wird als Team Velocity ermittelt und in Story Points pro Sprint gemessen. Die durchschnittlich erstellten Story Points pro Sprint bilden die Basis für die Zahl an Funktionalitäten, die innerhalb der nächsten Sprints erstellt werden sollen.

Die Pläne der verschiedenen Ebenen werden ständig überprüft und neuen Gegebenheiten angepasst.

Wenn jetzt einige Leser sagen: „Schön, – wenn wir jetzt mal die ganzen neuen Worte weglassen -, so haben wir doch immer schon gearbeitet. Was soll ich jetzt agil besser machen?“ Dann fällt mir nur die Antwort ein: „Lerne die neuen Worte“. Wenn Sie bisher anders gearbeitet haben, dann liegt im agilen Arbeiten ein großes Verbesserungspotential.

 

 

 

 

 

Agile Methode: Agil planlos Planung auf mehreren Ebenen

Agil = planlos? – Planung auf mehreren Ebenen

Eine der gängigsten Annahmen zum agilen Arbeiten: Jetzt müssen wir nicht mehr planen. Wir können alles spontan entscheiden und jederzeit ändern. Wir fangen einfach an und die Details werden nebenher geklärt.

Nichts könnte falscher sein. Wenn Sie agil arbeiten, planen Sie mindestens so viel wie vorher – nur zu anderen Zeiten und an anderen Stellen.

Die agile Planung 

geht von einer Reihe von Grundannahmen aus. (Quelle: Rubin, K.S.: Essential Scrum (ISBN 978-3-8266-9047-1)

Glauben Sie nicht an im Voraus erstellte Pläne

Ein Plan ist immer eine Zukunftsvorhersage. Zukunftsvorhersagen sind, wie wir alle wissen, sehr schwierig und erweisen sich als fehlerhaft, je weiter in die Zukunft wir schauen und umso unsicherer die Umweltsituation ist. 

Oder anders ausgedrückt: Wir können die Zukunft nicht vorhersagen. Darum kann kein Plan richtig sein. 

Bedeutet das, dass wir keinen Plan brauchen? Was wollen wir mit einem Plan?

Wir wollen unser gemeinsames Vorgehen auf unserem Weg hin zu einem Ziel koordinieren. Wir geben uns also eine Richtung, in die wir gemeinsam gehen wollen.

Haben wir diesen Plan nicht, dann laufen und handeln alle Menschen in unterschiedlichen Richtungen. Jeder für sich (und Gott gegen Alle). 

Erst durch einen Plan wird eine Handlungsrichtung festgelegt und ein gemeinsames Handeln koordiniert.

Pläne sind also notwendig für ein gemeinsames koordiniertes Handeln.

Da wir aber die Zukunft nicht kennen, dürfen wird nicht blind auf den Plan vertrauen. Wir müssen bereit sein, ihn jederzeit der Realität anzupassen.

Plane hilfreich, aber nicht exzessiv

Wenn Sie spazieren gehen oder Auto fahren, planen Sie dann die ganze Strecke? 

Wenn ja, wie genau?

Planen sie jede Abzweigung? Jede Kurve? Jedes Ausweichen oder Bremsen?

Was würde denn passieren, wenn sie so genau planen würden und sich an diesen Plan halten würden, ganz exakt halten würden? Wie lange würden Sie überleben?

Viele Pläne in Unternehmen sehen genau so aus, wie ein Streckenplan, auf dem jedes Ausweichen und Bremsen im Voraus bestimmt wird. 

Das ist genau das, was ich unter exzessiver Planung verstehe. Eine solche Planung ist:

  • aufwändig und damit teuer,
  • sinnlos, weil nicht einhaltbar ist und
  • gefährlich, wenn sie sich daran halten.

Genau hier sind wir der agilen Welt angekommen. Planung ja, aber nicht zu detailliert. „Wir gehen in diese Richtung, weil wir dahin wollen. Alles andere wird „vor Ort“ entschieden.

Planungsoptionen bis zum letzten Augenblick offen halten

Haben sie schon einmal mit einem Bogen geschossen?

Einen Pfeil den sie abgeschossen haben, können sie nicht mehr zurückholen. 

So funktioniert eine Timebox, bzw. ein Sprint in der agilen Denkweise. Sehr deutlich wird das im Scrum.

Ein Sprint – meines mehrere- wird vorgedacht (geplant). Hierfür wird das Product Backlock verwendet.

Ein Sprint beginnt im Scrum immer mit dem Sprint Planing. Erst zu diesem Zeitpunkt wird festgelegt, welche Inkremente genau innerhalb dieses Zeitfensters von dem Team erstellt werden wird. Das ist festgelegt und wenn man sich einmal darauf geeinigt hat, dann kann auch kein Außenstehender das mehr ändern. Ein Sprint ist fast – aber nur fast, wie ein Pfeil der abgeschossen wurde. Der Plan ist festgelegt.

Aber nur fast, denn was ganz genau wann gemacht wird, das wir viel später entschieden. So spät wie möglich, nämlich von einem Tag auf den anderen Tag. Im Daily Meeting. Hier wird, basierend auf den was gestern passiert ist, festgelegt, was jeder einzelne heute tut. Für morgen wird noch nichts geplant. Wir wissen ja noch nicht, was heute passiert.

Wird das Ziel, das im Sprint Planing angestrebt wurde, erreicht? – vielleicht. Wir überprüfen das im Sprint Review. Wenn ja, dann haben wir gelernt, das wir gut geplant haben. Wenn nicht, dann haben wir gelernt, dass wir anders planen müssen. Was wir anders machen müssen, das klären wir dann in der Sprint Retrospektive. Erst nachdem wir diese neuen Erkenntnisse gewonnen haben, machen wir den nächsten Plan für den nächsten Sprint.

Wenn wir agil arbeiten, dann planen wir viel. Wir planen sogar sehr viel und sehr viel mehr als bei allen anderen Methoden, in denen wir einen großen komplexen detaillierten Plan entwickeln, dem wir dann, egal was passiert, bis zum Ende folgen. Wir planen ständig neu und um.

Neuplanung und Anpassung

ist das Planungskonzept im Agilen. Natürlich versuchen wir so viel vorherzusagen wie möglich. Aber wir wissen, dass unsere Vorhersagen falsch sein werden. Wir überprüfen sie ständig und passen sie an. Ein Plan ist nur ein Zwischenzustand bis zur nächsten Veränderung. Da wir das wissen, sind wir gegenüber dem Plan immer misstrauisch.

Oder anders ausgedrückt: Wir vertrauen unserer Landkarte nicht absolut. Wir vergleichen die Landkarte immer mit dem Gelände auf dem wir uns bewegen – und wenn das Gelände anders aussieht, als die Karte, dann richten wir uns nach dem Gelände, welches wir sehen. Vertrauen sie ihrem Navi? Das ist begrenzt klug. In den meisten Fällen stimmt es und in einigen Fällen sind Navi Benutzer in den Rhein gefahren, weil das Navi glaubte, es gäbe an dieser Stelle eine Brücke. Fazit: selber denken und nicht auf einen Plan vertrauen.

Das richtige Maß – zu viel ist Gift

Agil versucht die Balance zu halten zwischen einem „zu viel an Vorausplanung“, die eine falsche Sicherheit über das „was  passieren wird und das, was zu tun ist“ schafft und damit die Menschen davon abhält, selber zu denken. Der Aufwand, der in eine Planung investiert wird, sollt im richten Verhältnis zu der Wahrscheinlichkeit stehen dass er wieder geändert werden muss. „Keine Medizin ist schlecht – zu viel Medizin aber“. 

Je unsicherer der Weg, umso kleiner die Schritte

Wie gehen sie über eine ebene Straße in einer Fußgängerzone? Wie gehen sie über eine unbefestigte Wiese irgendwo auf einem Feld? 

In dem einen Fall machen sie wahrscheinlich große Schritte und achten wenig darauf, wohin sie ihre Füße setzen. In dem anderen Fall überlegen sie jeden Schritt sorgfältig und achten bewusst darauf, wohin sie treten.

Also wie groß sollen die Timeboxes sein, die sie für den Leistungserstellungsprozess planen? 

 

 

Agile Methode Definition of Ready

Agile Methode: Definition of Ready (Definition von Bereit)

Die Definition of Done beschreibt, wann ein Product Backlog Item (PBI) nach der Auffassung des Entwicklerteams fertig ist und darum innerhalb einer Timebox nicht weiter bearbeitet werden muss.

Die Definition of Ready steht genau auf der anderen Seite einer Timebox. Sie beschreibt, wann ein Product Backlog Item (PBI) umfassend und genau genug beschrieben ist, dass es in einer Timebox bearbeitet werden kann.

Definition of Ready und Timebox Sprint

Die Definition of Ready wird vom dem Entwicklerteam bestimmt. Sie entsteht in der Zusammenarbeit mit den Product Owner und allen Anforderern. Es handelt sich dabei um eine Checkliste. Mögliche Punkte auf diese Checklisten können sein:

  • Der Geschäftswert ist klar benannt.
  • Das Entwicklerteam hat die Einzelheiten der Anforderungen verstanden.
  • Es gibt keine internen und externen Abhängigkeiten, die der Fertigstellung des PBI entgegenstehen.
  • Alle Teamressourcen für die Fertigstellung sind vorhanden.
  • Das PBI kann innerhalb eines Sprints fertig gestellt werden.
  • Die Akzeptanzkriterien sind bekannt, verstanden und testbar.
  • Das Team hat verstanden, was beim Sprint Review demonstriert werden soll.

 

Agile Methode Story Mapping

Agile Methode: Story Mapping

Jeff Patton entwickelte diese Technik im Jahr 2009. Das Story Mapping ist eine anwenderzentrierte Perspektive zur Entwicklung eines Satzes von User Storys. Es ist damit eine Kombination des anwenderzentrierten Designs mit der Story-Zerlegung. Es zeigt den Aktivitätsfluss aus Sicht des Benutzers und den Kontext der Storys.

Die Aktivitäten, die ein Benutzer mit einer Leistung durchführt, werden in einen oder mehrere Arbeitsabläufe zerlegt. Dieser Arbeitsablauf wird dann in eine Reihe von detaillierten Aufgaben zerteilt.

Wie geht es?

  • Eine Aktivität (Epic) wird in
  • Aufgaben (Themen, Tätigkeiten) aufgeteilt und dann in
  • Teilaufgaben (sprintfähige Storys) zerlegt.

 

Auf dem höchsten Abstraktionsniveau befinden sind die Epics. Sie müssen einen messbaren Wert für den Auftraggeber repräsentieren. (Beispiel: Einkauf von Lebensmitteln in einer Verkaufsstätte)

Daraus entsteht dann, entlang einer Zeitachse, die Abfolge der Aufgaben, bzw. Tätigkeiten. Links die erste Tätigkeit, usw.

Aus diesen Tätigkeiten werden die User Storys entwickelt. So wird jede Aufgabe in eine Reihe von umsetzbaren User Storys zerlegt.

Agile Methode User Story Workshop

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 Definition of Done

 

Agile Methode: Definition of Done (Definition von fertig, Done)

Innerhalb jeder Timebox, bzw. innerhalb jedes Sprints sollte mindestens ein potentiell auslieferbares Produktinkrement erstellt werden.

Durch die Definition of Done wird festgelegt, was das Entwicklerteam unter „potentiell auslieferbar“ versteht. Das „Done“ beschreibt den angestrebten Zustand der Arbeit, der am Ende des Sprints erreicht werden soll.

Diese Definition of Done wird von dem Entwicklerteam gemeinsam festgelegt.

Die Definition of Done basiert also auf einer Entscheidung des Entwicklerteams. Natürlich findet hier ein Abstimmungsprozess mit dem Product Owner und anderen Stakeholdern statt. Aber es handelt sich hier um eine Festlegung des Entwicklerteam. In der Philosophie des Agil gibt es keine unternehmensweite Definition of Done, die auf Vorgaben von außen beruht und von allen Teams angewendet werden muss. Dabei werden funktionale und nicht funktionale Anforderungen des Unternehmens natürlich berücksichtigt.

Die Definition of Done ist kein starres Dokument, das am Anfang einmal definiert wurde und anschließend nicht weiter verändert werden darf. Es ist ein Living Document, das sich im Zeitverlauf entwickelt, den Gegebenheiten und der Erfahrung des Teams angepasst wird und im Zeitverlauf meistens genauer und detaillierter wird.

Die Minimalanforderung einer Definition of Done orientiert sich daran, was unter einem Inkrement zu verstehen ist. Ein Inkrement ist ein komplettes „Stück Funktionalität“, dass:

  • entworfen,
  • gebaut,
  • integriert,
  • getestet und
  • dokumentiert wurde und
  • nachweislich einen Wert erbringt.

Klingt einfach – ist es aber nicht. Nehmen wir das Beispiel „getestet“. Was versteht das Team jetzt genau unter „getestet“. Bedeutet das, dass das Modul einmal funktioniert hat – oder dass es im Zusammenhang mit allen anderen Modulen einmal funktioniert hat. Oder das es z.B. einem Motor, über 1000 Stunden bei Höchstleistung nur einmal innerhalb der Laufzeit ausfällt und dann innerhalb von 2 Minuten wieder repariert werden kann? Und wie geht das Team mit dem Test von Modulen um, die zusammenarbeiten sollen, von denen aber einige erst in einem späteren Sprint erstellt werden?

In Tests, die einen längeren Zeitraum benötigen, liegt eine besondere Herausforderung. Ein Test, der über 1500 Stunden läuft, kann kaum innerhalb einer Timebox von 14 Tagen durchgeführt werden. Der Test muss zwangsweise außerhalb der Sprints stattfinden. Sonst müsste mit dem Beginn eines neuen Sprints gewartet werden, bis der Test abgeschlossen ist, was die Produktentwicklung ziemlich in die Länge ziehen würde. Aber wie geht das Team dann damit um, wenn dieser Test Fehler erkennen lässt.

Natürlich ist es extrem Aufwändig, solche Leistungstests in jedem Sprint durchzuführen. Einfach wäre es, einen Testsprint zu planen und dann alles zusammen zu testen. Aber was macht das Team dann, wenn sich heraus stellt, dass es doch einige Fehler gibt, so das Technische Schulden aufgebaut wurden? 

Eine Definition of Done sinnvoll zu erstellen, setzt viele Vorentscheidungen voraus und kann ausgesprochen komplex werden. Eine eineindeutig beste Lösung wird sich wohl nicht ergeben. Ein Kompromiss zwischen verschiedenen Alternativen ist hier eher wahrscheinlich.

Bei einer Definition of Done handelt es sich zumeist um eine Checkliste.

Was führt zu einer Veränderung der Definition of Done?

Manchmal bestehen am Anfang eines Projektes organisatorische Hürden, z.B. für die Durchführung von Nutzertests, weil die Nutzer nicht zur Verfügung stehen, oder weil es keine ausreichenden Testdaten gibt, etc. Im Verlauf der Leistungserstellung können diese Hürden beseitigt und damit die Definition of Done verändert werden. Es ist aber auch möglich, dass das sich eine bestehende Definition of Done als nicht detailliert genug erweist und darum geändert werden muss. 

Wichtig ist hierbei, dass die Veränderung in der Entscheidung des Teams liegt und nicht von außen vorgeschrieben wird.

Definition of Done und Akzeptanzkriterien

Die Definition of Done legt fest, wann ein Inkrement vorliegt. Also welcher Zustand vorliegen muss, damit das Team etwas für „potentiell auslieferbar“ hält. Die Definition of Done gilt dabei für alle Inkremente. Ob die Definition of Done erfüllt ist, prüft das Team vor dem Review durch den Product Owner. 

Akzeptanzkriterien werden für jede User Story vom Product Owner formuliert. Sie gelten für eine bestimmte Funktionalität, die sich aus der User Story ergibt. Damit bekommt jedes User Story ihre eigene Checkliste mit Akzeptanzkriterien.  Ob die Akzeptanzkriterien erfüllt sind, wird durch den Akzeptanztest geprüft, der spätestens im Review durch den Product Owner stattfindet. 

Die Definition of Done und die Akzeptanzkriterien sind also unabhängig von einander und existieren bei der Leistungsentwicklung nebeneinander.

 

Agile Methode Sprint Ziele

 

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?