Category Archives for "Scrum Artefakte"

Definition of Ready

Definition of Done – so geht es!

Definition of Done - echte Agilität

Mit der Definition of Done beschreiben wir, was vorhanden sein muss, damit ein Eintrag aus dem Product Backlog als fertig gelten darf. Alles was zur professionellen (Produkt)Entwicklung dazugehört, gehört auch in die Definition of Done.

Am Ende eines Sprints wird ein Inkrement erstellt. Es ist inkrementell aufgebaut und enthält damit alles neue, was zum letzten Inkrement hinzugekommen ist.

Dieses Inkrement kann dann (möglicherweise) ausgeliefert werden. Es ist also nicht zwingend für die Auslieferung vorgesehen, aber der Product Owner kann genau das tun, wenn er es für nötig hält.

So wird schnell klar: Wenn Sie Ihre Definition of Done immer erreichen, dann haben Sie die Möglichkeit jederzeit am Ende eines Sprints sich Feedback vom Kunden einzuholen, durch Lernen sich zu verbessern und haben eine sehr hohe Transparenz über den Projektfortschritt. Sie können Ihr Inkrement somit immer vorzeigen. ​

Ziel der Definiton of Done

Die Definition of Done sorgt für ein gemeinsames Verständnis was aus Sicht der Organisation und des Entwicklungsteam vorhanden sein muss, um gute Produkte zu entwickeln. Das hat positive Auswirkungen auf

  • check
    die​ Reduzierung vom Produktrisiko. Denn wenn Sie durch die Definition of Done regelmäßig etwas ausliefern können, dann erlebt der Kunde häufig den Fortschritt des Produktes. Sie lernen und verstehen die Erwartungshaltung und das hilft wiederum das Risiko, das falsche Produkt zu entwickeln, zu senken.
  • check
    ​die Flexibilität auf Produktebene. Wenn wirklich alles "done" ist, was Sie fertig haben und sie es ausliefern können, dann bewahren Sie sich Flexibilität auf Unternehmensebene, auf Unvorhersehbares zu reagieren und zwar zu jeder Zeit!
  • check
    ​die Maximierung des Kundenwertes. Denn nur, wenn Sie fertiges liefern, kann der Kunde lernen und Erfahrungen machen. Den erkennbaren Wert können Sie so optimieren!

Auf diese drei elementaren Vorteile der Definition of Done gehe ich im Folgenden nun einmal genauer ein. Dabei beschreibe dabei meine Sicht und Erfahrungen.​ Ebenso werden wir uns ansehen, was es mit unterschiedlichen Ebenen der Definition of Done auf sich hat und wie so eine Definition of Done aussehen kann.

Defintion of Done

Die Definition of Done (kurz DoD) ist ein Standardwerkzeug, das jedes Scrum Team besitzen muss. Es beschreibt, wann ein Eintrag aus dem Backlog (Product Backlog Item) als fertig angesehen werden kann. Und das gilt für alle Product Backlog Einträge.

Definition of Done

Beispiele für die Definiton of Done?

Um zu einer guten eigenen Definition of Done zu gelangen können Beispiele helfen. Einfache Möglichkeiten für die Definition of Done sind:

  • check
    ​Alle Akzeptanzkriterien sind erfüllt
  • check
    ​Code / Produkt Review wurde erfolgreich durchgeführt
  • check
    ​Entwicklungsrichlinien / Coding Guidelines sind eingehalten
  • check
    ​Es ist kein kritischer Fehler bekannt

Das Beispiel einer Definition of Done hängt sehr stark an Ihrem konkreten Produkt, das Sie entwickeln. Die Defintion of Done für Software Produkte ist anders als für Hardware Produkte. Und wieder anders für Prozessentwicklung.

Den konkreten Inhalt für Ihre Definition of Done müssen Sie, also Ihr Product Owner und Ihr Entwicklungsteam finden. Das Entwicklungsteam sollte hier federführend den Ton angeben, auch Scrum Master oder Product Owner können aber mit zusätzlichen Input helfen. Wie wir unten noch sehen, kommt der Impuls und die erste Vorgabe für die Definition of Done aus der Organisation.

Das Aufstellen der Definition of Done ist eine Diskussion und keine Übernahme einer "best practice". ​Haben Sie dabei bitte immer ein potentiell auslieferbares Produktinkrement vor Augen und überlegen, was Sie dafür benötigen.

Reduzierung des Risikos

Wenn Sie in klassischen Projekten gearbeitet, diese vielleicht sogar gemanagt oder es nur von Kollegen gehört haben: je länger das Projekt läuft und je näher die Abgabe des Projektes / Produktes kommt, desto höher steigt das Risiko. Wird die Integration klappen? Integrieren wir jetzt das Richtige? Kann der Kunde das erleben, was wir liefern?

Das Risiko aus Produktsicht kann nur klein gehalten werden, wenn Sie in kleinen Schritten überprüfen, ob...

Risiko ohne Definition of Done
  • check
    ​das Produkt lauffähig / erlebbar ist und
  • check
    ​den Kundenwünschen entspricht

Alles andere erhöht das Risiko. Das heißt nicht, dass andere Projekte nicht auch erfolgreiche Produkte entwickeln können, je mehr wir das Risiko aber unter Kontrolle haben wollen, desto mehr benötigen wir die Reduzierung des Risikos durch ein Inkrement, dass einer guten Definition of Done folgt.

Im folgenden Bild wird kein Inkrement erzeugt. Wenn der Product Owner ausliefern will, weiß er nicht was passiert. Bisher sind alle Inkremente im Blindflug, ob und wie ein Inkrement funktioniert, kann nicht bestimmt werden.​ Der Grund kann eine fehlende / falsche Definition of Done sein.

