Category Archives for "Methoden und Werkzeuge"

Scrum Themen Wand

Magic Prioritization

​Mit Magic Prioritization verfügen Sie über ein sehr einfaches aber doch wirkungsvolles Mittel, das Sie nutzen können, um große Mengen an Elementen wie Product Backlog Items oder auch sonstige Einträge, Anforderungen oder Ideen in eine relative Reihenfolge bekommen können.

​Magic Estimation vs. Prioritization

​Magic Prioritization ​und Magic Estimation klingen ähnlich, sind auch ähnlich, aber der Fokus ist ein anderer. Während wir ​bei Magic Prioritization auf eine relativen Priorisierung Wert legen, haben wir bei Magic Estimation den Fokus immer auf der relativen Schätzung​.

Vorbereitungen für Magic Prioritization

Zu priorisierende Elemente vorbereiten

​Wie auch bei Magic Estimation nicht anders, werden die zu bewertenden Einträge ausgedruckt und vorbereitet. Sie können diese auch auf Zetteln bereitstellen. Die Einträge müssen zu Beginn der Priorisierung vorhanden sein.

​Sie können die entsprechenden Ausdruck auch noch etwas vorbereiten. So kann es zum Beispiel hier je nach Situation sinnvoll sein, gleich ein Feld für die später geschätze Größe anzulegen. Das hilft auch gerade dann, wenn Sie die Werte in ein Tool überführen wollen.

​Eine beschriftete Skala für die Priorisierung

​Sie benötigen entweder einen großen Tisch oder Platz auf dem Boden. Dabei sollten Sie eine Skala einführung, die am oberen Ende mit "wichtig" beschriftet ist und am unteren Ende mit "weniger wichtig" beschriftet ist.

​Am schnellsten geht das in der Regel, wenn Sie sich dazu Maler Krepp oder ein anderes Klebeband schnappen und damit eine Linie auf dem Boden / Tisch "zeichnen". Die Beschriftung können Sie dann mit Klebezetteln oder Karteikarten vornehmen und an die entsprechenden Ende legen.

​Gleiches Verständnis

​Etablieren Sie auf alle Fälle ein gleiches Verständnis über den zu priorisierenden Inhalt. Wenn Sie das nicht im Vorfeld tun, dann müssen Sie später während des Vorgangs der Priorisierung diese Diskussionen auf Basis des Verständnis von den Backlog Items zulassen.

​Ich habe mehrere Teams gesehen, die das gleiche Verständnis nicht im Vorfeld erarbeiten. Dadurch entstehen dann Unruhen, denn die Leute wollen und müssen sich austauschen. Das muss nicht falsch sein, dann planen Sie aber deutlich mehr Zeit für Ihr Magic Prioritization ein.

​Durchführung für Magic Prioritization

​Verteilen der Product Backlog Items

​Alle Product Backlog Items können Sie willkürlich an die Teilnehmer verteilen. Dabei sollten Sie darauf achten, das jeder ungefähr gleich viele Elemente bekommt, ein leichtes Ungleichgewicht ist aber völlig normal und durchaus kein Problem.

Keine Diskussionen

​Während des Vorgangs der Priorisierung darf nicht gesprochen werden. Dafür müssen Sie - wie eingangs erwähnt - das Verständnis geschaffen haben. Wenn das nicht etabliert ist, werden Sie hier sehr wahrscheinlich nicht ohne Gspräche auskommen, denn die Klarheit der zu priorisierenden Elemente ist dann nicht gegeben.

​Auslegen der Product Backlog Items

​Zur Bewertung der Product Backlog Items können Sie sich an das folgende Muster halten und immer wieder durchlaufen, bis keine Einträge mehr existieren:

  • ​Der erste Teilnehmer legt seinen Eintrag auf den Boden bzw. die vorbereitete Fläche, auf der die Priorisierung stattfindet.
  • ​Dann folgt der zweite Teilnehmer, der als erste entscheiden muss, ob sein Eintrag wichtiger (dann legt er in oberhalb des existierenden Eintrages ab) oder weniger wichtig (dann legt er ihn unterhalb des existierenden Eintrags ab).
  • ​Der nächste Teilnehmer darf dann seine Einträge entweder ganz nach oben (ganz wichtig), ganz nach unten (wenig wichtig) oder irgendwo zwischen zwei liegende Element platzieren. Wichtig dabei ist, dass er abgesehen von seinem Element keine Reihenfolge ändern darf.

Verändern der Reihenfolge

​Wenn alle Product Backlog Items liegen, dann dürfen die Teilnehmer auch die Reihenfolge der einzelnen Elemente verändern. Dabei darf immer nur ein Element zur gleichen Zeit umgelegt werden. Die anderen Teilnehmer verfolgen das aktiv.

​Wenn ein Eintrag umgelegt wird - was jedem Teilnehmer zusteht - bekommt dieses Element eine Markierung. Wenn eine Karte drei Punkte bekommen hat, dann ist sie zunächst einmal aus der Bewertung zu nehmen.

​Abschluss der Priorisierung

​Es wird nach einer gewissen Zeit Ruhe einkehren. Die Teilnehmer haben sich damit auf eine gewisse Priorisierung geeinigt.

​Das ist ein sehr natürlicher Prozess, der sich automatisch einstellt. Hier bedarf es in der Regel kaum Eingriffe. Lassen Sie trotzem eine Zeit laufen und kommunizieren, wie lange die Teilnehmer sich die Zeit nehmen dürfen.

​Umgang mit entfernten Elementen

​Wenn Sie in der Priorisierung ein oder mehr Elemente bekommen, die drei Striche bekommen, müssen Sie diese im Nachgang besprechen. Dazu können Sie diese dann im Plemnun durchsprechen. Dabei können grundsätzlich zwei Dinge passiert sein

  • Das Element ist inhaltlich nicht verstanden. Dann müssen Sie das Element besprechen und den Inhalt der Karte klären. Da hilft oft schon die Diskussion in der Gruppe mit den Personen, die am Umlegen beteiligt waren.
  • ​Eine Einigung der Reihenfolge ist nicht möglich. Wenn Einträge verstanden sind, aber es zwei oder mehrere Personen sich einfach nicht auf eine Reihenfolge verständigen können, benötigen Sie ebenso eine Klärung im Plenum.
Scrum backlog Item

Magic Estimation

​Mit Magic Estimation können Sie eine große Anzahl von Aufgaben in eine relative Reihenfolge bringen. Was sich zunächst nach wirklicher "Magie" anhört, nutzt beim genaueren Ansehen eine sehr einfache und rudimentär wirksame Prinzipien für eine Ordnung. ​

​Für wen eignet sich der Artikel?

