Category Archives for "Scrum Grundlagen"

Fehler und Stories

Fehler und Stories im Product Backlog?

​Fehler passieren und sind menschlich. Wenig überraschend werden Sie mit der Frage gehören Fehler und Stories eigentlich gemeinsam in ein Product Backlog konfrontiert. Dieser Frage wollen wir uns in diesem Artikel einmal genauer widmen und klären, warum Fehler eigentlich wie Anforderungen zu behandeln sind.

​Grundlagen: Fehler und Stories

​Was ist ein Fehler?

​Ich möchte hier keine wissenschaftliche Definition eines Fehler angehen. Sondern nur soweit festhalten, dass ein Fehler eine Abweichung von einem gewünschten Verhalten ist. Eine vorhandene Forderungen wird nicht so erfüllt, wie wir sie gerne hätten und das bezeichnen wir an dieser Stelle dann als einen Fehler.

Was sind Anforderungen?

​Auch wenn es nach Scrum kein Muss ist, so sind doch die meisten Anforderungen die Benutzer an ein System haben in User Stories festgehalten. User Stories beschreiben Anforderungen an ein System aus Anwendersicht in einem sehr einfach verständlichen Aufbau.

In Scrum sind die Anforderungen immer im Product Backlog, das wissen Sie, wenn Sie regelmäßig hier die Artikel auf dem Blog lesen. Die Anforderungen sind als Product Backlog Items vorhanden und müssen dann durch das Refinement auf eine Reife gebracht werden. Dann kann das Entwicklungsteam diese ​Anforderungen ​in der Sprint Planung auch bearbeiten und planen.

​Da gehören Fehler hin

​Kunde meldet Fehler nach Auslieferung

​Im Grunde sind Fehler nichts weiteres als Anforderungen! Wenn Sie etwas an den Kunden ausgeliefert haben und er der Meinung ist, es gibt einen Fehler, dann muss dieser Fehler priorisiert werden. Damit ​bekommt er eine eindeutige Reihenfolge mit der restlichen Arbeit! Also ab damit ins Product Backlog!

Der Product Owner ist derjenige, der diesen Fehler dann (ggf. in Absprache mit dem Kunden) wieder priorisiert und für den nächsten oder einen späteren Sprint ​von ​dem Entwicklungsteam ziehen lassen kann.

​Fehler, die im Sprint auftreten

​Wenn Fehler im Sprint auftreten, dann halte ich es ganz gerne so, dass diese nicht in das Product Backlog kommen, wohl aber in das Sprint Backlog. Denn diese Fehler gehören direkt zu einem Product Backlog Item, dass Sie gerade bearbeiten. Es ist solange nicht "fertig", bis eben alles fertig ist, damit das Product Backlog Item ​nach der Definition of Done als fertig gelten kann. Wenn Sie die Stories im Sprint priorisiert haben, dann kann ein Fehler somit auch klar einem Product Backlog Item zugeordnet werden und damit wird dann auch sofort die Priorität sichtbar.

Ein Fehler ​kann eine Unterbrechung im Sprint ​darstellen und damit gibt es unterschiedliche Möglichkeiten, wie Sie darauf reagieren können. Als Empfehlung gilt -  egal welche Lösung Sie bevorzugen - dass der Fehler direkt im Sprint behandelt wird.

Scrum backlog Item

Der Scrum Roll-out gelingt nicht!

Der Scrum Roll-out

Wenn eine klassische (hierarchisch, tayloristische) Organisation ​sich auf die Fahnen geschrieben hat, Scrum einzuführen, dann folgt diese Einführung in der Regel einem bestimmten Muster. Dem Muster des sogenannten "Roll-out's".  Ebenso finden sich diese Roll-Out-Gedanken ebenso im Beratungsbereich stark verbreitet.

Das Prinzip ist identisch: Konzept erstellen, Überlegen wie es am besten und schnellsten in die Organisation gebracht werden kann, und dann durchführen. Am Ende: abgeschlossen und alle machen "gutes" Scrum. Auch wenn das Konzept des Roll-Out's bei Wikipedia (Stand Januar 2018) nicht genug mit Belegen untermauert war, findet sich doch dieses Muster sehr oft in Organisationen.

Wer jetzt den Scrum Guide richtig studiert und verstanden hat, sich bewusst ist, was empirische Prozesskontrolle und die Scrum Theorie ​ist, der kommt vielleicht schon auf eine möglich Idee, warum der Scrum Roll-Out nicht so funktionieren kann.

Was ist eigentlich ein Scrum Roll-out genau?

​Der Scrum Roll-out

​Häufig haben Organisationen das Verständnis von einem einmaligen Konzept, einer Durchführungsphase und dann dem Abschluss für ​das ganze ​Unternehmen. Diese Annahme ist grundsätzlich ​gegenläufig zu dem, was die Absicht von Scrum ist.

Zu Beginn wollen wir die Frage klären, was ist eigentlich genau ein Scrum Roll-out​? Scrum als agiles Projektmanagement kennen Sie sehr wahrscheinlich, wenn Sie diesen Blog lesen. Sie finden alle relevanten Informationen dazu auf der Startseite.

Unter einem Roll-out wird das "ausrollen" von unterschiedlichen Dingen, wie zum Beispiel Software verstanden, aber auch organisatorische Dinge, wie neue Methoden oder Frameworks. Der spannende und oft nicht beachtete Teil ist der, dass ein Roll-out in der Regel immer organisationsweit oder mindestens abteilungsweit gemeint ist. Unter einem Roll-out wird praktisch nie eine Einführung in einer kleinen Einheit wie zum Beispiel einem Team verstanden.

Scrum Theorie

​Im Scrum Guide gibt es zu Beginn einen kleinen, aber wichtigen Absatz. Ich möchte mit diesem zur Reflexion beginnen. Der Scrum Guide schreibt zu einem Scrum Roll-out nichts, aber es findet sich die folgende Textpassage.

Scrum Guide 2016

Scrum Guide

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

