Agile Methode Burnup Chart

 

Agile Methode: Burnup Chart (Burn Up Chart)

Der Burnup Chart wird, genau wie der Burndown Chart, zur Darstellung der erbrachten Leistung innerhalb eines Leistungsentwicklungsprozesses verwendet. Der Unterschied zwischen den beiden Verfahren liegt nur in der optischen Darstellung der gleichen Sachverhalte. Welches der beiden Instrumentarien verwendet wird, ist eine Frage des persönlichen Geschmacks.

Die nachfolgende Abbildung zeigt beispielhaft einen Burnup Chart für einen Sprint, basierend auf der Anzahl der geplanten Task (Arbeitspakete)

Burnup Chart

Die Timebox ist hier auf 19 Arbeitstage begrenzt. Es sind 150 Tasks geplant. Mit zunehmender Abarbeitung der Tasks nähert sich der Burn Up Chart der roten Linie an. Liegt die Team Velocity über der Ideal Linie, dann kommt das Team schneller voran als geplant. Liegen die Werte unter der Ideal Linie, dann erfolgt die Arbeit langsamer. 

Wenn der Brunup Chart zur Kontrolle der Produktentwicklung genutzt wird, dann kann der Entwicklungsfortschritt in Story Points gemessen werden. Veränderungen in der Planung der Story Point und der Entwicklungsdauer können mit dem Burnup Chart dargestellt werden.

Burn Up Chart Änderungen

Reduziert sich die Zahl der ursprünglich geplanten Story Point (Basisplan) zu einem bestimmten Zeitpunkt, dann sackt die schwarze Linie nach unten. Erhöht sich die Zahl der Story Points, dann geht diese Linie nach oben.

Ähnlich verhält es sich mit der Dauer der Produktentwicklung. Ausgehend von der schwarzen Linie auf der Zeitachse, verschiebt sich diese nach rechts, wenn die Produktentwicklung länger dauern soll, als ursprünglich geplant. Soll die Produktentwicklung verkürzt werden, verschiebt sich die Linie nach links.

 

Agile Methode Product Owner Direkte Kommunikation

 

Agile Methode: „Product Owner“ Direkte Kommunikation

 Ein Aspekt des agilen Arbeitens liegt darin, dass die Menschen direkt und Face-to-Face miteinander reden. Das ist die beste Form, um zu verstehen, was die andere Seite meint und die schnellste Form des Informationsaustausches.

Ein Aspekt der Rolle des „Product Owners“ ist die Kommunikation mit den Stakeholdern. Der Product Owner sammelt die Anforderungen der verschiedenen Stakeholder in direkten Gesprächen ein, Findet heraus, was – ausgehend von diesen Gesprächen für das Produkt als Ganzes von größtem Wert ist (Priorisierung) und schätzt in Interaktion mit dem Team den Aufwand. 

ProductOwnerKommunikation scaled

Der Product Owner ist eine Kommunikationsschnittstelle und ein Informationsfilter zwischen den Leistungsanforderern und den Leistungsentwicklern. Er ist ein Informationsfilter

In dieser Funktion als „Informationsfilter“ steht er im Wiederspruch zum dem agilen Grundsatz der direkten Kommunikation. Die Rolle dieses Informationsfilters ist nur darin begründet, dass die direkte Kommunikation von Team und Stakeholdern dazu führen würde, dass das Team nicht gleichzeitig mit allen Stakeholdern kommunizieren und eine Leistung erstellen kann. 

Totz der Rolle des Product Owner ist der direkte Kommunikationsweg zwischen Team und Stakeholdern offen und gewünscht. Innerhalb einer Timebox der Leistungserstellung kann jedes Mitglied Unsicherheiten über eine direkte Nachfrage an den Product Owner klären, aber wenn es schneller oder einfacher geht, kann es auch direkt bei dem jeweiligen Stakeholder nachfragen. 

Auch wenn die Pflege des Product Backlogs in der Verantwortung des Product Owners liegt, bedeutet das nicht, dass er diese Aufgabe alleine macht. Vielmehr koordiniert er die Interaktion von Stakeholdern und Leistungserstellungsteam. Wenn z.B. User Stories im Product Backlog verwendet werden, dann ist die aufgeschriebene Story nur ein Platzhalter für das Verstehen der User Story durch das Team.

Ebenso ist es natürlich, mit der Weiterentwicklung von User Stories von größeren zu kleineren Einheiten und dem Verstehen der Akzeptanzkriterien der Stakeholder durch die Leistungsersteller. Hier ist die direkte Face-to-Face Kommunikation zwischen Anforderer und Leistungsersteller der agile Weg des Verständnisses.

Spätestens beim Review kommen Leistungstersteller und Anforderer wieder zusammen und diskutieren über die Ergebnisse und damit über das gemeinsame Verständnis des Ergebnisses. 

Ein Kernelement des Agil richtet sich gegen Kommunikationsfilter. Natürlich kann das Filtern von Informationen den Kommunikationsaufwand für jeden Einzelnen verringern. Auch die Informationsbeschaffung für die nachfolgenden Einheiten ist einfacher, weil die Informationen bei jedem Filter stärker verdichtet werden. Dem entgegen steht das Risiko einer Fehlinterpretation.

Kommunikationsfilter

Ganz langsam und schwierig wird es, wenn das Team zwar verstanden hat, dass der Kunde „rot“ möchte, aber ein Detail nachfragen möchte.

Der rote Filter fragt dann den orangen Filter, der dann einen der Stakeholder fragt.

Der antwortet gelb, soweit bei dem gelben Stakeholder nachgefragt wird. Sonst antwortet er vielleicht blau oder pink.