​Der Artikel ist für Sie dann interessant, wenn Sie zu den folgenden Personengruppen gehören:

  • ​Agiler Coach
  • ​Scrum Master
  • ​Product Owner
  • ​Entwicklungsteam

​und ein Interesse an schnellem agilem Schätzen haben. Aber auch wenn Sie nur ein reines Interesse an der Thematik haben, können Sie sich so in Magic Estimation einlesen. Sie brauchen kein fachliches Wissen, der genannten Rollen (aber es hilft).

​Wann Sie Magic Estimation nutzen können

​Die folgenden Fragestellungen sind für Magic Estimation typisch - fragen Sie sich einmal, ob diese bei Ihnen auf zutreffen:

  • ​​Haben Sie ein größeres Backlog, dass Sie bislang noch nicht mit Story Points abgeschätzt haben? ​
  • ​Haben Sie viele neue Product Backlog Items, die Sie abschätzen müssen?
  • ​Sie müssen irgendwas einfach schnell und relativ schätzen?

​Magic Estimation macht es einfach, große Mengen an Product Backlog Items zu schätzen. Das ist gerade für Teams immer wieder nötig, die irgendwann mit Scrum beginnen, aber schon viele Einträge aus der vorherigen Zeit mitbringen und diese aber nicht im geschätzten Zustand vorliegen.

Magic Estimation

​Vorbereitung von Magic Estimation

​Fibonacci-Reihe

​Die gute (angepasste) Fibonacci-Reihe, die in Scrum Projekten häufig zum Einsatz kommt, wird auch für Magic Estimation verwendet. Für die Vorbereitung sollten Sie:

  • ​Ein Set an Planning Poker Karten bereitstellen
  • ​Die Fibonacci-Reihe auf Klebezettel oder Karteikarten vorbereiten

​Product Backlog Items auf Karten bringen

​Sie wollen alle Product Backlog Items (PBI) schätzen? Dann benötigen Sie auch alle PBI's auf Zetteln. ​Drucken Sie also Ihre ganzen PBI's aus oder schreiben Sie diese einfach auf die Zettel, wenn es nicht zu viele sind.

​Klarheit der Product Backlog Einträge

​Die Product Backlog Einträge sollten allen Personen inhaltlich verständlich sein. Wenn Sie diese Voraussetzung nicht haben, dann werden Sie zu deutlich mehr Gesprächsbedarf im Termin tendieren.

​Festlegen einer Referenzstory

​Magic Estimation setzt auf die relative Schätzung, genau wie Planning Poker auch. Es ist immer wichtig zu wissen, gegen was man was in ​Relation setzt. Wenn diese Basis nicht gegeben ist, dann versteht jeder etwas anderes und ist dann auch in den Schätzungen nicht in der Lage etwas in Relation zu setzen.

​Ablauf von Magic Estimation

​Um einen erfolgreichen Ablauf von Magic Estimation zu erreichen, bieten sich die folgenden Punkte als Checks an, die in der Regel zu einer erfolgreichen Schätzung führen.

​Es wird nicht gesprochen

​Bei Magic Estimation wird nicht gesprochen. Jedenfalls nicht, während des eigentlichen Aktes, diese Karten auszulegen. Das ist aus meiner Sicht sinnvoll, aber nur möglich, wenn klar ist, welche Bedeutung die einzelnen Einträge inhaltlich haben.

​Verteilen der Einträge

​Die Einträge aus dem Backlog werden zufällig und möglichst gleichmäßig an alle Beteiligten verteilt.

​Schätzen der Einträge

​Jeder Teilnehmer schaut sich seine Product Backlog Items an und schätzt diese in Relation zu den anderen. Dabei legt er seine Schätzung dann genau zu einem Zahlenwert. Es werden keine Zwischenwerte benutzt, es gelten bei Magic Estimation eben nur die aus der genannten Fibonacci-Reihe.

​Zu diesem Zeitpunkt erlaube ich noch kein umlegen der einzelnen Werte. Ich finde es immer wichtig, dass alle mit dem einen fertig sind, bevor einige schon mit der nächsten Aufgabe starten wollen.

​Verändern der ​Schätzungen

​Wenn alle Product Backlog Items gelegt worden sind, dann ist es an der Zeit, sich einmal alle Einträge anzusehen und zu überprüfen, ob man mit der Schätzung der anderen einverstanden ist.

​Das funktioniert in der Regel dann gut, wenn wie oben beschrieben, die Referenzstory klar und verständlich war. Hier darf jeder sich ein paar Minuten Zeit nehmen und in Ruhe die PBI's ansehen.

​Jetzt besteht die Möglichkeit für jeden Einzelnen die Schätzungen zu verändern

  • ​Wenn jemand der Meinung ist, dass eine Schätzung nicht zutrifft, dann kann er diese einfach umlegen und muss das auch nicht begründen. Dabei markiert er die Karte mit einem Strich oder Punkt.
  • ​Wenn eine Karte drei Punkte bekommen hat, dann wird diese aus der Schätzung genommen und muss seperat diskutiert werden. Hier ist das Verständnis scheinbar noch überhaupt nicht klar.

​Das Ende von Magic Estimation

​Magic Estimation ist beendet, wenn ​sich keine Karten mehr bewegen und die Teilnehmer mit der Reihenfolge zufrieden sind.

​Sollten Sie jetzt noch Product Backlog Items haben, die nicht zugeordnet werden konnten und mit drei Strichen herausgenommen wurden, müssen Sie diese noch klären. Dabei beachten Sie bitte die folgenden Punkte:

  • ​Sie sollten ​unklare Karten sofort klären. Sprechen Sie offen die PBI's mit drei Strichen an. Durch eine genauere Schätzung (z.B. mit Planning Poker) oder oft nur eine kurze Diskussion, können Sie die PBI's dann doch einsortieren - konsolidiert mit allen.
  • ​​Wenn Unklarheiten bleiben. Wenn eine Karte auch nach Diskussion und ggf. Nachschätzen mit Planning Poker zu keinem Ergebnis kommt, dann müssen Sie die Karte durch den Product Owner klären lassen Scheinbar ​fehlen hier noch die Informationen.
Scrum backlog Item

Release Planung

​In diesem Artikel zeige ich Ihnen, wie man die Release Planung in Scrum behandeln kann. Interessanter Weise denken viele Personen, dass diese zwingend notwendig ist. Ist sie aber nicht und ich möchte dazu auch ein wenig mit den Vorurteilen und falschen Annahmen zur Release Planung in Scrum aufräumen.

​Was ist ein Release?

​Als ein Release verstehen wir eine Version einer Software. Wenn wir also eine fertige, veröffentlichte Version einer Software ​erzeugt haben, dann bezeichnen wir diese als Release. Diese Version ist dann in der Regel immer für einen Kunden - wo auch immer der angesiedelt ist - verfügbar.