​Auf die Transparenz, die Inspektion und die Adaption komme ich gleich. Wichtig ist mir in diesem Moment die empirische Prozesskonktrolle. Ich stelle die folgenden Thesen auf und beziehe ich später noch einmal darauf:

  • 1
    ​Wir finden einen wichtigen Hinweis zur Empirie. Als Empirie bezeichnen wir das, was wir erlebt haben, das was wir wissen. Wenn wir Scrum einführen und diese über die ganze Organisation tun wollen, dann nehmen wir an, wir wissen schon genau, wie das zu tun ist. Das ist keine Empirie, das ist Prediktion.
  • 2
    ​Wir treffen zudem die Annahme, dass unsere frühe Entscheidung​ - also das Konzept für den Scrum Roll-out und die Durchführung - richtig war. Wir kennen das natürlich bereits aus anderen Zusammenhängen: Die Welt ist unbeständig und wird sich ändern. Mit Sicherheit also auch die Struktur, die wir für die Organistaion in Zukunft benötigen.
  • 3
    ​Ein Scrum Roll-Out in der angesprochenen Form entspricht ein wenig dem typischen "Big-Bang", den wir gerade ​durch die iterative und inkrementelle Entwicklung ​ versuchen zu vermeiden.
  • 4
    ​Wenn zu Beginn noch nicht sicher ist, wie genau der optimale Wertstrom für den Kunden aussieht und welche Verschwendungsarten existieren, dann haben Sie sehr wahrscheinlich die Situation, diese Probleme in die ganze Organiation zu tragen und zu vermehren.
Building Successful Communities of Practice

​Scrum Theorie

​Transparenz


Scrum benötigt ​ Transparenz, damit das Framework wie gewünscht funktionieren kann. Projektfortschritt und Status der Artefakte muss transparent sein.

​Inspektion


Wenn der gelebte Prozess kontunierliche betrachtet wird, können Abweichungen erkannt und Verbesserungen überhaupt erst abgeleitet werden.

Adaption


​​Wenn der aktuelle Prozess auf Transparenz beruht, er durch Inspektion begutachtet wird, kann eine Adaption in Richtung Verbesserung erfolgen

​Aktuelle Roll-out Gedanken von Organisationen

Ich erlebe im Moment wieder verstärkt Kunden, die mehr in die Explorations- oder Experimentphase eintauchen und sich spezielle Prototpyen für die organisatorische Entwicklung aussuchen. Das entspricht damit natürlich nicht dem klassischen Scrum Roll-out in der gesamten Organisation.

Es entstehen viele Keimzellen, die sich aber auch wiederum nicht auf eine ganze Organisation ausweiten. Das liegt in der Regel daran, das einzelne Bereiche und Abteilungen ohne Wissen der anderen Abteilungen ähnliche Initiativen vorantreiben.

​Wenn wir gedanklich beim Roll-out bleiben: was Sie natürlich immer benötigen ist eine Entscheidung des Managements. Sie müssen dieses einbinden und viel wichtiger noch, das Management muss die Notwendigkeit erkannt haben und unterstützen.

Es ist noch nicht lange her, als sich sowohl die Organisationen selbst, als auch Beratungen auf diese Art von Scrum Roll-out's konzentriert haben.

​Fazit zum Scrum Roll-out

​Wenn Sie unter dem Scrum Roll-out einen experimentellen, empirischen Ansatz sehen, der sich über die Zeit innerhalb der Organisation ausbreitet, dann kann ein dieser gelingen. Machen Sie gleich zu Beginn den Rahmen und die Entfaltungsmöglichkeiten sehr eng, dann werden Sie es sehr schnell, sehr schwer haben.

Wie so oft liegt die Frage für den Erfolg aber im Verständnis des Begriffes Roll-out. Im folgenden finden Sie noch einmal meine Überzeugungen, wann es klappen kann und wann eben eher nicht.

  • ​Verstehen Sie den Roll-out als einen abgegrenzten Teil, den Sie als Prototypen stellvertretend für die Organisation ausprobieren.
  • ​Binden Sie Teams in einen Roll-out ein, lassen Sie diese Erfahrungen und Empfindungen mit einbringen und unterstützen Sie auch den Rückfluss an Informationen.
  • ​Ein Roll-out ist in der Zeit eher kurzfristig, als langfristig. Vermeiden Sie große Initiativen, die kaum Veränderungen und Wert bringen.
  • ​​Betrachtung als ein "one-size-fits-it-all" Ansatz. Sie legen das Konzept im Vorfeld für die ganze Organisation fest und rollen dieses dann "bis zum bitteren Ende" aus.
  • ​​Treffen von Annahmen für andere Teams oder die ganze Organisation, ohne dessen Erfahrungen und Abläufe zu kennen und zu verstehen.
  • ​​Scrum als "Ersatz" für das klassische Projektmanagement sehen: altes raus, neues rein - so scheitern Sie schon mit Ansage.

Scrum: Framework vs. Prozess

​Framework vs. Prozess

​Immer wieder kommt in der Community, den sozialen Medien und Blogs die Frage und Diskussion auf: ist Scrum jetzt ein Prozess, eine Methode, ein Framework? Ist Methode, Methodologie und Methodik das Gleiche? Oder doch ganz verschiedene Dinge?

Gunther Verheyen hat es in einem Blogbeitrag schön zusammengefasst: Scrum ist ein Framework und keine Methodologie! Durch weitere Recherche bin ich dann über die Seite von der Universität in Wien gestolpert, die Methode, Methodik und Methodologie beschreibt. Für mich war Scrum schon immer ein Framework, denn es hat mir nie einen Prozess vorgeschrieben, den ich bis ins Detail folgenden muss, sondern gibt mir einen Rahmen in dem ich mich bewegen kann​!

Deutsche und englische Unterschiede

Die Universität Wien spricht von bei der englischen Sprache von einer doppelten Belegung des englischen Begriffs Methodology. Der englische Begriff der Methodology umfasst Methodik und MethodologieMethodology nutzt auch Gunther Verheyen in seinem Blogbeitrag.

​Warum wir Frameworks brauchen

Bei der Frage Framework vs. Prozess ist für mich nur eines wirklich relevant. Wenn wir in heutigen Zeiten und Ungewissheit Projekte entwicklen, dann stellt sich die Frage, wie wir dieses am besten bewerkstelligen können. Aus meiner Sicht benötigen wir dazu Frameworks. Sie erlauben es uns nämlich, mit Leitplanken auf neue Themen einzugehen ohne uns an konkrete Methoden zu klammern, die wir nutzen müssen. Wir müssen mit emergenten Praktiken arbeiten, anstatt uns an Best Practices festzuhalten, die irgendwann einmal in einem bestimmten Kontext funktioniert haben, es aber nicht in jedem neuen tun.

  • check
    ​In Zeiten von Ungewissheit, benötigen wir Flexibilität und Reaktionsvermögen. Das können wir nicht leisten, wenn wir alles Stück für Stück vorgeben und versuchen es anzuwenden. Peter Drucker sagte einmal sinngemäß: "Das Problem an turbulenten Zeiten ist nicht die turbulente Zeit an sich, sondern das reagieren mit gestriger Logik." Das ​bringt es aus meiner Sicht genau auf den ​Punkt.
  • check
    ​In den Zeiten der Digitalisierung müssen wir den Fokus auf die Wissensarbeit legen.  Alle anderen Jobs und Tätigkeiten werden - wenn es es bei diesem Tätigkeitsprofil möglich ist - digitalisiert. ​Für alles andere brauchen wir ein möglichst großes Maß an Freiheit, Kreativität und Autonomie für die Indiviuen. Das ​können wir nur durch Frameworks erreichen.
  • check
    ​Nur motivierte Indivuen sind wirklich erfolgreich und können sich zu hochperformanten Teams entwickeln. Es schlummer massive Reserven in jedem von uns, die aber gehoben werden müssen. Freiwilligkeit und Motivation sind dabei zentrale Schlüssel. Mit einem Framework können diese Potentiale gehoben werden.


