Category Archives for "Scrum Artefakte"

1 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!
1 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. ​

5 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.

4 Scrum Artefakte Product Backlog Sprint Backlog Inkrement

Product Backlog – 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.