​Release Planung in Scrum

Release Planung in Scrum

​Im Folgenden gehe ich nur auf die Möglichkeiten der Release Planung in Scrum ein. ​Dabei werden wir zum einen ein Blick darauf werfen, wann wir diese Release Planung überhaupt brauchen. Zum anderen schauen wir uns genau an, welche Möglichkeiten Sie in Scrum haben, um eine Release Planung durchzuführen.

​Scrum braucht keine Releases

​Grundsätzlich braucht Scrum keine Releases. Scrum hat den Anspruch in jedem Sprint etwas zu entwickeln, wobei der Nutzen die Kosten übersteigt. Wenn das so ist, können wir im Sprint Review überprüfen, in wie weit das dem Kunden zusagen, überlegen ob wir Anpassungen vornehmen wollen und dann in die nächste Runde gehen.

Das ist zum einen nicht immer ​realistisch, wenn Sie Ihre Integrations- und Deployment-Strategien nicht soweit entwickelt haben, dass das möglich ist. Zum anderen müssen Sie nicht zwangsläufig Software entwickeln, sondern können auch Scrum in der Hardware oder anderen Bereichen benutzen. Es gibt also durchaus die Situationen, in denen Sie sich mit einer Release Planung in Scrum auseinander zusetzen.

Wenn wir es besonders einfach ​betrachten wollen, dann finden Sie in meinem Artikel agil und Lean übertrieben einfach einen ersten Ansatz, sich dem Thema zu nähern. Je ungewisser die ​Rahmenbedingungen sind bei Ihnen sind, desto mehr sollten Sie auf schnelle Releases Wert legen, nur so können Sie das Risiko verringern, das auf einem unebständigen Markt existert.

​​Hohe Anforderungen, wenn der Sprint das Release ist

​Wer pro Sprint immer der Mehrwert an den Kunden liefern ​kann, ist gut dran. Viele Unternehmen und Teams ​befinden sich noch lange nicht auf so einer Ebene. Deswegen kann man den Gedanken der Release Planung (mindestens als Übergang) weiterführen.

Bedenken Sie, dass Sie praktisch in einem Sprint alles das machen müssen, um wirklich eine fertige, getestete und releaste Version zu erzeugen. Ja, das ist eigentlich nichts neues in Scrum, aber viele Teams sind da schlicht noch nicht. Das muss nicht schlimm sein, aber das ist grundlegend das Ziel von Scrum.

​Wann Sie doch eine Release Planung in Scrum benötigen

​Wie im vorherigen Absatz besprochen, brauchen Sie wenigstens dann eine Release Planung, wenn Sie eben nicht in der Lage sind, jeden Sprint eine vollständige Version zu erzeugen. Dann benötigt der Product Owner einen Überblick, wann und wie er mögliche Releases an den Kunden ausliefern kann. Zudem muss der Product Owner nicht jeden Sprint releasen.

Wenn Sie ​diese Szenarien haben und abdecken wollen, dann können und müssen Sie sich über eine Release Planung Gedanken machen.

​Release nach Zeit

​Oft haben Sie als Product Owner ein zeitliches Ziel. Sie können also einen Termin, wann die Version verfügbar sein soll, nicht verschieben. Zum Beispiel weil der Kunde etwas auf einer Messe zeigen möchte und deshalb die Software oder das Produkt, das Sie entwickeln, nicht später nutzen kann, als zu einem bestimmten Termin.

​Nutzen Sie Ihr abgeschätzes Backlog, das bereits D.E.E.P. sein sollte, dann haben Sie die Schätzungen für alle Einträge bereits vorliegen. Ansonsten können Sie mit agilem Schätzen diese Einträge ​nachträglich noch entsprechen bewerten und in eine Reihenfolge bringen.

​Jetzt brauchen Sie nur folgendes zu tun, um eine erste Prognose zu bekommen. Sie schauen sich an, wann Ihr zeitliches Ziel erreicht sein muss und wieviele Sprints Sie bis dahin noch durchführen werden. Danach schauen Sie sich die Velocity des Teams pro Sprint an. Jetzt können Sie die Anzahl der Sprints einfach mit der Velocity (Durchschnitt) multiplizieren und Sie bekommen eine Zahl an z.B. Story Points, die Sie in der Zeit erledigen können.

​Jetzt gehen Sie Ihr Backlog einfach von oben nach unten durch und addieren die Schätzungen. Irgendwann haben Sie den zuvor ausgerechneten Umfang erreicht und wissen, was Sie bis zu diesem Datum noch schaffen.

​​Beispiel für die Release Planung mit zeitlicher Komponente

​Sie haben eine mittlere Velocity von 50 Punkten pro Sprint. Ihre Deadline liegt noch 10 Sprints in der Zukunft. Sie können damit 500 Punkte an Funktionalität liefern.

​Jetzt gehen Sie Ihr Backlog von oben nach unten durch und zählen die Schätzungen zusammen. Bei spätestens 500 Punkten sollten Sie sichh überlegen, ob diese Funktionalitäten noch erreicht werden können.

​Release nach Umfang

​Wenn der Umfang bereits feststeht, der unbedingt geliefert werden muss, dann können Sie ähnlich wie bei dem Umfang mit der Zeit, zunächst einmal Ihre Velocity ausrechnen. Dann wissen Sie, welchen Umfang Sie bereits benötigen. Ausgehend von diesen Daten sind Sie nun in der Lage den Umfang durch die Velocity pro Sprint zu teilen und dann wissen Sie, wie lange (Anzahl der Sprints) Sie für den Umfang benötigen.

​​Beispiel für die Release Planung mit Umfang

​Sie haben einen Backlog mit einem geschätzen Umfang von 500 Punkten. Ihr mittlere Velocity liegt bei 50 Punkten pro Sprint. ​Sie teilen die 500 Punkte durch 50 und wissen, dass Sie 10 Sprints dafür benötigen werden.

​Typische Grundursachen, wenn Sie Releases benötigen​

​In den letzen Jahren durfte ich ettliche Teams beobachten und ich finde es immer wieder interessant neue Tatsachen zu lernen. Ebenso ist es spannend, dass häufig immer gleiche oder ähnliche Grundursachen in den Teams und den Unternehmen stecken. Diese Grundursachen hinsichtlich der Release Planung in Scrum, schaue ich mir nun in den folgenden Abschnitt zum Abschluss noch einmal genauer an.

Die folgenden Punkte sind als kleine Impulse gedacht und nicht abschließend betrachtet. Nehmen Sie diese bitte als Gedankenanstoß.

​Team ist kein wirkliches Team