Fazit

Wie so oft ist es eigentlich egal, wie etwas bezeichnet wird, wenn man die dahinter liegenden Prinzipien verstanden hat. Scrum ist aus meiner Sicht kein Prozess, sondern ein Framework. Es gibt einfach kein detailliertes Vorgehen an. Wenn Sie dann Scrum bei sich im Unternehmen, im Team, etc. etablieren, dann wird es konkreter. Oft nähert sich dann das, was Sie dort haben, einem Prozess. Dabei kann es aber sein, dass diese Prozess nicht unbedingt wiederholbar sein muss.

Sie fangen nämlich an auszukleiden, wie Sie zum Beispiel entwickeln. Natürlich können Sie das weiterhin frei lassen und dann bleibt Scrum immer ein Framework. Allerdings neigen viele Unternehmen dazu, so etwas wie Tools festzulegen, konkrete Vorgehen zum Beispiel unter bestimmten Rahmenbedingungen (sicherheitskritische Software) enger zu ziehen. Das ist gut und nötig, die Frage bleibt immer konkret, ob und wenn ja, ab wann es zu einem Prozess wird.

Für mich ist es immer entscheidend wie weit ein Team Dinge selbst entscheiden kann und auch will. Das hat viel mit der Reife eines solchen Teams zu tun. Ich brauche keine umfassende Selbstorganisation, wenn ein Team oder eine Organisationen noch gar nicht so weit ist. In solchen Fällen führt das mehr zu agiler Verwirrung, als das es nützt.

Scrum backlog Item

Akzeptanzkriterien & Definition of Done

​Definition of Done

​Wann Sie eine Definition of Done benötigen

Defintion of Done

Eine Definition of Done gibt an, wann eine Arbeit als fertig gelten kann. Diese Liste an Definition gilt für alle Einträge, die Sie im Sprint bearbeiten. Wollen Sie also ein in der Sprint Planung sich vorgenommenes Product Backlog Item abschließen, dann muss das der Definition of Done entsprechen. Je nachdem was Sie konkret entwickeln kann und ist eine Definition of Done unterschiedlich.

Beispiele für eine Definition of Done 

Die Beispiele für eine Definition of Done sind natürlich sehr unterschiedlich, denn diese hängen davon ab, wie reif Ihr Team zum einen ist und zum anderen natürlich, welches Produkt Sie entwickeln. Im Folgenden finden Sie ein paar Möglichkeiten für eine Definition of Done:

  1. Dokumentation ist vorhanden
  2. Softwareänderungen sind mit  einem Test abgesichert
  3. Änderungen am physikalischen Layout sind der Fokusgruppe vorgestellt

Ich brauche mehrere Definition of Done - was nun?

Nicht selten kommt es vor, dass ein Team der Meinung ist, dass es mehrere Definition of Done benötigt. Weil zum Beispiel Software und Hardware Anteile in einem Produkt sind. Prüfen Sie hier 

  • wie Ihre Stories geschnitten sind (schneiden Sie vielleicht bewusst anhand alter Strukturen?)
  • ob Sie die Definition of Done nicht mehr auf den Wert des Kunden beziehen können, als ihn auf eine Disziplin zu beziehen.

Auch hier kann es - je nach Reife des Teams - durchaus möglich und nötig sein, dass Sie so einen "Zwischenstand" von zwei Definition of Done benötigen.

Akzeptanzkriterien

Akzeptanzkriterien sind sehr mit einzelnen Product Backlog Items verbunden. Insbesondere gibt es die Akzeptanzkriterien bei den User Stories. Sie werden auch Condition of Satisfaction genannt und drücken die Erwartungshaltung des Product Owners gegenüber der User Story aus.

Sie können folglich von Product Backlog Item zu Product Backlog Item unterschiedlich sein. Sie können mehrfach in der Anzahl vorkommen. Passiert es Ihnen, dass die gleichen Akzeptanzkriterien immer wieder auftauchen, überlegen Sie, ob sich daraus nicht etwas für die Definition of Done ableiten lassen.

Wann Sie Akzeptanzkriterien benötigen

Akzeptanzkriterien benötigen Sie als Product Owner, um Ihre Erwartungshaltung auszudrücken. Diese Akzeptanzkriterien ergeben sich mit fortschreitender Zeit. Sie erarbeiten und bearbeiten Ihre Product Backlog Items hinsichtlich Ihrer Erwartungshaltung kontinuierlich im Product Backlog Refinement.

Beispiele für Akzeptanzkriterien 

Schauen wir uns auch für die Akzeptanzkriterien ein paar kurze Beispiele an

  1. Der Benutzer kann mit Kreditkarte bezahlen
  2. Die Antenne kann elektrisch ausgefahren werden
  3. Alle Rollen in der Prozessbeschreibung sind mit der HR Beschreibung verfügbar

Screencast

Im Vergleich: Definition of Done & Akzeptanzkriterien

Der Vergleich


Definition of Done

  1. Kommen initial von der Organisation
  2. Gelten für alle PBI
  3. Liste von Kriterien
  4. "Wann ist die Arbeit fertig"

Akzeptanzkriterien

  1. Kommen überwiegend vom Product Owner
  2. Gelten für einzelne PBI
  3. Liste von Kriterien
  4. "Wann ist die Erwartung erfüllt"
2 Scrum backlog Item

Was sind eigentlich Product Backlog Items

​Das Product Backlog Item

​Ein Product Backlog Item befindet sich im Product Backlog. Es wird auch als Product Backlog Eintrag bezeichnet. Alle​s, ​was sich in einem Product Backlog befindet, bezeichnen wir damit als Product Backlog Items, ungeachtet der Größe.

Eigenschaften von Product Backlog Items

​Product Backlog Items haben Eigenschaften. ​Die folgenden Eigenschaften von Product Backlog Items habe ich in diesem Artikel zusammen gefasst.