Definition of Done - undone work

Flexibilität

Wenn Sie flexibel sein und sich dem schnell wechselnden Markt stellen wollen, dann hilft Ihnen dafür nur ein Inkrement, dass einer eindeutigen Defintion of Done folgt.

Definition of Done bringt Flexibilität

Nur wenn Sie nach einer Auslieferung die Möglichkeit haben, eine andere Richtung einzuschlagen, dann haben Sie eine wirkliche Flexibilität im Markt. Und genau das schaffen Sie nur, wenn Sie ein Inkrement erzeugen, das auslieferbar ist. Und genau deshalb ist dieses Inkrement auch so entscheidend und wichtig. Um zu diesem Inkrement zu kommen, benötigen Sie die gute Definition of Done.

Deshalb ist es an dieser Stelle wichtig, zum einen natürlich den Markt genau zu kennen. Also welches Produkt in welchem Umfeld entwickeln Sie bzw. welches Problem lösen Sie.

In Relation dazu müssen Sie wissen, was können Sie alles in die Definition of Done aufnehmen​.

Maximierung des Kundenwerts

Egal wie gut Sie planen, egal wie viel Arbeit Sie im Vorfeld in der Erhebung der Kundenanforderungen stecken, die wirkliche Akzeptanz und den Erfolg sehen Sie erst dann, wenn der Kunde das Produkt in den Händen hält und eine Aussage darüber treffen kann. Er erlebt es. Nur wenn er es erlebt, damit seine Erfahrungen machen kann und letztendlich so lernt, können Sie sich an diesem Ergebnis orientieren!

Und genau das hilft - als einzige Möglichkeit - den Kundenwert nachhaltig zu maximieren.

Die Definition of Done kommt aus der Organisation

Die Definition of Done aus Organisationssicht

Wer erstellt innerhalb der Organisation diese Definition of Done? Diese wird durch die Organisation vorgegeben und von den Teams übernommen (und ggf. noch erweitert). Warum wird die Definition of Done durch die Organisation vorgegeben? Diese Frage kann man sich stellen, denn irgendwie liegt die Vermutung nahe, das macht doch das Team mit dem Product Owner!

Entwicklungsteam und Product Owner helfen in der Praxis

Ganz falsch ist die Idee mit dem Product Onwer und dem Entwicklungsteam nicht. Wenn die Organisation keinerlei Vorgaben macht, springt das Entwicklungsteam ein und fertig die Definition of Done an.

Ich mache es in der Praxis gerne so, dass in die Erstellung der Definition of Done alle eingebunden sind. Der Ansatz nach möglichst großer Zusammenarbeit funktioniert in reifen Organisationen mit etablierten und guten Teams hervorragend. Sie müssen in Ihrer Organisation abwägen, ob diese Möglichkeit bei Ihnen ebenso funktioniert. Der Fokus liegt auf einer breiten, existierende Erfahrung in Ihrem Unternehmen.

Organisationsanforderungen in der Definition of Done

Typische Themen, die in so einer Definition of Done stehen können, sind zum Beispiel Teile von Normen. Wenn ein Unternehmen im Bereich von existierenden Normen entwickelt, dann müssen oft für alle Produkte solche Normen auch eingehalten werden. Das kann sich damit direkt auf die Definition von "fertiger Arbeit" durchschlagen.

Entwickeln Organisationen unterschiedliche Produkte, dann ist es oft so, dass alle diese Produkte Normen einhalten müssen und zusätzlich produktspezifische Anforderungen haben, die in der Definition of Done festgehalten werden.

Die Definition of Done lebt!

Die Defintion of Done ist kein statisches Artefakt in Scrum. Es wird erwartet, dass sich mit wachsender Reife des Teams und dem Beherrschen von mehr Techniken und Werkzeugen auch die Definition of Done verbessert.

Im Sprint Planning wird die Definition of Done überprüft

Es gibt ein Event in Scrum, in dem diese Definition of Done überprüft wird. Und das ist das Sprint Planning. Hier haben Sie als Team in der Regel weitere wertvolle Erkenntnisse (zum Beispiel aus der Retrospektive) gewonnen, wie Sie sich verbessern können.

Im Sprint Planning entscheiden Sie dann, ob für den aktuellen Sprint die bisherige Definition of Done noch Gültigkeit hat oder ob Sie hier noch eine Anpassung ermöglichen.

Level of Done

Im Gegensatz zur Definition of Done gibt es noch das Level of Done. Das Level of Done wird immer dann wichtig, wenn Sie aus Organisationssicht nicht in der Lage sind, sofort ein potentiell auslieferbares Produktinkremement zu erstellen. Das kann unterschiedliche und z.B. physikalische Gründe haben. Verlassen wir die reine Softwareentwicklung. Wenn wir ein Produkt haben, in dem wir überwiegend nur Hardware erstellen, dann kann ​nicht immer die Hardware nach jedem Sprint releasefertig sein. Beachten Sie aber immer: nach jedem Sprint erzeugen Sie trotzdem Wert für den Kunden und es ist auch etwas "erlebbares" vorhanden. Beispiele für unterschiedliche "Level":

  • check
    ​Die Hardware funktioniert am Aufsteller am Platz des Entwicklers, eingebunden in die Umgebung ohne zum Beispiel auf bestimmte Bussysteme im Auto zurückzugreifen.
  • check
    ​Die Hardware funktioniert in einem Kontext mit anderer Hardware. Das können verschiedene Komponenten sein, die miteinander interagieren.
  • check
    ​Die Hardware ist im Systemverbund testbar und unter realen Einsatzbedingungen nutzbar.