​Wenn Sie eine Release Planung brauchen, dann prüfen Sie doch einmal genau Ihr Teamsetting. Also ist das Team wirklich ein Team? Kann es sich eine Aufgabe aus dem Backlog nehmen und diese von Anfang bis Ende durchgehen bearbeiten?

​Aufgaben werden nicht fertig

​Schaffen Sie es zum Ende des Sprints wirklich ein Inkrement zu erstellen? Sind die Aufgaben für die Fertigstellung gedacht?

​Falscher Teamschnitt

​Wenn Sie Featureteams besitzen und mit diesen wirklich das Backlog abarbeiten, dann haben Sie eine gute Ausgangsbasis. Häufig finden sich Strukturen in Teams, die genau das nicht erlauben. Hier finden viele Übergaben, und weitere Verschwendungsarten, innerhalb des Teams statt.

Nicht selten werden Teams um das doppelte schneller, nur weil die jetzt zusammensitzen und eben genau das früher nicht getan haben. Es benötigt nicht unbedingt viel, aber das richtige Team mit den richtigen Leute am gleichen Platz ist auch für die Release Planung in Scrum sehr wichtig.

Backlog und Sprint Backlog Vorlage (analog!)

​Backlog Vorlage

​Eine Frage aus meiner täglichen Praxis ist: "gibt es eine Backlog Vorlage?". Natürlich gibt es diese! Während die meisten aber eine ​digitale Vorlage in Form von Excel & Co suchen, gehe ich hier den Weg einer analogen Backlog Vorlage ein. Im folgenden Artikel finden Sie sowohl die Backlog Vorlage zum herunterladen, als auch eine textuelle Beschreibung sowie eine Erklärung dazu in Wort & Bild als Video. Mit dieser Backlog Vorlage kommen Sie schnell vom (Product) Backlog über das Sprint Backlog zum Inkrement.

Backlog Vorlage
Backlog Vorlage

​Wobei die Backlog Vorlage hilft

​Nicht selten geht es darum nach einem Workshop schnell die ersten Aufgaben in eine passende Form zu bringen. Man hat sich für Scrum entschieden (oder ein sehr ähnliches Vorgehen) und möchte mit einem Backlog arbeiten (relativer Priorisierung) und dann das Team entscheiden lassen, was und wieviel es schaffen kann. Und diese Arbeit soll dann transparent gemacht werden. Mit 4 DIN A0 Blättern schafft meine Backlog Vorlage genau das.

​Die Backlog Vorlage zum Download

​Vorbereitung

​Sie benötigen für das Backlog einmal eine bestimmte Größe von Post-It's und einmal den Ausdruck. Dann sollten Sie noch überlegen, wie Sie das Backlog fixieren können. Dabei bieten sich entweder Tesa Power Strips an, Tesafilm oder Malerkrepp an.

​Backlog Vorlage - Material


​Produkt

​Beschreibung

​Bezugsquelle

Die Tesa Power Strips (oft reichen auch noch die Poster Strips) eignen sich immer dann besonders, wenn Sie Ihr Product Backlog so aufhängen wollen, dass man die Fixierungspunkte nicht sieht.

​Maler Krepp lässt sich leicht anbringen und leicht wieder entfernen. Gerade für temporäre Anbringungen perfekt geeignet!

​Tesafilm sollte man mit Bedacht einsetzen, diesen bekommen Sie nämlich so ohne Probleme oft nicht mehr von Ihrer Backlog Vorlage ab. Trotzdem hilft Tesafilm extrem bei der Fixierung an der Wand. Beachten Sie aber auch immer den Untergrund. Nicht überall hält Tesafilm und da die Backlog Vorlage auf A0 doch etwas Gewicht hat, kann die Schwerkraft siegen.

​​Ich habe die unterschiedlichsten Klebezettel verwendet und ausprobiert. Die Post-It's halten sehr gut und funktionieren mit meiner Backlog Vorlage optimal. Die Klebezettel benötigen für die Backlog Vorlage die Größe 152 x 101 mm.

Das sind die kleinen Klebezettel, die für die Aufgaben in der Backlog Vorlage nötig sind.

​Die großen Post-It's sind ideal wenn Sie auf der Backlog Vorlage "Product Backlog Items" aufnehmen wollen. Die Größe von 203 x 152 mm ist ideal um alle wichtigen Dinge zu fixieren.

​So wird die Vorlage für das Backlog verwendet

​Zunächst einmal, müssen Sie sich die Vorlage herunterladen. Untenstehend sehen Sie die einzelnen vier Blätter der Backlog Vorlage. Laden Sie sich bitte jedes Blatt herunter und drucken das ​auf A0 aus. Dabei hängen Sie Blatt 1 und Blatt 2 nebeneinander. Blatt 3 und Blatt 4 direkt darunter, so dass Blatt 1 über Blatt 3 hängt und Blatt 2 über Blatt 4.

Backlog Vorlage DIN A0 1
Backlog Vorlage DIN A0 2
Backlog Vorlage DIN A0 3
Backlog Vorlage DIN A0 4

​Auf dem Blatt 1 und dem Blatt 2 finden Sie alle wichtigen organisatorischen Angaben für den Sprint:

  • Team. Tragen Sie hier den Namen des Teams ein
  • Sprint. Tragen Sie hier den Sprint ein, um den es geht
  • Vision. Hier steht die Vision für Ihr Produkt
  • Sprint Ziel. Das ändert sich von Sprint zu Sprint und wird gewechselt.

Auf dem Blatt 1 unten links finden Sie das Backlog (das erstreckt sich bis Blatt 3). Durchnummeriert von 1-20 hängen Sie hier als Product Owner Ihre wichtigsten Product Backlog Items auf. Dazu verwenden Sie bitte die oben erwähnten großen Post-It's.

Die selected Backlog Items werden können auf dem Blatt 2 verwaltet werden. Dazu wählt das Entwicklungsteam aus, wieviele Product Backlog Items es benötigt. Zu diesen Einträgen bestimmt das Team dann noch, wie diese konkret umgesetzt werden. Diese hängen dann auf Blatt 2 und Blatt 4.

Auf Blatt 4 können Sie ebenso eine Defintion of Done notieren, die Ihnen hilft zu beschreiben, wann eine Aufgabe wirklich abgeschlossen ist.

​Achten Sie zudem darauf, dass Ihr Backlog immer D.E.E.P. ist und Sie auch die Stories im Sprint priorisieren.

​Die Anleitung zur Befüllung der Backlog Vorlage als Video

​Im folgenden Video zeige ich, wie diese Vorlage für das Backlog genutzt werden kann. Dabei handelt es sich im wesentlichen genau um die gleiche Beschreibung, wie es auch hier textuell nachzulesen ist.