Epic & User Story? Die Größe ist egal

Egal welche Größe die Einträge in einem Product Backlog haben. Sie heißen alle Product Backlog Items. Es spielt keine Rolle, ob das eine User Story oder ein Epic ist.

​Product Backlog Items müssen keine User Stories sein

​Auch wenn die User Stories häufig als Product Backlog Items verwendet werden, ist das keine Pflicht! Wenn Sie die User Stories allerdings nutzen wollen, dann achten Sie hier auch die INVEST Kriterien.

Product Backlog Items sind geschätzt

​Alles das, was sich im Product Backlog befindet benötigt eine Abschätzung. Diese Abschätzung wird häufig in Form sogenannter relativer Abschätzungen getroffen, die deutlich schneller als absolute Stundenwerte zu ermitteln sind. Der Scrum Guide macht allerdings keinerlei Vorschriften, wie geschätzt werden soll, nur dass es passieren muss.

Product Backlog Items ​erzeugen inkrementellen Mehrwert

​Die Product Backlog Items beschreiben Produkteigenschaften an dem zu entwickelnden Produkt. Das bedeutet, dass alles das, was an Anforderungen existiert in diesem Backlog steht. Der Mehrwert für den Kunden am Ende eines Sprints steht im Vordergrund.

Die Summe der Product Backlog Items ist die Summe der Anforderungen an das Produkt

​Zu jedem Zeitpunkt stellt die Menge an Arbeit im Prodcuct Backlog genau die Arbeit dar, die bekannt ist, um ein Produkt zu entwickeln. Somit sind alle Product Backlog Items, die sich im Backlog befinden (unbeachtet der aktuellen Größe) als Summe die Menge an Anforderungen, die für das Produkt auch erbracht werden müssen.

​Product Backlog Items können während des Sprints abgenommen werden

​Product Backlog Items ​können jederzeit im Sprint durch durch Product Owner abgenommen werden. Dazu müssen Teammitglieder nicht bis zum Ende des Sprints warten. Je früher ein Feedback gegeben werden kann, desto früher steht auch neue Erkenntnisse zur Verfügung - gerade unter unbeständigen Rahmenbedingungen wertvoll.

Product Backlog Items hängen am Sprint Ziel

​Das Sprint Ziel wird während des Sprint Planning vom Scrum Team erstellt. Das Entwicklungsteam hilft die nötigen Product Backlog Items dafür auszuwählen. Am Ende des Sprints ist es das Ziel, ein "done Inkrement" zu bekommen.

​Product Backlog Items die "done" sind, werden abgenommen

​Bei Product Backlog Items ist der Product Owner die letzte Instanz, die über die Abnahme entscheidet. Es gibt die Definition of Done, die angibt, was alles getan werden muss, damit ein Product Backlog Items als fertig gilt.

​Entspricht so ein Product Backlog Item der Defintion of Done, dann gibt es Feedback auf die Arbeit, das Product Backlog Item kann aber in dem Sinne, nicht abgelehnt werden, denn es wurde bereits alles für die Erfüllung getan. Auch der Scrum Guide gibt in seiner aktuellen und vorherigen Version nichts von einem "Ablehnen" von Product Backlog Items im Sprint Review an.

​D.E.E.P. für Product Backlog Items

​Das Akronym D.E.E.P. für das Backlog habe ich bereits vorgestellt. Ein genauer Blick auf dieses Akronym verrät, dass dieses Akronym sehr auf die Product Backlog Items abzielt. Wie schon oben beschrieben, sind die Backlog Items immer geschätzt.

Die entsprechenden Items müssen auch so detailliert sein, dass die vorne im Product Backlog stehenden Einträge unmittelbar im nächsten Sprint auch benutzt werden können - sie müssen also angemessen detailliert sein.

Ebenso sind die Product Backlog Items immer geschätzt. Diese Schätzung entspricht dem einem "E", wie estimated. Emergent (das andere "E") ist das Backlog und damit auch die Items darin. Diese können nämlich schnell verschwinden, verfeinert werden oder sonst einer Änderung unterliegen.

​Und zum Schluss sind die Product Backlog Items durch die Priorisierung in eine Reihenfolge gebracht - also priorisiert, besser geordent, worden.

​Das Product Backlog Item in der Zusammenfassung

​Das hier vorgestellte Product Backlog Item ist eindeutig und einfach. Es handelt sich um eine einfache Definition, die ausreichend ist, um komplexe Produkte zu entwickeln.

1

Der Scrum Guide 2017 und die Änderungen

Der Scrum Guide 2017

Als ich die Änderungen des Scrum Guide über soziale Medien bemerkt hatte, dachte ich nur - oh schon wieder? Es gab doch erst 2016 ein größeres Update. Nach dem Studieren des Scrum Guide 2017 muss ich sagen, dass die Änderungen sehr hilfreich für alle Teams sind. Jeff Sutherland und Ken Schwaber haben es mal wieder geschafft, die richtigen Änderungen einzufügen, die keine wirklichen großen Änderungen sind, aber die Wichtigkeit und Angemessenheit auf den Punkt bringen. Ich stelle die wichtigen Änderungen und meine Sicht auf diese in dem Artikel vor und freue mich über Diskussionen!

Was ist der Scrum Guide?

Sie kennen den Scrum Guide ​schon? Dann lesen Sie einfach beim nächsten Abschnitt weiter. Für alle anderen ist es wichtig zu wissen, dass der Scrum Guide die "Spielregeln" für Scrum festlegen. Hier ist auf wenigen Seiten das Framework beschrieben, es gibt nach wie vor: 3 Rollen, 3 Artefakte und 3 Events. Den Scrum Guide haben Ken Schwaber und Jeff Sutherland erstellt und aktualisieren diesen auch immer noch weiter. Daraus resultieren dann von Zeit zu Zeit genau die Änderungen, die ich hier beschreibe. Der Scrum Guide 2017 hat sich - wie erwähnt - zwar nicht gravierend geändert, aber es sind erneut Erkenntnisse aus der Erfahrung und Anwendung mit diesem Scrum Guide.

Die Änderungen im Scrum Guide 2017 im Detail

Scrum ist mehr als Software

Jeder kennt die Geschichten zum einen von großen globalen Software Playern, bei denen Scrum zu guten Ergebnissen geführt hat. Weniger bekannt sind oft die Geschichten, in denen es um Dinge geht, die nicht dem Software Bereich entsprungen sind. Der Scrum Guide 2017 räumt damit nun auf. Es gibt nun einen neuen Abschnitt, der sich mit der Anwendung von Scrum  ("Uses of Scrum") befasst. Hier wird jetzt explizit  ausgeführt, dass Scrum auch außerhalb der Software seine Berechtigung und Erfolge hat.