​Achten Sie aber bitte ganz genau darauf, ob Sie dieses Level of Done nicht eigentlich dafür nutzen wollen, etwas wegzulassen. Tests wegzulassen macht kein Sinn und verkennt auch den Sinn des Level of Done.

LoD & DoD: Der Scrum Master hilft

Wenig überraschend, da es sich um prozessuale Abläufe handelt, treibt der Scrum Master auch hier die Verbesserung in der Organisation.

Fazit zur Definition on Done

Es ist mit Sicherheit nicht leicht, eine Definition of Done zu erzeugen, die ein potentiell auslieferbares Produktinkrement erzeugt. ​Nur wenn Sie von letzterem eine gutes Verständnis und eine Beschreibung haben, werden Sie ersteres überhaupt erzeugen können.

Damit das wirklich gut funktioniert, müssen Sie im Bereich der Software ein gutes Integrationskonzept haben. Tests müssen automatisch laufen können, oft eben auch auf Systemebene.​ Continuous Integration gehört dazu - ohne solche Unterstützung werden Sie kaum eine gute agile Entwicklung hinbekommen.

Eine gute Definition of Done zu haben, ist nicht alleine aus Sicht von Scrum wichtig: ​​Wenn Sie nicht wissen unter welchen Bedingungen ​Ihre Arbeit als "fertig" angesehen werden kann, laufen Sie grundsätzlich in Produktprobleme​.

2 Das Produktinkrement in Scrum

Das Done Inkrement

Was ist das Inkrement in Scrum?

In Scrum sprechen wir von einem Inkrement, wenn wir die Summe aller umgesetzten Product Backlog Items, die während eines Sprint umgesetzt werden, betrachten. Dazu kommt noch der bereits erzeugte Wert der vorherigen Inkremente aus allen Sprint. 

Haben Sie nur einen Sprint durchgeführt, dann ist das Inkrement genau nur die umgesetzten Product Backlog Items aus diesem Sprint. Das gilt bereits für den ersten Sprint. Haben Sie mehrere Sprints erfolgreich hinter sich gebracht, dann sind es ebenso die bisherigen Inkremente (inkrementell = aufeinander aufbauend).

In meinem Beitrag agil und lean übertrieben einfach habe ich das folgende Bild verwendet und finde es gerade für das Inkrement sehr passend.

Done Inkrement - agil und lean einfach

Nur dieses ​Done Inkrement erlaubt es Ihnen in Scrum die Flexibilität und höchste Kundenzufriedenheit zu erreichen, die es benötigt, um komplexe Produkte zu entwickeln.

Inkrement bei Tesla

​Beziehen wir uns noch einmal konkret auf den angesprochenen Wert. Ein sehr früher "Wert" für den Kunden kann zum Beispiel "nur" sein, wie stark der Kunde etwas annimmt oder darauf reagiert. Wenn ich in einer ersten Vision und später auch Version es schaffe Kunden zu begeistern, reicht als Inkrement mit Sicherheit eine Webseite mit der Eingabe meiner Kredikartennummer für eine Reservierungsgebühr. Bei Tesla kann man das sehr schön sehen und es funktioniert immer wieder.

Dieses "Inkrement" ist jetzt in dem eigentlichen Sinne natürlich keine inkrementelle Entwicklung, denn die weiteren Inkremente bauen nicht auf der Webseite auf, schließlich wollen wir ja irgendwann das Auto selbst besitzen und fahren. ​Legen wir ​hingegen den Fokus noch mal auf den eigentlich Wert des Kunden, dann sehen wir, dass die folgenden Inkremente natürlich aufeinader aufbauen.

In sofern ist es wichtig zu verstehen was das Inkrement ist und den notwendigen Blickwinkel dafür auch einzunehmen.

Inkrement bei ​Dropbox

​Wenn wir den Geschichten von Eric Ries Lean Start-Up (siehe unten) Gedanken folgen, dann ist es mit der DropBox nicht ganz so wie mit dem Tesla gewesen, aber der Mechanismus war sehr identisch. Als Inkrement kam hier als erste Version ein Video zu dem Cloudspeicherplatz zum Einsatz und die Möglichkeit sich für den Service per Email zu registrieren. Das war ein super Lead-Magnet und ein sehr schöner Test herauszufinden, ob das Wert für den Kunden erzeugt. Hat es, wie wir heute wissen.

Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen
Preis: 19,99€
Zuletzt aktualisiert am 24.02.2018

Schnell, risikolos und erfolgreich Unternehmen gründenBroschiertes BuchDer Weg zum eigenen Unternehmen ist nie ohne Risiko. Und bis die Firma sich auf dem Markt etabliert hat, dauert es. Wer doch scheitert, verliert in der Regel viel Geld. Genau hier setzt das Konzept von Eric Ries an. Lean Startup heißt seine Methode. Sie ist schnell, ressourcenfreundlich und radikal erfolgsorientiert. Anhand von durchgespielten Szenarien kann man von vornherein die Erfolgsaussichten von Ideen, Produkten und Märkten bestimmen. Und auch während der Gründungphase wird der Stand der Dinge ständig überprüft. Machen, messen, lernen - so funktioniert der permanente Evaluationsprozess. Das spart enorm Zeit, Geld und Ressourcen und bietet die Möglichkeit, spontan den Kurs zu korrigieren. Das Lean-Startup-Tool hat sich schon zigtausenfach in der Praxis bewährt und setzt sich auch in Deutschland immer stärker durch.

Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen
Preis: 19,99€
Zuletzt aktualisiert am 24.02.2018