​Backlog Vorlage Verbesserungen

​Haben Sie die Vorlage mal ausprobiert? Was hat Ihhen genützt, was gefehlt?​ Schreiben Sie mir doch gerne einen kleinen Kommentar! 

Stacey Landscape Diagram für Scrum nutzen

​Das Stacey Landscape Diagram für Scrum

​Mit dem Stacey Landscape Diagram ​können Sie die Rahmenbedingungen bei Ihrem Produkt ​in den Fokus nehmen. Das Stacey Landscape Diagram eignet sich hervorragend, um mit Kollegen, Kunden und Teammitgliedern ein gemeinsames Verständnis über die Rahmenbedingungen zu erlangen.

Ich nutze das Stacey Landscape Diagram immer dann, wenn ich zum ersten Mal das Produkt betrachte und mit allen Beteiligten Konsenz über die Rahmenbedingungen bekommen möchte. Auch wenn das Diagramm ursprünglich eine andere Verwendung hatte, so macht es sehr schön deutlich, wann und wo Scrum sinnvoll eingesetzt werden kann.

Stacey Landscape Diagram

Simple, Complicated, Complex, Chaotic

​Im Stacey Landscape Diagram gibt es vier Bereiche, in denen Ihr Produkt landen kann. Je nach Einordnung macht es mehr oder weniger Sinn, dass agile Projektmanagement Framework Scrum zu nutzen. Grundsätzlich nutzen können Sie Scrum immer.

Ist Ihr Produkt im Bereich des komplexen, dann haben Sie die besten Rahmenbedingungen für die Entwicklung eines Produktes mit Scrum. Wenn Sie diesen Bereich nicht treffen, dann muss das nicht zwangsläufig bedeuten, dass Sie Scrum nicht nutzen können. Sie sollten es aber reflektieren!

Anforderungen und Lösungstechnologie

​Das Stacey Landscape Diagram stellt immer eine Relation dar. Und zwar die Relation zwischen Anforderungen und (Lösungs-)technologie. Auf den Achsen finden Sie jeweils die Werte von "klar" bis "unklar" - dabei sind nicht die konkreten Werte ausschlaggebend, sondern es ist eine entstehende Kommunikation über die Parameter des Projektes. Wenn Sie im komplexen Bereich sind, dann benötigen Sie eine iterative und inkrementelle Entwicklung.

Das Stacey Landscape Diagram

Video zum Stacey Landscape Diagram

​In meinen Präsenztrainings und auch in meinen Onlinetrainings verwende ich gerne ​das Stacey Landscape Diagram - ich zeige hier deshalb gerne noch mal eine Zusammenfassung mit Beispielen als Video. So nutze ich das Diagramm gerne und es erschließt sich vor allen den Entwickeln gleich, wie es zu verstehen ist.

​Fazit

​Mit diesen Diagramm haben wir eine sehr schöne und einfache Möglichkeit herauszufinden, ob es Sinn macht, sich für Scrum zu verwenden. Auch wenn das Ergebnis nie schwarz / weiß bzw. richtig / falsch ist, hilft es doch, die Einordnung des Projektes einmal sebst vorzunehmen.

Gerade die Diskussion mit den Kollegen kann an dieser Stelle wertvolle Erkenntnisse und weitere ​Ansichten liefern.

Stacey Landscape Diagram
Stacey Landscape Diagram
Stacey Landscape Diagram
Gute User Stories schreiben Titelbild

User Stories folgen INVEST Kriterien

Gute User Stories sind INVEST

In diesem Artikel befasse ich mich mit einem weiteren Akronym: INVEST. Das Akronym DEEP war für das Backlog und das damit verbundene Backlog Refinement wichtig. Nun geht es um eine Form der sogenannten Product Backlog Items. Und zwar für die User Stories. werfe ich nun auf das Akronym INVEST, welches für User Stories in Scrum eine entscheidende Bedeutung hat.

Independent 

I

Starten wir mit dem Buchstaben I. Independent bedeutet, dass die User Story unabhängig von anderen sein soll. Sie werden mit Sicherheit den Fall entdecken, dass Sie eine Story vor der anderen machen müssen. Vermeiden Sie aber User Stories zu schreiben, in denen Sie zum Beispiel 20 User Stories umsetzen müssen, da Sie sonst bei Problemen im Sprint gar nichts liefern können.

N

Negotiable bedeutet, dass die User Story immer verhandelbar sein muss. Sie ist also nie so ausspezifiziert, dass diese einmal festgelegt wird und dann in die Umsetzung kommt. Die Beschreibung ist bewusst so gewählt, dass schnell und kostengünstig neu über die User Story verhandelt werden kann und diese dann auch neu geschrieben werden kann. Während diese im Product Backlog vorhanden ist, besteht laufend die Möglichkeit diese zu verändern.

V

Value bedeutet, dass die User Story immer einen Mehrwert besitzen muss. Eine User Story ist also nicht Mittel zum Zweck, sondern liefert einen (in sich abgeschlossenen) Mehrwert. Das hilft auch für die Bildung des Inkrements, was am Ende des Sprints zur Verfügung stehen muss. Das berücksichtigen Sie schon bei den Sprint Planung.

E

Estimated bedeutet, dass die User Story eine Schätzung benötigt. Auch wenn sich die Story Points vielerorts durchgesetzt haben, sind diese nach dem Scrum Guide keine Pflicht.

S

Sizeable bedeutet, dass die User Story die richtige Größe besitzen muss. Sie passt also in einen Sprint. Alles was nicht in einen Sprint passt, ist erstmal ein Epic und muss dann weiter zerteilt werden. Das kann im Backlog Refinement durchgeführt werden.

T

Eine gute User Story ist testbar. Das bedeutet, dass diese User Story von einem Tester, Endanwender oder weiteren Stakeholdern getestet werden kann. Dazu gibt es in der Regel Akzeptanzkriterien aus Benutzersicht, damit ein Testen auch möglich ist. Zudem kann der Product Owner so seine Erwartungshaltung an diese User Story ausdrücken.

Sie haben nun die INVEST Kriterien kennengelernt. Wenn Sie sich diese genau betrachten, wenn werden Sie auch erkennen, dass eine agile, interative und inkrementelle Entwicklung nur dann möglich ist, wenn Sie Product Backlog Items entwickeln, die nicht von einander abhängig sind und für sich genommen auch einen Mehrwert liefern. Nutzen Sie Ihr Backlog Refinement zur Verbesserung Ihrer Product Backlog Items.

Abseits von den User Stories können Sie INVEST aber auch zur grundsätzlichen Reflexion Ihrer Product Backlog Items nutzen.

Retrospektive Titelbild

15 Minuten Retrospektive Format

15 Minuten Retrospektive