Jeder der sich ein wenig genauer mit Scrum schon befasst hat, kennt das New New Product Development Game. Hier viel das Wort Scrum in Verbindung mit guten Entwicklungsprozessen, die alle nicht Software als Hauptbestandteil hatten!

Erweiterte Definition von Scrum

Während die Definition von Scrum im Scrum Guide 2016 nur "Scrum ist eine Framework zur Entwicklung und Aufrechterhaltung von komplexen Produkten ist" hieß, findet sich im Scrum Guide 2017 die folgende Beschreibung von Scrum: "Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern." Der Purpose, als der Zweck des Scrum Guide, enthält weiterhin die obige Beschreibung, allerdings leicht angepasst "Scrum ist ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte".

Damit rückt der Scrum Guide nun eindeutig weg von der reinen Software Entwicklung, hin zu einem universellen Framework. Für alle die, die Scrum schon immer so gesehen und eingesetzt haben, für die ändert sich nichts. Alle anderen finden hier noch einmal die schriftliche Bestätigung.

Konkretisierung Scrum Master Rolle

Im Scrum Guide 2017 findet sich - ähnlich zur Definition von Scrum - noch eine Erweiterung hinsichtlich der Rolle des Scrum Masters. Auch hier gilt fast ähnlich zum vorherigen Absatz, dass sich die Aufgabe nicht geändert hat. Es wird aber noch einmal der Fokus darauf gelegt, dass es die Aufgabe vom Scrum Master ist, Scrum umzusetzen, es in der Organisation zu treiben. Dafür wird für mich die "Management-Rolle" Scrum Master gestärkt. Nicht oft sehe und höre ich in Organisationen einen Scrum Master, der weder entsprechend befähigt ist, noch sonst eine wirklich Handhabe im Unternehmen hat.

Damit die Scrum Master (hoffentlich) in vielen, vor allem größeren, Organisationen anders wahrgenommen werden bzw. klarer gestellt ist, was deren Aufgabe und Rolle ist, hilft diese Erweiterung für alle die, die diesen Guide lesen.

Die Zeiten für die Events im Scrum Guide 2017

Der Scrum Guide 2017 hilft dem Scrum Master hinsichtlich der Klarstellung von Zeiten der Events in Scrum. So wird jetzt explizit noch einmal herausgestellt, dass es sich um Maximalzeiten handelt. Ein Daily Scrum darf also maximal 15 Minuten dauern, kann aber auch früher beendet werden, wenn das Ziel erreicht ist.

Daily Scrum

Das Daily Scrum ist nun ein Inspect & Adapt Meeting für das Sprint Ziel. Auch das ist genau genommen schon so gewesen. Nun wird es explizit noch einmal herausgehoben. Wie Jeff Sutherland auch in seinem Scrum@Scale Trainings vorstellt - hier ist die Keimzelle für eine Skalierung. Hier wird die Abstimmung der Teams optimiert. Dieses Meeting ist essenziell.

Die Retrospektive bekommt mehr Durchschlagskraft

Wer vor Scrum Guide 2017 Retrospektiven durchgeführt hat und diese auch erfolgreich waren, hat bestimmt das 12. agile Prinzip gut umgesetzt. Darin heißt es unter anderem, dass "(...) das Verhalten entsprechend angepasst wird. (...)". Im Scrum Guide findet sich nun auch der Hinweis, dass diese "Anpassung" auch im Backlog zu finden ist. Konkret heißt das, es gibt ein Backlog Item, dass diese Anpassung auch adressiert.

Das Inkrement und die Wichtigkeit

Was mir persönlich ja immer sehr wichtig ist, ist das Inkrement. Es hängt nun ja so inhärent mit einer iterativen und inkrementellen Entwicklung zusammen, wie nur irgendwas. Ich finde es angemessen, dass diese Wichtigkeit im Scrum Guide 2017 eingeflossen ist.

There is one more thing...

Was mir noch sehr positiv an diversen Stellen auffällt: es geht mehr und mehr weg von den Situationen, dass wir diskutieren müssen, funktioniert Scrum nun in der Software oder Hardware, was ist mit Prozessen, Services oder Innovation. Scrum ist das Ergebnis einer seit 30 Jahren andauernden Studie und der Scrum Guide ist das Ergebnis dieser Studie: an kleinen Elementen merkt man, dass wir zum Beispiel mit "The increment is a step toward a vision or goal." davon weg kommen, ob in einem Hardware Projekt nun am Ende eine neue Hardware auf dem Tisch steht oder nicht.

Scrum: The Art of Doing Twice the Work in Half the Time
Preis: 9,99€
Zuletzt aktualisiert am 24.02.2018

This is the definitive account of the Scrum methodology from its co-creator and the CEO of Scrum, Inc., Jeff Sutherland. Scrum is the revolutionary approach to project management and team building that has helped to transform everything from software companies to the US military to healthcare in major American hospitals. In this major new book its originator, Jeff Sutherland, explains precisely and step by step how it operates - and how it can be made to work for anyone, anywhere. Take the FBI attempt to digitize its records, for example. As with so many software projects the first attempt failed, having taken four years and cost over $400 million. Then the FBI turned to Scrum, and just over a year later unveiled a functioning system that cost less than a tenth of the first project and employed a tenth of the staff. And it's not just grand projects that Scrum can help with. Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed. Filled with practical examples drawn from all types and organisation it will make you rethink the fundamentals of successful management - and show you how to get things done however everyday or ambitious, however small or large your organisation.

Das Inkrement ist immer mehr auf den Wert fokussiert. Auf den Wert des Kunden. Wenn das verinnerlicht ist, dann ist auch eine Skalierung möglich. Wenn nicht, dann wird es hart und Sie skalieren nur Probleme. Eine saubere Scrum Implementierung ist ein Garant und die absolute Basis.

Diese Tendenz finden Sie nun auch zu Beginn des Scrum Guide in dem Beispiele gegeben sind, wo und wie Scrum genutzt werden kann und wurde.

Fazit Scrum Guide 2017

Aus meiner Sicht sind die Anpassungen im Scrum Guide 2017 angemessen und adressieren die richtigen Dinge. Alle die, die Scrum schon länger erfolgreich einsetzen, für die sind die Neuerungen common sense. Für alle anderen eine gute Guidline, um das Ziel Scrum erfolgreich einzusetzen, besser umsetzen zu können. 

1