Schnell, risikolos und erfolgreich Unternehmen gründenBroschiertes BuchDer Weg zum eigenen Unternehmen ist nie ohne Risiko. Und bis die Firma sich auf dem Markt etabliert hat, dauert es. Wer doch scheitert, verliert in der Regel viel Geld. Genau hier setzt das Konzept von Eric Ries an. Lean Startup heißt seine Methode. Sie ist schnell, ressourcenfreundlich und radikal erfolgsorientiert. Anhand von durchgespielten Szenarien kann man von vornherein die Erfolgsaussichten von Ideen, Produkten und Märkten bestimmen. Und auch während der Gründungphase wird der Stand der Dinge ständig überprüft. Machen, messen, lernen - so funktioniert der permanente Evaluationsprozess. Das spart enorm Zeit, Geld und Ressourcen und bietet die Möglichkeit, spontan den Kurs zu korrigieren. Das Lean-Startup-Tool hat sich schon zigtausenfach in der Praxis bewährt und setzt sich auch in Deutschland immer stärker durch.

Was bedeutet Done?

Done bedeutet, dass alles fertig ist, so dass wir die Software oder das Produkt unseren Kunden geben könnten. Das müssen wir nicht tun, und ob wir das tun, entscheidet immer der Product Owner. Es darf aber keinerlei Arbeit mehr über sein, dass diese Features, etc. durch den Kunden erlebbar sind. Alles das was Sie damit erstellen ist potentiell auslieferbar. 

Schafft man das gleich? Eine Done Inkrement ist keine triviale Sache, die alle Teams sofort schaffen. Ebenso das Verständnis darüber zu bekommen sowie gute Product Owner zu besitzen, die befähigt sind, Entscheidungen treffen und das Backlog richtig priorisieren können, sind leider auch nicht überall an der Tagesordnung. Alles das benötigt es aber für ein solches Done Inkrement.

Done Inkrement und agile Prinzipien

Wenn Sie einmal ein done Inkrement erzeugt haben, dann erhöhen Sie automatisch die Transparenz, ein agiles Prinzip. Sie sind damit auch in der Lage früh und regelmäßig etwas zu liefern. Auch das ist ein agiles Prinzip. Ebenso unterstützt ein done Inkrement auch die Inspizierung und Anpassung - auch hier erneut ein agiles Prinzip. Und so lassen sich durchaus weitere Beispiele finden.

Das Inkrement ist ein ganz zentrales und wichtiges Artefakt in Scrum. Viele Teams haben damit Probleme, ​stellen Sie es deshalb bitte immer in den Mittelpunkt!

Wie kommen Sie zum done Inkrement?

Was passiert wenn Sie kein Inkrement erzeugen? Dann sollten Sie dem ganzen Sachverhalt natürlich mit einer Retrospektive auf den Grund gehen. Dabei können Sie unterschiedliche Formate nutzen. Wichtig ist, dass Sie eine durchführen und - wie im 12. agilen Prinzip des agilen Manifestes beschrieben - der Prozess auch angepasst wird. Sonst hilft Ihnen die beste Retrospektive nichts für Ihr Done Inkrement. Das Update des Scrum Guide 2017 zeigt deutlich, dass eine Verbesserung mit in den nächsten Sprint genommen werden muss.

DONE INKREMENT


Wert

Welchen konkreten Wert erzeugen Sie mit Ihrem Inkrement für den Kunden?

Größe

Sie müssen sich über eine passende Größe der Entwicklung im Klaren sein.

Qualität

Das Inkrement muss eine entsprechende Qualität sicherstellen und messbar machen.

​Verständnis

​Klären Sie das Verständnis über das Inkrement und wie sie dieses erreichen.

Was ist Wert für Ihren Kunden?

Der erste Weg zu einem guten Inkrement zu kommen ist es, sich zu überlegen, was der Kunde überhaupt wirklich als Wert empfindet. Dieser Wert muss nicht unbedingt darin begründet sein, dass Sie Software abliefern oder ein Produkt, das erlebt werden kann. Verstehen Sie mehr, was Ihr Kunde damit macht. Verstehen Sie, wie der Kunde damit Wert für sich erzeugt. Wer das ganze Verständnis hat, der wird erfolgreich sein.

Wie bekommen Sie kleine Einheiten zusammen?

Ein wohl sehr wichtiges Element für das Liefern in Sprints ist es in der richtigen Granularität Wert zu erzeugen. Sie schaffen das nur durch ein kontinuierliches Backlog Refinement mit den richtigen Product Ownern. Es hat schon einen Grund, warum die Kapazität für das Refinement nicht gering ausfällt. Kommunikation, und zwar die richtige dazu, ist der Schlüssel.

Wir hören oft, "kleine Einheiten gehen bei uns nicht". Wenn man Jeff Sutherland zuhört oder auch Mike Cohn, dann ist die Antwort klar: "das geht immer". Dinge kleiner zu bekommen, finde ich persönlich oft nicht so schwer, es aber kleiner im Sinne des Wertes, ​der am Ende eines Sprints geliefert werden muss, schon.

Wie schaffen Sie eine ausreichende Qualität?

​Ein Done Inkrement ist qualitätiv hochwertig, wenn Sie wissen, was das überhaupt bedeutet. Während zu Beginn solche Vorgaben fast immer aus der Organisation kommen, kann eine Feinjustierung später im Team getroffen werden. Mit zunehmender Reife wird auch die Definition of Done besser.

Done Inkrement bedeutet lernen

Ein Inkrement, das als wirklich done gilt, bedeutet eine lange Lern- und auch Experimentphase. Dabei werden Sie Techniken und Praktiken ausprobieren müssen. Sie müssen sich nach Wegen umschauen, wie Sie das Inkrement noch schneller, noch besser so entwerfen, dass die Defintion of Done erfolgreich sein kann.

Dummerweise ist das - wie auch agile Prinzipien oder Werte - nicht ein einfaches Copy & Paste. Es ist ein Lernen und ein auf das eigene Team, auf das eigene Produkt anzupassende