Die 15 Minuten Retrospektive ist durch Zufall entstanden und ich habe sie mehr oder weniger spontan ausprobiert und entwickelt. Dabei ging es nicht um das Framework Scrum selbst, es wurde aber trotzdem eine Reflexion auf einen gelebten Zeitabschnitt durchgeführt. Bei der 15 Minuten Retrospektive müssen Sie natürlich noch fokussierter arbeiten als sonst auch und können kurz und knackig Themen abfragen und Auswertungen analysieren.

Was braucht es?

Zur Durchführung braucht es nicht viel, aber die Vorbereitung muss gut geplant sein, damit auch keine Zeit verschwendet wird.

  • Alle Teilnehmer müssen pünktlich in einem Raum anwesend sein
  • Stehend oder U-Bestuhlung ist vorteilhaft
  • Klebezettel, Stifte und ein Flipchart bereitstellen
  • Uhr / Handy / Wecker um die Zeit zu nehmen (besonders wichtig)

Mehr benötigt es an Vorbereitung und Materialien nicht.

Wie funktioniert die 15 Minuten Retrospektive?

Für die eigentliche Retro können Sie sich die folgenden Fragen überlegen.

  • Handzeichen: Wer kann mir von euch sagen, was ihr aus der letzten Retro erfolgreich umgesetzt habt (wenn es eine vorherige Retro gegeben hat)?
  • Handzeichen: Wer hat Lust etwas neues umzusetzen?

Bei dieser Frage geht es hauptsächlich um “Set the stage“, die Frage sollte schnell und ohne langes Nachdenken durchgeführt werden können. Eine positive Formulieren erhöht die Chancen der Handzeichen. Mit ein bisschen Übung lässt sich aber auch bei der 15 Minuten Retrospektive der ein oder andere Hinweis schon ableiten. Der Moderator kann sich an dieser Stelle gut überlegen, was im Rückblick wichtig ist und was er beantwortet haben möchte. Die Frage kann ein gutes Stimmungsbild liefern. Das sollte keine Minute dauern.

Sparen Sie! 10 statt 30 Euro für die Retrospektive in 30 Minuten - mein Kurs!

Die Kernfrage (gather data)

Danach gibt es eine Frage, für die die Teilnehmer drei Minuten Zeit haben.

  • Was ist dein aktuell größtes Problem (aus der letzten Iteration, wenn vorhanden), das auch noch existiert.

Das beantworten die Teilnehmer indem sie die Antwort auf Ihre Zettel schreiben. Der Moderator bereitet (wenn nicht schon geschehen) das Flipchart vor, in dem er die fertigen Probleme der Teilnehmer aufnimmt und diese auf die linke Seite klebt. In der Regel werden nicht so viele Punkte in drei Minuten genannt und es passiert auch, dass Themen doppelt genannt werden. Der Platz sollte je nach Klebezettelgröße auch ausreichen (es ist auch legitim, wenn jemand nichts schreiben möchte oder schlicht kein Problem hat!).

Die Detallierung und konkrete Aufgaben (generate insights)

Im nächsten Schritt hängen diese Zettel untereinander auf der linken Seite des Flipcharts. Jetzt folgt die Frage

  • was jeder Teilnehmer sich als kleine Aufgabe zur Lösung eines oder mehrerer Probleme vorstellen kann, die er in der nächsten Iteration umsetzen möchte.

Diese Aufgaben sollten mit Namenskürzel oder Avatar versehen werden, um eine Zuordnung zu erleichtern. Dafür kann man acht Minuten spendieren. Die Zettel werden dann auf die rechte Seite zum korrespondieren Problem gehängt, praktisch die Aufgaben zur User Story aus dem Sprint Planning.

Abschluss (close retrospective)

Nach Ablauf der Zeit, gerne auch schon vorher, findet allerdings keine Priorisierung oder Vergemeinschaftung statt. Es geht bei dieser Form der Retrospektive darum, auf konkrete Aufgaben zu fokussieren, die jeder Teilnehmer umsetzen möchte. Damit priorisiert der Mitarbeiter selbst. Dann fordert der Moderator auf, die entsprechenden Aufgaben mit in den Sprint zu nehmen. Wie die einzelnen Teilnehmer das machen und umsetzen, sollten diesen überlassen werden: es ist Selbstorganisation!

Was am Ende noch passieren kann:

  • Es werden nicht alle Karten abgehängt
  • Es besteht noch Bedarf zur Diskussion

Im ersten Fall bin ich recht schmerzfrei, solange jeder etwas mitgenommen hat und sich beim Betrachten des Flipcharts dann vielleicht doch gedacht hat, es sei zu viel, soll die entsprechende Karte hängen bleiben. Niemand muss eine Karte schreiben oder zwangsläufig mitnehmen, wenn er oder sie meint, es sei zeitlich nicht möglich.

Meistens werden die Personen, die konkrete Karten schreiben dazu tendieren, eine Karte mitzunehmen. Wer noch Diskussionsbedarf hat, der kann die letzten zwei oder drei Minuten – je nach Verlauf – zur freien Verfügbarkeit nutzen. Es kann zum Beispiel auch schnell im Rausgehen eine Feedback-Door als Stimmungsbild genutzt werden.

Agiles Schätzen

Agiles Schätzen

Agiles Schätzen

Agiles Schätzen wird – wie der Name vermuten lässt – in agilen Projekten, die zum Beispiel mit Scrum durchgeführt werden, verwendet. Schätzen ist ein wichtiger Bestandteil vom Projektmanagement, nicht nur in agilen Projekten. Agiles Schätzen hat aber einige Besonderheiten auf die ich in diesem Artikel genauer eingehe. Wir werden uns ebenso die Vertreter des agilen Schätzen ansehen.

Wenn Sie agiles Schätzen durchführen, kommen Sie recht schnell mit dem Vergleich zwischen Aufwand und Komplexität in Berührung. Sie sollen jetzt plötzlich nicht mehr den Aufwand schätzen, sondern ein abstraktes Maß, namens Komplexität! Wenn Sie sich mit dem Thema etwas länger beschäftigen, stellen Sie bestimmt auch fest, dass das Maß Komplexität nicht so ganz einfach ist.

Agiles Schätzen und die später vorgestellten Methoden funktionieren übrigens immer dann gut, wenn Sie mit einem cross-funktionales Team arbeiten.

Das Team rechnet in Aufwand

Aufwand ist etwas, das wir tagtäglich schätzen: Wie lange dauert es, bis wir die Kinder vom Kindergarten abgeholt haben, wie viel Zeit benötigen wir wohl, bis wir unsere Einkaufsliste abgearbeitet und aus dem Supermarkt zurück sind. Schaffen wir es noch pünktlich zum Endspiel nach Hause?