Meeting Overhead in Scrum reduzieren!?

Meeting Overhead in Scrum

"Wie können wir in Scrum den Meeting Overhead reduzieren?". Wenn ich diese Frage im Scrum-Umfeld bei Kunden höre, bildet sich bei mir schon eine Liste an möglichen Problemen in der Umsetzung des agilen Projektmanagement Framework Scrum.

Kommen Sie aus einer größeren Organisation und sind der Meinung, Overhead von Meetings in Scrum reduzieren zu müssen? Dann helfe ich Ihnen, wie Sie die Scrum Events richtig durchführen. Ich glaube fest daran, dass alle Scrum Events ausreichen, um komplexe Produkte zu entwickeln.

Sie sind der Agilist und der Meinung, das es keinen Overhead von Meetings in Scrum gibt, dann haben Sie ins Schwarze getroffen 🙂 Ich gehe auf das Symptom des Problems im Folgenden genau ein.

Mit "Meeting Overhead" wird folgender Sachverhalt bezeichnet: das Team das Gefühl, nur noch in Meetings zu sitzen und nicht mehr zum Arbeiten zu kommen. Diese Situation des "Meeting Overheads" findet sich nicht nur im agilen Projektmanagement Framework Scrum, sondern ist ein häufiges Problem von Teams und Individuen in Organisationen.

Aus meiner Erfahrung finden sich häufig drei Grundursachen bei Scrum. Ein "Meeting Overhead" entsteht immer dann, wenn...

  • ... Scrum "nebenbei" eingeführt wird und die Teams und Teammitglieder in mehreren Projekten arbeiten. Sie nehmen also mehr als eine Rolle in einem Projekt ein und sind dann überproportional mit Meetings belegt.
  • ... die Umsetzung der Scrum Events nicht richtig gelungen ist. Es werden mehr Meetings benötigt und diese dauern länger als gedacht. Damit sind die Meetings gefühlt und stundentechnisch einfach mehr, als nötig.
  • ... ein typischer "Roll-out" von Scrum in der ganzen Organisation durchgeführt wird. Es gibt keine Zeit für Experimente und alle müssen sich von einem Zeitpunkt x schnell umstellen.

Wieviel Meetings haben wir in Scrum?

Scrum als agiles Projektmanagement hat fünf Events. Davon sind vier typischerweise Meetings. Nehmen wir noch das Backlog Refinement als Meeting dazu, dann haben wir schon alles, was wir brauchen. Diese Meetings brauchen Sie, um Ihr Projekt verwalten und komplexe Produkte entwickeln zu können. Dabei sind alle Aktivitäten zur Verwaltung Ihrer Scrum Implementierung enthalten. Mehr hinsichtlich der Anzahl gibt es nicht. Eventuell haben Sie noch eigene Meetings, die Sie im konkreten Fall für Ihre Implementierung benötigen, aber grundsätzlich ist das alles.

Das Verhältnis von Events zu Entwicklungszeit

In diesem Abschnitt möchte ich mich dem "Meeting Overhead" einmal von den Fakten her nähern. Ich schaue mir die Vorgaben für die Events aus dem Scrum Guide an und setze diese Werte zu unterschiedlichen Sprintlängen in Beziehung.

Während es das agile Manifest mit

3. agiles Prinzip aus dem agilen Manifest

"Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne."

Quelle: Agiles Manifest, http://agilemanifesto.org

noch recht locker sieht, nimmt es der Scrum Guide mit

Scrum Guide

"Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ("Done"), nutzbares und potenziell auslieferbares ProduktInkrement hergestellt wird."

Quelle: Scrum Guide, www.scrumguides.org

schon etwas genauer. Er gibt aber nur die Obergrenze für die Dauer eines Sprints, nämlich ein Monat, an. In der Praxis haben sich neben der Maximallänge von einem Monat noch die Sprints von zwei und drei Wochen etabliert. Auch der Sprint mit der Länge von einer Woche findet ab und zu bei besonders innovativen und komplexen Produkten Anwendung. 

Meetings in Abhängigkeit der Sprintlänge

Nun werfen wir einen Blick auf die Länge der vorhandenen Events in Scrum, inklusive dem Backlog Refinement. Dabei stelle ich die Zeiten gegenüber, die in der Regel (und durch bloßes rechnen) Sinn ergeben. In der Praxis variieren diese Zeit teils sehr stark, abhängig von unterschiedlichen Rahmenbedingen. Das können zum Beispiel sein:

  • Was für ein Produkt wird konkret entwickelt
  • Wie reif ist das Team und welche Erfahrung hat das Team
  • Wie optimiert ist der bisherige Prozess
  • Wie gut sind Backlog Items vorbereitet
  • ...

Es hilft dennoch sehr, mit diesen Zeiten und Rahmenbedingungen zu starten. Dann werden Sie auch keinen Meeting Overhead in Scrum erleben!

Besonderheit Backlog Refinement

Das Backlog Refinement ist kein Event und hat keine Timebox wie die anderen Events. Das liegt daran, dass das Backlog Refinement eine aufwandsbezogene Tätigkeit ist. Das wird schnell klar, wenn wir überlegen, dass es schwieriger ist, mit 10 Entwicklern Stories zu verfeinern, als es mit 5 der Fall ist. Deswegen bezieht sich der Aufwand auf die Kapazität des Entwicklungsteams

Was bedeutet nun die Kapazität des Entwicklungsteams? Die Kapazität eines Teams ist die Zeit, die es in den Sprints real auch verbringt. Wenn wir zwei Wochensprints machen und dabei 10 Tage Kapazität von 10 Entwicklern haben, ergibt das eine Kapazität des Entwicklungsteams von 100. 10 Tage (10%) entfallen damit auf das genannte Refinement.

Dabei wird vom Scrum Guide offen gelassen, wer was wie macht. Deswegen entscheidet auch das Scrum Team darüber. Ein Beispiel:

  • Der Product Owner könnte von diesen 10 Tagen zum Beispiel eine gewisse Zeit für die Abstimmung mit dem Kunden sein (ohne Entwicklungsteam) und das Verfeinern und Aufnehmen von Backlog Items verwenden. Nehmen wir an, dies sind 3 Tage.
  • Der Rest könnten zusammen mit dem Entwicklungsteam für Schätzworkshops, Refinements, etc. verwendet werden. Dafür benötigt der Product Owner selbst noch zur Vor- und Nachbereitung 2 Tage und das Entwicklungsteam die restlichen 5 Tage für ein Meeting von einem halben Tag (10 Entwickler spendieren je einen halben Tag = 5 Tage).