2 Das Produktinkrement in Scrum

Hilfe: kein Inkrement?

Das Inkrement

Das Inkrement, potentiell auslieferbares Inkrement oder potential shippable increment hat eine zentrale Bedeutung in Scrum. Die Namen sind oft unterschiedlich gewählt, es geht aber immer um dasselbe. Das Grundlegende hinter diesem Inkrement ist ganz zentral in Scrum und wichtig zu verstehen. Das Inkrement steht in Scrum (spätestens) am Ende des Sprints zur Verfügung und kann im Sprint Review damit gezeigt werden.

Bei diesem Sprint Review können der Product Owner, Stakeholder und andere Personen das Inkrement betrachten und bekommen einen Eindruck über den Fortschritt des Projektes.​ Zudem kann hier das typische und oft genannte "inspect & adapt" aus Produktsicht zum Tragen kommen.

In dem folgenden Video gehe ich auch einige Prinzipien hinter dem Inkrement ein. Wenn Sie kein Inkrement haben, schauen Sie sich bitte das Video an und erarbeiten Sie - zum Beispiel in Retrospektiven - die fehlenden Dinge auf.

Warum ist das Inkrement in Scrum wichtig?

Produktinkrement in Scrum

Das Inkrement in Scrum hilft allen Beteiligten zu erkennen, wie der Fortschritt des Projektes und damit auch des Produktes ist. Sie bekommen zu jedem Inkrement ein Gefühl darüber, wie Anforderungen umgesetzt sind und wie sich diese anfühlen und erleben lassen.

Durch das Inkrement sind Sie überhaupt erst in der Lage inkrementell zu arbeiten!​ Es ist wichtig zu verstehen, dass wir Menschen - also auch der Kunde - erst in der Lage sind ein Produkt, ein Inkrement oder Prototyp dann zu verstehen, wenn er das erste Mal etwas sehen und ausprobieren  und es wahrhaftig erfahren kann.

Das Inkrement ist genau der Teil, der die richtige Agilität ausmacht. Also wendig und flexibel auf dem Markt zu bestehen und sich diesem anzupassen. Nur wenn Sie nach dem Sprint etwas lauffähiges und werterzeugendes abliefern können, dann haben Sie die Möglichkeit überhaupt auf Änderungen am Markt eingehen und reagieren. Es ist damit Ihre Möglichkeit, Einfluss zu nehmen. 

In dem folgenden Bild sehen Sie zwei Teams. Ein Team erzeugt regelmäßig ein Inkrement, das andere nicht. Während ersteres immer die Möglichkeit hat, auf Reaktionen seitens Kunden & Stakeholder einzugehen, fehlt das beim zweiten Team.​ Hier ist eine Rückmeldung nur nach einer bestimmten Anzahl von Inkrements möglich.

Wenn Sie in einem turbulenten Umfeld arbeiten, kann das im schlimmsten Fall nicht ausreichen.​

Woran erkennen Sie, dass Sie kein Inkrement haben?

Die einfache und schnelle Antwort ist, "daran, dass die Arbeit nicht fertig ist". Sie haben es nicht geschafft Ihre Arbeit in ein "done" Inkrement umzusetzen. Oft haben Teams zunächst gar keine richtige Definition of Done oder aber sie ist einfach noch nicht ausreichend.

Letzteres ist ein Inspect & Adapt, dann müssen und sollten Sie sich schnellstens darum kümmern, dass diese Definition of Done passend ist.

Wenn Sie in einem Sprint Review nichts zeigen können, weil Sie zum Beispiel nur ein Design von der Software erstellt haben oder etwas anderes, das für sich genommen nichts an Wert erzeugt, dann bringt Ihnen das im Sinne einer agilen, inkrementellen Entwicklung recht wenig.

Wenn Sie im Unternehmen gefragt werden, wie denn nur der Stand vom Produkt sei und ob Sie mehr Details erläutern können, dann ist das Inkrement ebenso nicht ausreichend.

Woran erkennen Sie, Ihr Inkrement funktioniert?

Ein Inkrement erlaubt es, immer wieder auf einen alten, auslieferbaren und funktionierenden Stand zurück zugehen. Natürlich passiert es mal, dass das nicht immer der Fall ist, aber wenn es die Ausnahme ist, dann ist es eben nicht hilfreich. Schaffen Sie so einen Stand, schaffen Sie auch Inkremente!

Ebenso haben Sie ein recht geringes Risiko, denn nach einem Sprint können Sie einen neuen Weg einschlagen und sich auf den Kunden neu einlassen und neue Wünsche und Anforderungen bearbeiten.

Hilfe, ich habe kein Inkrement!

Scrum Master Schlichter

Nun ist guter Rat in der Regel teuer. Es kann bei Ihnen der Fall sein, dass Sie kein Inkrement erzeugen können oder wollen. Wenn es um das Können geht, dann ist die Sache oft auf technische Infrastruktur zurückzuführen oder bestimmte Fähigkeiten, die fehlen.

Ohne ein Continuous Integration und mit kurzen Sprintzyklen werden Sie wenig Software erzeugen, die lauffähig, getestet und dem Kunden vorgeführt werden kann, erzeugen.

Wenn Sie nicht im Softwarebereich tätig sind, dann müssen Sie sich ebenso die gleichen Fragen stellen. Wenn Sie Prozesse oder Dienstleistungen mit Scrum erstellen, fragen Sie sich immer, was am Ende des Sprints erstellt werden kann, das Wert erzeugt und erlebbar ist.​