Diese Schätzungen sind recht einfach und lassen sich in Stunden (oder einer anderen Zeitangabe) wunderbar ausdrücken. Natürlich nutzen wir intuitiv auch so etwas für unsere Arbeit. Ich brauche 3 Sunden, um das Konzept zu schreiben, bestimmt nur 30 Minuten die neue Klasse zu implementieren und für die Inbetriebnahme der Hardware braucht der Klaus bestimmt gute zwei Wochen.

Jetzt stellen wir fest, dass meine Frau immer länger für das Holen der Kinder benötigt als ich. Der Klaus komischerweise immer doppelt so lange an Zeit für die Inbetriebnahme der Hardware benötigt als ich, und man in 30 Minuten doch nie diese Klasse implementiert haben kann. Warum ist das so?

Ganz einfach: Meine Frau hält immer noch ein Schwätzchen mit der Erzieherin im Kindergarten, die Klasse kann man nur in 30 Minuten schaffen, wenn man zu den besten seiner Programmiersprache gehört und der Klaus ist einfach noch nicht lange im Unternehmen, will nicht falsch machen und macht deshalb alles sehr gewissenhaft – und das dauert einfach.

Wir haben teilweise sehr hohe Schwankungen in den Schätzungen, weil der Aufwand immer personenbezogen ist und jeder seine Erfahrungen und Erlebnisse mit in diese Aufwandsschätzungen interpretiert. Das hat die unangenehme Eigenschaft, dass wir zum einen nur auf Basis der schätzenden Person Aussagen machen können und zum anderen sind diese Schätzungen nicht belastbar.

Der Grundgedanke der Komplexität

Agiles Schätzen und KomplexitätDa der Aufwand – wie wir eben gelernt haben – personenbezogen ist und teilweise sehr stark variieren kann, führen wir doch einfach ein abstraktes Schätzmaß ein, dass agiles Schätzen erleichtert: die Komplexität. Nun, zuerst kommt die Frage, was die Komplexität denn nun sei. Welche Faktoren spielen in eine Komplexität hinein? Die Komplexität ist dummerweise nicht so ganz einfach und jedes Teammitglied kommt damit sofort klar.

Nehmen wir den Weg in den Kindergarten. Lassen wir die personenbezogene Erfahrung einmal weg. Was kann also die Komplexität des Kindergartenweges beeinflussen? Wie können meine Frau und ich auf die gleiche Komplexität (nicht Aufwand) kommen? Wir könnten zum Beispiel die Wahl des Verkehrsmittel berücksichtigen (ein Auto zu bedienen ist komplexer als zu Fuß zu gehen), mögliche Weghindernisse (zum Beispiel Ampeln), etc. Wenn wir noch keinen Referenzpunkt haben (siehe weiter unten) dann könnten wir nun sagen, für die Komplexität Kindergarten vergeben wir die 2. Jetzt sehen wir uns das Einkaufen an und bestimmen die Komplexität relativ gegen diesen Wert und würden zum Beispiel zu einer 5 gelangen.

Wenn wir uns nachher entscheiden, wer die Aufgabe wirklich macht, nutzen wir personenbezogene Schätzungen, die auch in Stunden sein können. Auf dieser abstrakten Ebene (die nachher die Product Backlog Ebene zum Beispiel sein kann) wollen wir das aber nicht nicht tun.

Klar sollte auch sein, die Komplexität ist eine teambezogene Größe und immer abhängig vom Team.

Komplexität und Aufwand korrelieren teilweise

Nehmen wir an, Sie haben eine hohe Komplexität für eine Funktionalität bestimmt. Was glauben Sie, was das Team als Aufwand schätzen wird? Er wird hoch sein, haben Sie eine geringe Komplexität, dann wir der Aufwand geringer sein. Selten sind die Fälle, das eine sehr komplexe Aufgabe mit wenig Aufwand zu lösen ist. Irgendwo steckt also inhärent der Aufwand auch in der Komplexität, spätestens dann, wenn Sie sich an die Arbeit machen.

Wir werden später noch sehen: es muss nicht immer die Komplexität sein, es lassen sich auch andere “Werte” ganz ausgezeichnet benutzen.

Agiles Schätzen: die Prinzipien

Wir befolgen für agiles Schätzen einige Prinzipien, die das agile Schätzen vom klassischen Aufwandsschätzen unterscheiden.

Agiles Schätzen Geschwindigkeit

Geschwindigkeit

Agiles Schätzen lebt von der Geschwindigkeit. Dazu muss die verwendete Technik besonders schnell sein, gerade wenn wir Product Backlog Einträge abschätzen wollen. Es geht darum, schnell zu sein und keine Zeit in unnötige Planungen zu investieren.

Scrum Werte - Commitment

Zusammenarbeit

Agiles Schätzen basiert auf einer gemeinsamen Zusammenarbeit. Das Team schätzt gemeinsam und es geht nicht darum, einzelne Mitglieder zu blamieren.

Agiles Schätzen Relativ

Relatives Schätzen

Agiles Schätzen basiert nicht auf dem absoluten Aufwand, sondern immer zu einem Referenzwert und alle weiteren Schätzungen findet relativ zu diesem statt. Wir können sehr schnell sagen, ob A komplexer ist als B – ob A aber 10 Stunden oder 11 Stunden dauert ist schwierig – und das wollen wir hier auch noch gar nicht wissen!

KonstanzKonstanz

Komplexität ändert sich nicht über die Laufzeit. Ein sehr komplexes Feature ist immer komplex. Auch kurz vor dem Ende. Ein Aufwand muss über die Laufzeit des Projektes angepasst werden und nimmt

agiles Schätzen Objektivität

Objektivität

Komplexität lässt gleich zu Beginn die Individuen außen vor. Es hilft sich auf das Wichtige zu konzentrieren und nicht indirekt in Aufwand zu denken.

Agiles Schätzen: die Methoden

Planning Poker

Agiles Schätzen mit Planning PokerPlanning Poker ist bestimmt eine, wenn nicht die, bekannteste Methode um agiles Schätzen durchzuführen. Dabei gibt es pro Teammitglied einen Satz “Poker-Karten”. Das sind in der Regel Karten, die eine leicht geänderte Fibbonacci-Folge aufgedruckt haben. Je größer die Zahlen werden, desto größer wird auch der Abstand zwischen diesen. Der Abstand zwischen 1 und 2 ist Faktor 2, wenn wir und die nächsten Zahlen ansehen, haben wir 2 und 5 – hier ist der Faktor nicht mehr doppelt so groß, sondern schon “etwas mehr”.

agiles Schätzen: Planning Poker