Was auf den ersten Blick hoch erscheint, hilft Ihnen massiv bei der interativen und inkrementellen Entwicklung! Gerade wenn Sie Probleme in der Erstellung eines Inkrements haben, sollten Sie genauer auf Ihr Backlog Refinement schauen!

Die Sprints und die Zeiten im Überblick

Wenn Sie frisch mit Scrum starten, nutzen Sie bitte immer die aus dem Scrum Guide abgeleiteten Zeiten, so entgehen Sie dem Meeting Overhead in Scrum. Besonders wenn Sie merken, dass Sie deutlich mehr Zeit benötigen, als angegeben, ist es Zeit für eine Retrospektive bei Ihnen.

Sprint
Länge
1 Woche

Sprint Planning

2 Stunden

Daily Scrum

15 min

Sprint Review

1 Stunden

Sprint Retrospektive

0,75 Stunden

Backlog Refinement

4 Stunden
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
2 Wochen

Sprint Planning

4 Stunden

Daily Scrum

15 min

Sprint Review

2 Stunden

Sprint Retrospektive

1,5 Stunden

Backlog Refinement

8 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
3 Wochen

Sprint Planning

6 Stunden

Daily Scrum

15 min

Sprint Review

3 Stunden

Sprint Retrospektive

2,25 Stunden

Backlog Refinement

12 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
4 Wochen

Sprint Planning

8 Stunden

Daily Scrum

15 min

Sprint Review

4 Stunden

Sprint Retrospektive

3 Stunden

Backlog Refinement

16 Stunden *Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Aus meiner Sicht hilft es, sich gleich zu Beginn eine Übersicht zu erstellen, wann welche Meetings stattfinden und diese Information muss dann in das (oder die) Team(s) gebracht werden, ebenso in die Organisation. Im folgenden sehen Sie beispielhaft so einen Sprint Meeting Plan (ohne Backlog Refinement).

Meeting Overhead? Der Sprint Plan für 4 Wochen Sprints

Was Sie weiter für den Meeting Overhead und die Sprints beachten müssen!

Es gibt neben den konkreten Zeiten für die Sprints noch weitere Dinge, die Sie in Betracht ziehen sollten. Dazu gehört es sich in der Organisation auf die Suche nach Synchronisationswegen zu machen. Kann Ihr Team alleine alles entscheiden, benötigt es keine Abstimmungen, keine Zulieferungen oder ähnliches? Dann ist es einfach, oft gibt es aber irgendein Ereignis, auf das Sie sich synchronisieren müssen.

Ihre Sprintlänge und auch der genaue Startpunkt muss dann überprüft und ggf. auch angepasst werden. Im folgenden Bild sehen Sie eine vereinfachte Darstellung für eine angepasste Sprint Planung auf den Wochentag Donnerstag. In dem Beispiel könnten andere Takte dazu führen, dass die Sprint Planung am Donnerstag beginnen muss.

Kein Meeting Overhead mit getacktetem Meetingplan in der Organisation

Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS
Preis: nicht verfügbar
Zuletzt aktualisiert am 24.02.2018

Wir brauchen eine Anpassung!

Seien Sie bitte mit Anpassung immer vorsichtig. Scrum funktioniert nur als Ganzes. Auch wenn Sie aus dem Scrum Guide lediglich Teile nutzen können, ist das Ergebnis dann kein Scrum. Anpassungen sind im zeitlichen Rahmen aber immer wieder mal nötig. Das hängt zum Beispiel von dem entwickelten Produkt ab, wie gut das Team zusammenarbeitet und ähnlichem.

Ich starte gerne mit den Vorgaben, die der Scrum Guide bereitstellt. Orientieren Sie sich bitte auch an den oben genannten Werte und Zeiten. Stellen Sie dann fest, dass Sie andere Bedarfe an die Zeiten haben, dann nutzen Sie Ihre Retrospektive und beleuchten Sie Ihren Prozess und Ihre Anforderungen genau. Scrum basiert auf der empirischen Prozesskontrolle, Sie machen also Erfahrungen und adaptieren auf Basis dieser gemacht Erfahrungen!

Fazit: Meeting Overhead in Scrum gibt es nicht!

Wie so oft gilt auch hier:  Scrum ist einfach aber nicht leicht. Es ist eben kein Problem den Scrum Guide am Wochenende durchzulesen. Es gehören aber unter Umständen aber Jahre dazu, diese Anwendung zu perfektionieren. Sie müssen Scrum richtig anwenden und werden dann auch keinen Meeting Overhead spüren. Denken Sie bitte daran, dass Sie einen Meeting Overhead wahrnehmen, dass Sie sehr wahrscheinlich  Anpassungen an Scrum vorgenommen haben, die nicht optimal sind. Das liegt häufig an der Parallelität von Scrum zu bestehenden Initiativen und an Teilzeitteams.

1

Agil und Lean übertrieben einfach

Agil und Lean - übersichtlich und einfach

Manchmal vereinfache ich gerne Dinge. Agil und Lean jemanden zu erklären, der sich noch gar nicht damit auskennt erfordert oft so eine Vereinfachung. In diesem Artikel stelle ich Ihnen einmal meine einfach übertriebene Art und Weise vor.

Agil: Kundenwert und Flexibilität

Das wichtigste für mich im Bereich von Agil ist das Inkrement. Durch das Inkrement sind Sie in der Lage wirkliche Agilität zu leben. Wenn ich wählen müsste, wäre das Inkrement genau das, was für mich den Ausschlag gibt, ob Sie Agilität vorfinden können.

Das Inkrement zahlt maßgeblich auf die Flexibilität und den Kundenmehrwert ein.​ Beide Variablen sind die, an denen z.B. Scrum das System optimiert. 

Lean: kurze Durchlaufzeit

Schauen wir uns nun ebenso übertrieben einfach einmal an, was Lean ist, dann können wir sagen, dass eine besonders kurze Durchlaufzeit maßgeblich auf alles von Lean einzahlt. Auch hier spielen weitere Faktoren mit hinein. Wenn Sie es aber schaffen eine kurze Durchlaufzeit zu erreichen, dann haben Sie vieles von Lean erreicht zu haben.

Das Scrum nicht agil sein muss und das alles agile gleich Scrum ist, lasse ich an der Stelle einmal bewusst außen vor. Ebenso können Sie natürlich auch schnelle Durchlaufzeiten erreichen ohne sich mit Lean je beschäftigt zu haben. In der Regel werden Sie aber genau diese beiden Ausprägungen vorfinden, wenn sich die Ergebnisse (Inkrement, schnelle Durchlaufzeit) in der Realität finden lassen.