Fehlt es Ihnen an Fähigkeiten, dann ist das genau ein Punkt der in der Retrospektive sofort zu erkennen ist. Es fällt auf und das nach einem Sprint. Wenn Sie sich das in einem klassischen Projekt vorstellen, dann kommen solche Dinge typischerweise erst später zum Tragen. Doch auch im Sprint Review sollten hinsichtliches des Produktes schon Probleme angesprochen und ans Tageslicht kommen.

Scrum ist ein hervorragendes Diagnosetool für Ihren Prozess, das gnadenlos alles an die Oberfläche spült, was bei Ihnen nicht funktioniert. Umgehen müssen Sie damit dann selbst und Lösungen finden.​ Kein Inkrement zu haben ist nicht optimal, aber oft im Umfeld normal. Nutzen Sie hier immer die Retrospektiven, um Verbesserungen zu erzielen.

Achten Sie ​beim Sprint Planning direkt darauf, was Sie konkret einplanen. Kann das am Ende dann auch wirklich ein funktionierendes Inkrement werden? Oft kann dieser explizite Schritt schon ein andere Bewusstsein beim Scrum Team fördern.

Typische Antipattern für kein Inkrement in Scrum

  • Wenn der Product Owner oder andere Stakeholder nachfragen, wie ist denn eigentlich der "Stand im Projekt", dann ist das ein Alarmsignal, dass Sie kein Inkrement haben.
  • Sie benötigen mehrere Sprint, um überhaupt etwas zeigen zu können. Kunden, ob intern oder extern, haben lange keine Klarheit, was eigentlich das Produkt macht.
  • Sie suchen nach Möglichkeiten den Sprint zu verlängern, da die Zeit nie ausreicht etwas aaslieferbares zu erstellen.
Kein Inkrement - das sind die Anti-Pattern!
2 Titel Backlog DEEP

Das Product Backlog ist DEEP

Übersicht über das DEEPe Product Backlog

Abstract. In diesem Artikel beschreibe ich Ihnen das Akronym DEEP. Dieses DEEP ist im Zusammenhang mit dem Backlog sehr entscheidend und hilft Ihnen ein gutes Backlog zu erstellen, das sich perfekt im Projekt benutzen lässt.

DEEP steht im englischen für  detailled, emerget, estimated, prioritized,

Das Product Backlog

Ein zentrales Artefakt im Scrum ist das Product Backlog. In diesem Backlog werden alle Anforderungen an ein Produkt oder eine Dienstleistung zusammen getragen. Der Product Owner ist für dieses Artefakt verantwortlich. Er steuert damit das Produkt hinsichtlich Kundennutzen und Wirtschaftlichkeit.

Nur wenn etwas in diesem Product Backlog steht, dann hat es die Chance umgesetzt zu werden. Wenn es nicht in diesem Backlog steht, wird es definitiv nicht umgesetzt.​

Das Product Backlog ist das wichtigste Artefakt für die Anforderungen, die an das Produkt oder die Dienstleistung gestellt werden. Und genau auf diese Wichtigkeit stützt sich auf das Akronym DEEP.​ Wenn Sie DEEP erfüllen, dann hat Ihr Product Backlog eine gute Chance optimal für Ihr Scrum zu funktionieren.

Im Folgenden werfe ich nun gemeinsam mit Ihnen einen Blick auf diese einzelnen Bestandteile des Akronyms DEEP.​

DEEP: Angemessen detailliert

Ein Product Backlog ist immer angemessen detailliert. Doch was genau bedeutet angemessen? Die Frage des Detaillierungsgrades müssen wir in Abhängigkeit der Position im Backlog beantworten. Das Product Backlog ist Ihr Arbeitsvorrat für die Sprints. Das was in den nächsten Sprints bearbeitet werden soll, benötigt einen anderen Detaillierungsgrad, als vage Ideen, die sich am Ende des Backlogs befinden.

DEEP - detailliertes Backlog

Im Backlog Refinement ist es Ihre Aufgabe diesen Detallierungsgrad zu erzeugen. Das spielt oft in die sogenannte Definition of Ready mit hinein. Nur wenn Sie Product Backlog Items bekommen, die angemessen detailliert sind, dann können Sie diese auch in das Sprint Planning gelangen.

DEEP: emergent

Ein Product Backlog ist keine Spezifikation, die einmal zu Beginn geschrieben wird und dann final ist. Das Product Backlog ist lebendig, das bedeutet

  • Es werden neue Product Backlog Items hinzugefügt
  • Bestehende PBI werden entfernt
  • Die Reihenfolge der Product Backlog Items verändert sich
  • ...
DEEP Emergent

Diese Emergenz ist auch gewünscht, denn wir wissen, dass Anforderungen die über eine lange Zeit festgelegt werden, sich definitiv wieder ändern. Wir akzeptieren also die Unbeständigkeit der Anforderungen und versuchen aktiv damit umzugehen. Und aus diesem Grunde muss das Product Backlog auch emergent sein.

DEEP: abgeschätzt (estimated)

Jedes dieser Product Backlog Einträge benötigt eine Schätzung. Zumindest dann, wenn es bald in den nächsten Sprint aufgenommen werden soll. Die Schätzung in Scrum wird in der Regel in einem günstigen Schätzformat ausgedrückt (Story Points). 

Auf der Backlog Ebene ist - im Gegensatz zur Sprint Ebene - die Art der Schätzung eine andere. Während wir auf Backlog Ebene sehr schnell schätzen, ob Product Backlog Einträge in den Sprint gelangen oder nicht, gehen wir im Sprint Backlog dann in die Details, wenn nötig.

Wichtig ist zu verstehen, dass die Schätzungen die wir hier tätigen noch kein Waste sind. Sie sind schnell und trotzdem genau genug.​ Es reicht um festzustellen, ob etwas in den Sprint passt oder nicht.

DEEP: priorisiert