Der grüne Leistungsersteller wartet in der Zeit auf die Information, ohne die er nicht weiter arbeiten kann. 

Der orange Filter versteht gelb. Er meldet das dem roten Filter weiter. Der wird jetzt auch gelb und meldet das dem Team weiter.

Das Team verwirft die Ergebnisse und macht jetzt gelb.

Was passiert, wenn den Stakeholdern, in der Mehrheit blau und pink, das Ergebnis irgendwann präsentiert wird?

 {article 245}[text] {/article}

 

Agile Methode Release Backup

Agile Methode Release Backup

Release Backup

Das Release Backup ist ein Planungstool, das bei der Aufteilung der Funktionalitäten eines Produktes unterstützt und hilft diese Entwicklung der Funktionalitäten im Zeitverlauf über mehrere Releases zu verteilen. 

Die Bezeichnung für die Release Planung unterscheiden sich innerhalb der Organisationen. Sie wird auch als langfristige Produktplanung oder meilensteingesteuerte Planung bezeichnet. Wenn nach jedem Sprint eine Auslieferung erfolgt, kann die Aufteilung in Releases auch als Sprint Mapping bezeichnet werden.

Die Fragen der Stakeholder, die mit der Release Planung beantwortet werden:

  • „Wann werden wir welche Inkremente geliefert bekommen?“
  • „Welche Funktionen werden wir bis zum Ende des Jahres bekommen?“
  • „Bis wann müssen wir wieviel Geld bereitstellen?“

Mit einem Release werden Funktionalitäten an den Kunden ausgeliefert. – So zumindest der Zusammenhang, in dem ich den Begriff Release hier verwende.

Je nach Vertragssituation, Stakeholder Wünschen und Produkteigenschaften, muss eine Entscheidung über die Kadenzen mit denen die Leistungen an den Kunden ausgeliefert werden, vereinbart werden. Die agilen Prinzipien empfehlen diese Auslieferungszyklen möglichst klein zu halten. Einerseits, um frühzeitig ein Feedback zu erhalten und so Fehlentwicklungen zu vermeiden, andererseits damit die (Teil-)Produkte am Markt möglichst früh einen Deckungsbeitrag generieren können. 

Denkbar sind folgende Kadenzen:

 Kadenzen Zyklen von Releases

Bei manchen Produktentwicklungen werden Minimum Relesable Features (MRFs) festgelegt. Es handelt sich um minimal freigegebene Funktionen, also um die Funktionen, die pro Release mindestens als Inkremente erstellt werden müssen. Das ganze Konzept dieser MRFs ist etwas schwierig, weil es nur dann realisierbar ist, wenn die Funktionen in einem Product Backlog alle vergleichbar sind. Außerdem sollen die User Stories, die in einer Timebox erstellt werden, ja nach Möglichkeit verbindlich sein. Das MRFs Konzept beinhaltet das Risiko, dass Timeboxes über die bearbeitbaren Anforderungen hinaus vollgestopft werden, so nach dem Motto: Vielleicht sind sie ja schneller. Wichtig sind ja sowieso nur die MRFs. 

 

Ein Produkt, das in dem Portfolio Backlog steht, ist zumeist nur sehr ungenau beschrieben. Die Beschreibung wird eben ausreichend sein, um die wirtschaftlichen Kriterien zu überprüfen und daraus die Priorität zu bestimmen, die das Produkt in Relation zu den anderen Produkten im Portfolio Backlog haben. 

Wahrscheinlich werden einige Funktionalitäten beschrieben sein und andere eher unklar bestehen. Die Genauigkeit der Schätzung für die einzelnen Funktionen und für den Aufwand der Produkterstellung kann sehr unterschiedlich sein. Das ist immer davon abhängig, wie genau der Auftraggeber und das eigene Unternehmen eine Kosten-Leistungsschätzung haben möchte und welche Kriterien in dem Unternehmen zur Wirtschaftlichkeitsprüfung von Investitionen zugrunde gelegt werden.

Für die Erstellung des Release Backups ist das zunächst nicht wichtig. Wir nehmen die Informationen die bisher erarbeitet wurden. Für das Release Backlog werden sie weiter entwickelt, überprüft und verfeinert.

vom Portfolio Backlog zum Release Backlog

Zunächst wird festgelegt:

  • Wie viele Releases gemacht werden sollen.
  • Wie lange die einzelnen Releases dauern sollen. Die Dauer der Releases kann auch als Timebox für die Produktentwicklung verstanden werden. 
  • Wie viele Aufwandspunkt, z.B. Story Points innerhalb eines Release abgearbeitet werden kann. Dafür können z.B. die Erfahrungen mit der Team Velocity genutzt werden.

Wenn zusätzliche Anforderungen dazu gekommen sind, werden diese Anforderungen ergänzt. Anders Ausgedrückt: es müssen neue User Stories geschrieben werden. Auch der für das Gesamtprojekt geschätzte Aufwand muss für jede Funktion oder User Story neu geschätzt werden. 

Die Prioritäten, die jetzt aus Perspektive der Funktionalitäten basierend auf dem Wert der jeweiligen Funktionalität aus Stakeholder Sicht ermittelt werden, sind ausschlaggebend für die Reihenfolge, mit der die Funktionalität in den Releases bearbeitet wird. 

Daraus entsteht ein Release Plan, der den Leistungserstellungsprozess des Produktes in mehrere große Einheiten unterteilt. Genau wie alle anderen Backlogs muss dieses Backlog regelmäßig überprüft und an die neueste Entwicklung angepasst werden. 

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.