Je weiter wir dann und von kleinen Zahlen wegbewegen, desto größer wird auch der Unsicherheitsfaktor im Schätzen (siehe auch Cone of Uncertainty). Der wirkliche Benefit von Planning Poker ist in meinen Augen der Konsens des Entwicklungsteams. Denn es wird im Team ein Product Backlog Item geschätzt (verdeckte Karten jedes Mitglieds) und dann wird gemeinsam auf die ausgewählten Werte der Teammitglieder geschaut, wenn alle gleichzeitig die Werte umdrehen. Wer den höchsten und den niedrigsten Wert geschätzt hatte, erläutern Ihre Argumente. Dann wird erneut geschätzt – das ganze i.d.R. drei mal. Es ist überraschend, wie schnell Konsens herrscht.

T-Shirt Größen

Agiles Schätzen: T-Shirt GrößenDas Schätzen mit T-Shirt-Größen eignet sich besonders für Teams, die gerade mit dem Schätzen starten. Es ist neben dem Planning Poker und Magic Estimation eine sehr verbreitete Art der relativen Schätzung für agile Teams, um das Product Backlog abzuschätzen.

Hier werden zum Beispiel S,M,L und XL als Größen festgelegt und diese stehen dann für die Komplexität / Größe für Aufgaben. Bei den T-Shirt Größen einigt sich das Team auf eine Referenzstory und schätzt dann alle anderen Werte dagegen. T-Shirt Größen funktionieren immer dann sehr gut, wenn Sie analog mit einem Backlog / Board arbeiten. Nutzen Sie digitale Tools, sollten Sie ein Blick auf das Werkzeug werfen: sind hier Eingaben von T-Shirt Größen möglich?

Das Schöne an T-Shirt Größen ist, das diese jeder im Team und in der Organisation kennt. Jeder hat schon mal ein T-Shirt angehabt und kennt sich mit den Größen aus. Indirekt werden diese Größen umgerechnet. Das ist faktisch auch das, was immer bei solchen Ansätzen probiert wird. T-Shirt Größen und Story Points können so hin und her gerechnet werden. Ein schönes Beispiel für Erfahrungen mit T-Shirt Größen finden Sie auf diesen Seiten.

Infografik agiles Schätzen T-Shirt

Agiles Schätzen bei T-Shirt Größen ist vom Vorgehen einfach: Zuerst wird sich das zu schätzende PBI angesehen und vom Team gemeinsam nach Abstimmung einer dieser Größen zugeordnet. Dabei ist darauf zu achten, dass alle “Zwischengrößen” in die nächste Größe einsortiert werden. Das kann und sollte in der Regel im Refinement geschehen, bei dem es auch der Product Owner vorstellt. Da das agile Schätzen aber schnell ist, können einzelne Elemente auch noch im Sprint Planning geschätzt werden.

agiles Schätzen T-Shirt Größe

Die Velocity bekommen Sie natürlich nur dann heraus, wenn Sie in irgendeiner Art und Weise die T-Shirt Größen mit Werten belegen. Es ist schwer zu argumentieren, wir schaffen 3xS, 4xM und 1xL im Sprint. Folglich gibt es direkt oder auch indirekt das Umrechnen in Werte. Zum Beispiel bekommt M dann eine 5 und so wird dann die Velocity bestimmt.

Magic Estimation

Mit Magic Estimation können größere Backlogs mit mehreren Parteien schnell geschätzt werden. Es eignet sich daher ideal zu Beginn eines Projektes, wenn noch keine Schätzungen vorliegen. Von Magic Estimation gibt es verschiedene Varianten. Meine bevorzugte ist die, dass die Planning Poker Karten ausgelegt werden, am besten auf dem Boden. Dann werden die zu schätzenden Product Backlog Einträge (PBI) verteilt und von den Personen zu den (aus deren Sicht) korrespondierenden Story Points gelegt.

agiles Schätzen: Magic Estimation

Nicht jeder wird jeder Zuordnung zustimmen und folglich darf dann auch eine Karte umgelegt werden. Wird das getan, bekommt diese Karte dann eine Markierung (zum Beispiel einen Punkt). Ähnlich wie beim Planung Poker werden dann nur diese PBI besprochen.

Agiles Schätzen: meine Erfahrungen

Meine Erfahrungen agiles SchätzenFür mich stellt sich immer eine Frage: Was nützt es dem Team? Mit dieser Fragestellung gehe ich gerne in Retrospektiven, frage mich das bei Scrumeinführung und spreche in Kaffeeküchen gerne mit Mitarbeitern, die agiles Schätzen anwenden, es wollen oder sich einfach nur dazu einen Vortrag von mir angehört haben.

Eine Grundtendenz gibt es immer: Komplexität ist sehr schwer zu begreifen! Relativität stellt sich recht schnell ein und von der Schnelligkeit sind nicht wenig Teams regelrecht begeistert! Agiles Schätzen funktioniert bei – ich erwähnte es zu Beginn schon – cross-funktionalen Team sehr gut. Je weniger Teams interdisziplinär sind, desto mehr ist die Vorliebe für den Aufwand vorhanden.

Für mich ist das Ausprobieren und Experimentieren ein sehr wichtiger Teil von Scrum. Gerade zu Beginn, wenn Teams existieren die noch nicht “richtig” geschnitten sind.

Einige Teams bevorzugen, ab einer bestimmten Größe – zum Beispiel 20 Story Points – diese Story nicht mehr in den Sprint zu nehmen. Die Aussage ist dann in der Regel “das passe nicht mehr hinein”. Schaut man sich diese Situationen genau an, dann ist diese Schätzung auch keine Komplexität, sondern ein umgerechneter Aufwand. Wenn wir wirklich mit einer Komplexität argumentieren, kann es aber durch vorkommen, dass eine höhere Komplexität mit weniger Aufwand zu erledigen ist und damit auch in den Sprint passen würde. Das ist das aus meiner Sicht nicht schlimm, grundsätzlich finde ich es egal, was vom Team geschätzt wird – Hauptsache es geht schnell und ist relativ. Konkrete Techniken, die keinen Mehrwert bringen werden in einer Retrospektive betrachtet und verbessert.

Ich halte es praktisch: Womit kann das Team gut und schnell arbeiten? Wie kann die Schätzung schnell durchgeführt werden? Ist die Komplexität das Richtige, Ideale Mann-Tage oder eine Normwoche? Das kann unter den jeweiligen Rahmenbedingungen durchaus Sinn machen. Also auch hier: Augen auf, gesunden Menschenverstand einschalten und in Retrospektiven regelmäßig prüfen, ob es den Anforderungen an agiles Schätzen genügt!

>
This website stores some user agent data. These data are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to opt-out of any future tracking, a cookie will be set up in your browser to remember this choice for one year. I Agree, Deny
578