Zu jedem Zeitpunkt ist klar, welches das wichtigste Element im Product Backlog ist. Und das bedeutet, es gibt zu keinem Zeitpunkt zwei wichtige Elemente. Das wird in Scrum mit einer relativen Priorität umgesetzt.

​Relativ bedeutet dabei, das jedes Element (solange es nicht das erste oder letzte ist) immer ein Element hat das wichtiger ist und eines, das weniger wichtig ist. Also immer einen Vorgänger und Nachfolger, wenn Sie es so betrachten wollen. Das erste (und damit wichtigste) hat natürlich kein Element, das wichtiger ist. Und das letzte Element im Backlog keines, das weniger wichtig ist. Für alle anderen Elemente gilt aber genau dieser Sachverhalt.

DEEP Priorisiert

Um noch mal zu klären, warum das so ist und sein muss. Wir rechnen in Scrum immer mit unvorhergesehenen Dingen.​ Es kann also passieren, dass uns das Geld im Projekt ausgeht, es wichtigere Dinge als unser Projekt plötzlich vorgeschoben werden und noch so einige andere unvorhergesehene Dinge. Wenn wir immer genau wissen, was das wichtigste Element ist und wir uns nicht in negativen Multitasking verlieren, dann haben wir eine sehr gute Chance, dass die wichtigen Dinge auch abgeschlossen werden.

Ist das nicht klar und Sie arbeiten an zehn mal der Priorität "top", dann ist nicht klar, mit was gestartet werden soll. Häufig fängt dann ein Team mit allem an und wird mit nichts so richtig fertig.​ Auch hier kann es Ihnen helfen, sich noch mal mit der Priorisierung im Sprint zu befassen!

Deshalb achten Sie immer auf eindeutige Prioritäten!​

Wie wenden Sie DEEP für sich an?

Der Scrum Master kann DEEP nutzen, um zu überprüfen, wie gut der Prozess ist. Dabei fungiert DEEP als eine Art Checkliste und es ist immer gegen diese Liste zu vergleichen. Sie merken in der Regel schnell die Auswirkungen eines schlechten Backlogs. Sind die Einträge nicht detailliert genug, dann entstehen häufige Rückfragen und die Einträge können nicht in den nächsten Sprint gezogen werden.

Sind die Einträge nicht abgeschätzt, dann werden Sie ein langes Sprint Planning 1 bekommen, denn irgendwann müssen Sie schätzen.​ Auch das fällt recht schnell und schmerzhaft auf. Ebenso fehlt Ihnen natürlich die Möglichkeit Ihre Kapazität / Velocity im Sprint zu berechnen.

Ist die Priorität nicht klar, dann kann ein Team auch nicht eindeutig die Stories ziehen und es wird Probleme mit der Wichtigkeit, nicht nur im Backlog sondern auch im Sprint Backlog während des Sprints geben können.​

Doch nicht nur der Scrum Master kann DEEP nutzen, auch der Product Owner sowie das Team finden hier eine praktische Möglichkeit zu reflektieren. ​

7 Das Produktinkrement in Scrum

Das Produktinkrement

Das Produktinkrement

Produktinkrement in ScrumIn Scrum gibt es das Produktinkrement. Ziel eines Sprints in Scrum ist es immer, ein Produktinkrement zu erstellen und damit den Projektfortschritt zu zeigen. Das Produktinkrement hat eine ganz zentrale Bedeutung in der Synchronisation und dem gemeinsamen Verständnis im Projekt! In diesem Artikel beleuchte ich dieses am Ende des Sprints entstehende Produktinkrement genauer und beschreibe, was oft falsch gemacht wird.

Ein solches Inkrement wird im Sprint Review begutachtet. Dabei wird der Fokus auf das Erlebbare gelegt und versucht durch Feedback und Rückmeldung das Produkt (und damit das nächste Inkrement) zu verbessern.

Die Eigenschaften vom Inkrement

Definition of DoneWerfen wir zunächst einen Blick auf das (Produkt)Inkrement und dessen Eigenschaften. Der Name Inkrement lässt es schon vermuten: das Produktinkrement wird inkrementell erstellt und wächst demnach über mehrere Sprints. Inkremente bauen in der Regel aufeinander auf. Sie sind erlebbar und ausführbar. Auch gehört zum Beispiel ein Test zu einem Produktinkrement dazu. Somit ist dieses Produktinkrement immer ein vertikaler Schnitt durch das zu entwickelnde Produkt.

Transparenz, Inspect & Adapt

Produktinkrement - Transparenz, Inspect, AdaptDurch die Eigenschaft, dass Produktinkremente erlebbar sind, fördern sie einen Meilenstein, der auch verlässlich ist. Nur das, was wirklich funktioniert und erlebbar ist, kann bewertet werden. Genau dieser Zustand zeigt den Projektfortschritt! Und genau das steht im Fokus am Ende des Sprints. Scrum basiert sehr stark auf dieser Art der Transparenz und dem dann folgenden Inspect & Adapt.

Alle anderen Messungen helfen nicht, denn Sie zeigen nie, wie es wirklich um das Projekt steht. Dabei muss sich diese Transparenz nicht auf Software beziehen.

Fehler beim Produktinkrement

Immer wieder findet sich die gleiche Problematik bei Produktinkrementen in Scrum. Ich möchte hier auf einige Dinge eingehen, die mir immer wieder in der Laufbahn begegnen. Ich persönlich empfinde diese Produktinkremente als entscheidende Artefakte in Scrum. Wenn das wirklich funktioniert, dann gibt sich der Rest ebenso.

Experiment

Tests sind nicht enthalten