Agil und Lean - einfache Schlüsselkonzepte

Lernen ist ein inhärent wichtiger Bestandteil

Egal welche Wünsche ein Kunde hat, egal was wir in ein Backlog schreiben. Wenn wir es nicht schaffen aus einem Inkrement zu lernen und uns weiterzuentwickeln, dann haben wir nichts gewonnen. Wir können dann Verbesserungen eben nicht übernehmen.

Und das geht wiederum nur, wenn das Inkrement vorhanden ist. Wenn Sie kein Inkrement erzeugen, dann sollten Sie alles daran setzen, genau damit zu starten.

Reflektieren Sie einmal ihre agil und lean Implementierungen gegen diese Aussage. Ich bin mir sicher, dass Sie dort genau solche Ausprägungen finden werden.

YouTube ScrumKurs24

ScrumKurs24 jetzt mit YouTube Kanal!

ScrumKurs24 und YouTube

Der ScrumKurs24 ist jetzt mit einem eigenen YouTube Kanal vertreten. In diesem YouTube Kanal wird es in unregelmäßigen Abständen kleine Videos zu Scrum geben. Diese Video behandeln immer genau einen Aspekt aus Scrum oder dem Umfeld von Scrum.

Ziel und Zweck

Zum einen bin ich ein Fan von Videos im Ausbildungsbereich. Zum anderen denke ich, dass es eine gute Möglichkeit darstellt, Wissen über einen visuellen Kanal mit aufzunehmen. Ich möchte so die Möglichkeit geben, neben den hier existierenden Artikeln auch bewegte Informationen rund um Scrum darzustellen. Sie können sich den Kanal abonnieren und ganz kostenlos ansehen.

Fokus

Fokus ist nicht nur ein Scrum-Wert, sondern stand auch Pate für meine YouTube Videos: keines dieser Videos ist länger als 2:30min! So ist es möglich, den passenden Bereich herauszugreifen und in sehr kurzer Zeit das Wichtigste sich anschauen zu können.

Erklärstil

Die Videos sind alle im sogenannten “Erklärstil” oder auch “Explainer-Video” erstellt. Dabei sehen Sie praktisch, wie sich ein Whiteboard füllt und können der Hand folgende, die das schreibt. Diese Art der Produktion lässt den Aufwand in Grenzen halten, im Gegensatz zu Videos bei denen ich zum Beispiel selbst vor der Kamera stehen würde.

Nun wünsche ich aber viel Spaß mit meinem neuen YouTube Kanal! Schreiben Sie mir doch einfach, welche Videos Sie gerne noch sehen würden!

6

Nutzen Sie das Sprint Ziel richtig!

Das Sprint Ziel in Scrum

Scrum Entwicklungsteam Sprint Ziel

​Das Sprint Ziel definiert den Nutzen, den ein Produktinkrement am Ende des Sprint erreicht. Das Sprint Ziel wird allerdings so definiert, dass es nicht die Summe der umzusetzenden User Stories ist. Ein Sprint Ziel schreibt den Nutzen des Produktinkrements in einer abstrakten Form, so ist es möglich das Sprint Ziel zu erreichen, auch wenn z.B. eine User Story getauscht wurde oder nicht umgesetzt wurden konnte.

Das Scrum Team definiert

Das Entwicklungsteam, der Product Onwer und der Scrum Master definieren gemeinsam das Sprint Ziel. Dabei gehen die Teams in der Regel so vor, dass der Product Owner ein solches Ziel als Vorschlag mit in das Team bringt. Dann wird mit dem Entwicklungsteam darüber diskutiert und im besten Falle gleich übernommen. Es kann auch vorkommen, dass das Entwicklungsteam kleine Anmerkungen hat oder das Sprint als utopisch ansieht - dann muss in die Verhandlung mit dem Product Owner gegangen werden. Das Sprint Ziel wird während des Sprints nicht verändert.

Das Sprint Ziel am Board

Sprint Backlog

Das Sprint Ziel wird immer zum Sprint Backlog gehängt. Das hilft zum einen sehr im Sinne der Visualisierung - das Team schaut zwangsläufig immer jeden Tag (zu Beispiel im Daily Scrum) auf dieses Ziel und wird erinnert. Ach wenn dieser Aspekt oft als "lächerlich" oder "überflüssig" angesehen wird, ist es in meinen Augen sehr entscheidend.

Zudem kann das Team so auch viel besser die drei Fragen im Daily Scrum auf dieses Sprint Ziel beziehen.

Das Sprint Ziel kann nicht erreicht werden

Scrum Sprint Planning

Es kann durchaus auch vorkommen, dass ein Sprint Ziel einmal nicht erreicht wird. Das sollte immer die Ausnahme bleiben und ebenso in der Retrospektive ausführlich untersucht werden. Nehmen wir an das Scrum Entwicklungsteam hat sich komplett verschätzt und das Ziel des laufenden Sprints ist jetzt schon nicht mehr erreichbar. Dann kann und sollte der Sprint durch den Product Owner abgebrochen werden. Auch der Product Owner kann durch eine Änderung der Anforderungen und andere wirtschaftliche Entscheidungen sich dazu genötigt sehen, das Sprint Ziel einzustellen, da es nicht mehr zu erreichen ist.

Der Sprint wird in diesem Falle abgebrochen. Es ist besser den aktuellen Sprint abzubrechen, als ihn zu Ende zu führen, obwohl wir wissen, dass das Ziel nicht mehr erreicht werden kann.

​Beispiele

Wenn Sie Ziele zum ersten Mal aufstellen wollen, suchen Sie in der Regel eine Vorlage, ein Beispiel - kurz: wie machen es denn eigentlich andere? So ein Ziel könnte lauten: Ersten haptischen Prototypen für das neue Navigationsgerät erstellen, die Loginfunktionalität des Portals etablieren oder auch den Umgang mit Scrum lernen. Sie sehen schon, dass das Ziel ganz unterschiedlich sein kann. Nur eines sollte es eben nicht sein: eine einfache Wiederholung von Anforderungen / Product Backlog Einträgen.

Sie können sich nun bestimmt auch vorstellen, dass das im Sprint definierte Ziel als eine kleine Vision für den Sprint gilt. Es ist konkret genug eine Richtung festzulegen, aber noch so abstrakt, dass Sie sich für oder gegen Eigenschaften des Produktes entscheiden können.

Es ist nun vollkommend ausreichend, wenn Sie dieses Ziel am Sprint Backlog des Team festhalten. So kann jedes einzelne Teammitglied aus dem Entwicklungsteam tagtäglich seine Arbeit gegen eben dieses Ziel reflektieren!

>