Es wird entwickelt, aber Test sind nicht im Inkrement enthalten. Damit fehlt immer die Aussage, ob das Produktinkrement auch wirklich funktioniert. Im Laufe der Entwicklung bauen sich so technische Schulden und fehlerhafte Inkremente auf, die Qualität sinkt. Test nicht zu tun, bringt letztendlich nie einen Vorteil!

Wir haben nichts zu zeigen

Genauso wenig, wie man einen Bericht für das Management nicht machen würde, genauso wenig darf es sich einschleichen, nichts zu zeigen. Auch wenn Sie nichts zu zeigen haben, dann ist das auch ein Ergebnis und sagt etwas über den Fortschritt aus.

Skalierung Produktinkrement

Skalierung

Während bei einer Entwicklung von einem Team es noch durchaus für den Kunden einmal verfechtbar ist, ein Inkrement zu erleben, scheitert es in skalierten Umgebungen in der Regel schneller. Der Fokus in skalierten Umgebungen muss auf dem Wertstrom und der gesamten Wertschöpfungskette im Unternehmen liegen und nicht nur einem Team. Wenn hier ein Produktinkrement fehlt, steht deutlich mehr auf dem Spiel.

5 Scrum Artefakte Product Backlog Sprint Backlog Inkrement

Product & Sprint Backlog & Inkrement

Die Scrum Artefakte

Die drei Scrum Artefakte spielen nicht nur im Framework eine wichtige Rolle, sondern enthalten alles nötige, was für die Erstellung von komplexe Produkte gebraucht wird. Das Product Backlog, das Sprint Backlog und das Inkrement sind sehr eng miteinander verbunden und harmonieren in diesem Triplett außerordentlich gut.

Scrum Artefakte Product Backlog Sprint Backlog Inkrement

Sie ergänzen sich und füllen sich im Kreislauf mit dem jeweiligen Input. Das Sprint Backlog bekommt Einträge aus dem Product Backlog und das Inkrement ist das Ergebnis des umgesetzten Sprint Backlogs. Anhand des Inkrements kann es wieder neuen Input für das Product Backlog geben. Die Scrum Artefakte spielen hier Hand in Hand auf einer sehr einfachen und auch sehr effektiven Art und Weise.

Das Product Backlog: Die Wunschliste

Scrum Product BacklogDas Product Backlog

Das wichtigste Artefakt für den Product Owner und die einzige Liste im Projekt mit Anforderungen.

Im Product Backlog hat der Kunde zwar oft schon konkrete Vorstellungen, wie sein Produkt aussehen könnte. Aus der Erfahrung wissen wir aber, dass sich das oft auch ändern kann. Hier finden sich erst einmal die Wünsche. Diese Wünsche sind in einem einfachen Format geschrieben. In Scrum setzten wir oft die User Story ein, denn die Formulierung ist immer Sinne der “Aufwandskosten” sehr gering. Das bedeutet, eine User Story ist schnell geschrieben und repräsentiert dann in dem Backlog einen Wunsch aus Sicht des Kunden. Mehr Aufwand hier in die Beschreibung zu stecken lohnt nicht, denn die Frage ist, ob der Wunsch überhaupt so bestehen bleibt, wenn die Zeit fortschreitet.

Je näher wir an die Umsetzung heran kommen, je mehr wir lernen, je mehr wir verstehen über das, was wir entwickeln, desto konkreter und genauer können wir sagen, was wir wollen. Deshalb sind die Einträge im Product Backlog die weit in der Zukunft liegen noch sehr vage, andere schon viel klarer und detaillierter, da die Umsetzung direkt vor der Tür steht.

Das Sprint Backlog: Die Auswahl aus dem Product Backlog

Sprint Backlog
Das Sprint Backlog

Das wichtigste Artefakt für das Team mit dessen ausgewählten und zugesagten Aufgaben für den aktuellen Sprint.

Das Sprint Backlog enthält alles, was als Ergebnis aus dem Planning festgehalten wurde. Das ist die Auswahl der Product Backlog Items, die umgesetzt werden sollen. Diese Anzahl hat das Team gezogen (nach der Priorität des Product Owners) und sich verpflichtet, diese auch im Sprint umzusetzen.

Mit dem Sprint Backlog muss klar sein, ab wann ein Item as umgesetzt gilt. Hier gibt es die Definition of Done – die zwischen Product Owner und Team definiert wurde. Zudem wird auch hier ein Ziel festgelegt. Dieses Ziel beschreibt, was mit den ausgewählten Product Backlog Items erreicht werden soll. Das Ziel findet sich damit auch im Inkrement wieder.

Das Inkrement: das Ergebnis aus dem Sprint

Produktinkrement in Scrum
Das Produktinkrement

Das wichtigste Artefakt für die Stakeholder und das Scrum Team um zu lernen und die Kundenwünsche zu treffen.

Das Inkrement ist ein erster Eindruck von dem zu entwickelnden System. Hier können die Beteiligten alle erkennen, wie weit das Team gekommen ist und wie sich das System bis jetzt anfühlt. Das Inkrement lässt immer eine Reflexion über das aktuelle System zu. Es hilft zu verstehen, wie weit das Produkt ist. Dadurch, dass das Inkement immer ausführbar ist, kann auch direkt wirklich etwas erlebt werden und nicht nur in langweiligen Folien betrachtet werden.

Scrum Artefakte in der Zusammenfassung

Scrum Artefakte Zusammenspiel

Wir haben gesehen, dass die drei Scrum Artefakte gut zusammenspielen und sich ergänzen: Das Product Backlog, das Sprint Backlog und das (Produkt)Inkrement sind notwendige Artefakte, um komplexe Produkte zu entwickeln. Zusammen sind sie sehr effizient und inhärent in Scrum enthalten. Sie hängen alle zusammen und füttern sich gegenseitig mit Input.

>