Category Archives for "Projekterfahrungen"

Mehrere Produkte im Team

Agile, iterative und inkrementelle Entwicklung

Agile, iterative und inkrementelle Entwicklung

Ich darf täglich Kunden beobachten, die entweder mit Scrum Produkte entwickeln oder es demnächst vorhaben. Leider geht das Verständnis von Scrum, wenn sie sich dafür als “agile Entwicklung” entscheiden, in der Praxis und Theorie weit auseinander.

Häufig kommen das Aussagen, dass “Scrum so einfach nicht funktioniert” und wir “einen pragmatischen Ansatz benötigen, um Scrum an unsere Umgebungen anzupassen”. Innerlich baut sich dann ein Gefühl bei mir auf, dass sich zwischen Schmunzeln, Lachen, Wut und Ohnmacht ausdrückt.

Das ist gar nicht negativ auf den Kunden bezogen, sondern fängt bei mir selbst an. Ich trage - nicht erst seit gestern - die Gedanken von Scrum und Co durch die Welt, weil ich davon überzeugt. Vielleicht oft nicht aus der gesamten Perspektive, die für den ein oder anderen Betrachter notwendig sind. Deshalb versuche ich einen neuen Anlauf hier im Blog, der in meine must-have Readinglist für alle Kunden, Partner und Interessenten eingeht 🙂

agile, iterative und inkrementelle Entwicklung

Die Rahmenbedingungen müssen stimmen

Damit eine agile, iterative und inkrementelle Entwicklung wirklich Sinn macht, müssen die Rahmenbedingungen für Ihr Umfeld stimmen. Wenn Sie nicht die Rahmenbedingungen besitzen, die für Scrum optimal sind, dann werden Sie auch nur bedingt Vorteile in diesem Framework finden.

Diesen Rahmenbedingungen können Sie sich mit dem Stacey Landscape Diagram recht gut nähern oder Sie verwenden das Cynefin Framework. Wenn Ihre Analyse ergibt, dass Ihr Produkt, welches Sie entwickeln möchten, in einer komplexen Umgebung befindet, dann liegen Sie an der Stelle schon mal recht gut für einen Einsatz von Scrum. Wenn Sie die Rahmenbedingungen begriffen haben, spielen zudem noch eine Menge an weiteren organisatorischen Rahmenbedingungen mit in eine Entscheidung für eine Umsetzung mit Scrum. Ein Klassiker dabei ist immer wieder zu denken, mit einem großen “Roll-Out” kann eine solche Einführung gelingen. Das funktioniert nicht, denn Scrum basiert zum einen auf Empirie und zum anderen auf einem Inspect & Adapt Ansatz. Ohne jetzt zu sehr in die Details einzusteigen, wenn Sie nicht in der Lage sind, auf Basis Ihrer gemachten Erfahrungen den Prozess kontinuierlich zu verbessern, diesen transparent zu haben und darauf hin Anpassungen vorzunehmen, dann wird Ihnen auch der Erfolg von einem Scrum Team verwehrt bleiben.

Sie müssen überhaupt erstmal inkrementell entwickeln können!

Wenn Sie die benötigten Rahmenbedingungen (sowohl für Ihr Umfeld, als auch Ihre Organisation) vorfinden, dann ist das ein erster wichtiger Schritt. Allerdings müssen Sie auch die Fähigkeit besitzen, inkrementell Produkte zu entwickeln, denn dieses Denken in Inkrementen ist essentiell und sehr wichtig. Inkrementell bedeutet, dass Sie innerhalb Ihrer gewählten Länge des Sprints (wenn Sie sich nach dem agilen Manifest richten, dann müssen Sie innerhalb weniger Wochen oder Monate (regelmäßig) liefern, nach dem Scrum Guide, darf dieses nicht mehr als ein Monat sein) ein erlebbares Inkrement liefern können, das einer sauberen Definition of Done entspricht und durch den Kunden auch inspiziert werden kann. Das bedeutet, dass der Kunde Erfahrungen mit dem Inkrement machen und etwas “erleben” kann.

Natürlich ist oft die Euphorie recht groß zu Beginn einer neuen Transformation auf Scrum, aber auch voller Gefahren, wenn man die wirkliche Tragweite eines Inkrements nicht richtig verstanden hat. Deshalb gehe ich auf die aus meiner Sicht größten Stolpersteine noch einmal ein:

  • Sie liefern ein Inkrement aus und dieses Inkrement ist nicht erlebbar. Das kann die unterschiedlichsten Gründe haben wie zum Beispiel: Die Software ist nicht in einem Zustand, so dass sie ein Kunde auch wirklich erleben kann. Sie haben ein Produkt erstellt, aber keinen wirklichen “Durchstich” durch das Produkt generiert, so dass dem Kunden nur ein Blick auf einen Teil des Produktes möglich ist und der ganze Wert nicht erkenntlich ist. Ein Blick auf das Produkt ist also im Sinne eines Projektfortschritts wenig transparent.

  • Wenn Sie Ihre bisherige Entwicklung lediglich in “Sprints” zwängen, innerhalb in des Sprints aber nach wie vor ein sequentielles Vorgehen umsetzen, dann werden Sie keine agile Entwicklung und keinen Vorteil aus Scrum ziehen können. Das mag zu Beginn vielleicht noch ein logischer Weg sein, verstößt später aber gegen das Inspect und Adapt und auch eine regelmäßige Lieferung von funktionierender Software wird dann problematisch werden.

Sie müssen sich grundsätzlich einmal über den Wertstrom für Ihr Produkt, Ihre Software oder Ihren Service bewusst werden. Nur wenn Sie diesen kennen, können Sie überhaupt entscheiden, wie Ihre Teams organisiert sein sollten. Nur wenn Sie die Teams richtig aufstellen, dann können Sie auch inkrementell entwickeln.

Kennen Sie die Scrum Werte und agilen Prinzipien?

Leider immer sehr vernachlässigt und als “einfach” abgestempelt: die agilen Prinzipien und Scrum Werte. In der Regel haben natürlich die wenigsten Unternehmen, die keinen besonderen Wert darauf legen, diese verstanden. Ich werde die an dieser Stelle nicht erneut herleiten, sondern verweise auf meine bisherigen Blogbeiträge dazu.

Nicht erreichte Product Backlog Einträge gehören nicht in den nächsten Sprint - oder doch?

Immer wieder sehe ich gerne den folgenden Effekt bei Srcum Teams. Der Sprint ist zu Ende und es gibt noch einige Arbeit die im Sprint geplant wurde, aber nicht erledigt werden konnte. Sie liegt also als halbfertige Arbeit vor und gilt nicht als “fertig”, da sie natürlich nicht der Definition of Done entspricht.

Was macht der Product Owner und das Entwicklungsteam? Ganz oft nach dem Motto: was muss, das muss eben und schon stehen diese Einträge wieder im nächsten Sprint. Es wird sich häufiger nicht einmal die Mühe gemacht, dass man sich dem Thema erneut widmet.

Dafür gibt es folgende Ursachen aus meiner Sicht:

  1. Sie entwickeln nicht wirklich inkrementell, denn diese Einträge müssen immer gemacht werden, egal was passiert. Sie sind also zu erledigen, da sonst andere Dinge überhaupt nicht erledigt werden können (Vorarbeiten Integration, etc.).
  2. Sie haben doch nicht die Rahmenbedingungen von komplexen Produkten. Sie müssen nämlich bestimmte Aufgaben immer machen und es ist egal, wie sich der Markt entwickelt. Da würde ich zum einen immer gerne mal hineinschauen, ob dem auch wirklich so ist. Zum anderen scheint wenig Notwendigkeit zu bestehen, mit Scrum zu entwickeln.

Wie Sie richtig gute Product Backlog Items erstellen

Im Folgenden Abschnitt möchte ich das Augenmerk noch einmal genau darauf legen, wie Sie konkret auf gute Produkte hin entwickeln können. ich starte dabei ich mit den elementaren Variablen auf die Scrum fokussiert: Flexibilität und Kundennutzen.

Die Flexibilität fokussieren

Vielleicht ist die Annahme für viele zu trivial und wird gerne als überzogen und zu theoretisch abgetan. Nur wenn Sie dieses Inkrement liefern können, auch dann haben Sie überhaupt die Möglichkeit eine wirkliche agile und inkrementelle Entwicklung durchzuführen. Wenn Sie einmal das Konzept von einem Inkrement verstanden haben, dann begreifen Sie auch sehr schnell den Sinn von Scrum und dann wird schnell alles schlüssig.

Hinweis!

Wenn Sie zu den Personen gehören, die einfach “agile Elemente” einmal ausprobieren und nicht alle Vorteile von Scrum ausschöpfen wollen oder müssen, dann können Sie das natürlich tun. Ihr Ergebnis ist dann kein Scrum, Sie können aber trotzdem Ihre ersten Versuche machen und ausprobieren, wie sich zum Beispiel bestimmte Praktiken wie Planning Poker, User Stories oder Taskboards anfühlen und bei Ihnen einsetzen lassen.

Sie brauchen eine Flexibilität, um an einem dynamischen und volatilen Markt bestehen zu können. Wir erinnern uns an das Cynefin Framework, nur wenn Sie die Schritte “probe - sense - respond” benötigen, dann sind Sie auch im komplexen Bereich. Und dann brauchen Sie auch genau diese Inkremente. Wenn Sie die Inkremente nicht schaffen, dann entwickeln Sie an Ihrem Markt vorbei. Wenn Sie nicht am Markt vorbei entwickeln, dann haben Sie diese komplexen Rahmenbedingungen nicht. Und dann brauchen Sie dieses Inkrement auch nicht, dann sollten Sie aber genau überlegen, was für Vorteile Sie sich von Scrum erhoffen und warum Sie es einsetzen.

Die Kunden im Blick

Als nächstes müssen Sie Ihre Kunden im Blick behalten. Das sagt sich zwar einfach, ist aber in der Realität schwer. Denn Kunden im Blick halten bedeutet nicht, dass Sie mit diesem “halt mal sprechen” und dann der Meinung sind, zu wissen was dieser genau braucht. In komplexen Rahmenbedingen “driftet” die Erwartungshaltung des Kunden beachtlich. Und das auch oft so, dass Sie die Erwartungshaltung nicht einfach in einem Gespräch erarbeiten können, sondern der Kunde muss diese erleben. Nur durch die oben genannte Flexibilität hat ein Product Owner überhaupt die Möglichkeit irgendeine Verbesserung zur Optimierung des Mehrwerts für den Kunden herbeizuführen. Er ist derjenige, der das Beste aus dem Produkt mit dem Entwicklungsteam zusammen herausholen muss. Dafür ist es unabdingbar, den Kunden und die Wünsche zu erleben, zu reflektieren und dann zu kennen.

Gute Product Backlog Items erstellen

Im Grunde ist das einfach aber nicht leicht umzusetzen. Sie haben genau dann gute Product Backlog Items, wenn diese für sich einzeln genommen

  • einen Mehrwert liefern und
  • sich einzeln in ein Inkrement überführen lassen

Das finden wir zum Beispiel in den INVEST Kriterien von User Stories. Sie müssen einen Wert (value) liefern und sie dürfen nicht voneinander abhängig sein. Wenn Sie dieses Muster etablieren, dann werden Sie mit Ihrem Inkrement Erfolg haben.

Scrum Entwicklungsteam

Teamzusammensetzung in Scrum

Teamzusammensetzung in Scrum: So geht’s!

Wer mit Scrum startet, muss sich Gedanken machen, wie die Teamzusammensetzung der Teams aussieht, die ein Produkt umsetzen. Mit der Teamzusammensetzung ist gemeint, wie das Team, dass in Scrum cross-functional entwickeln soll, sich zusammenstellt. Welche Personen mit welchen Skills werden benötigt und arbeiten in dem Team zusammen und entwickeln das besagte Produkt. Während früher die Teams einfach durch das Management bestimmt wurden, geht es mehr und mehr dazu über, dass sich Teams frei organisieren dürfen. Doch wie funktioniert diese Selbstorganisation?

Teamzusammensetzungen früher: es wird bestimmt!

Wenn Sie nicht in einem super innovativen Unternehmen arbeiten, das eine Teamfindung für Projekte erlaubt, kennen Sie die Zuweisungen von Mitarbeitern zu Projekten wahrscheinlich nur zu gut. Der Chef bestimmt, wer an welchen Projekten arbeitet. Das kann der richtige Weg sein, sein Personal zuzuteilen. Aus Sicht des Management ist es vielleicht sogar einzig richtige.

Es gibt - gerade im Bereich der Wissensarbeit - Projekte, in denen das nicht mehr so einfach der Fall ist. Hier spielen deutlich mehr Faktoren für eine Teamzusammensetzung ein, als es früher der Fall war. Motivation, Selbstbestimmung und das exzellente Können sind nun Treiber geworden, die für die Teamzusammensetzung eine Rolle spielen.

Die Teamzusammensetzung neu gedacht

Voraussetzungen

Für die folgende Beschreibungen gehe ich davon aus, dass wir uns über ein größeres Unternehmen unterhalten, in dem auch verschiedene Projekte durch verschiedene Teams bearbeitet werden können.

Wenn Sie nur ein Produkt und nur ein Team haben, dass alle benötigten Fähigkeiten besitzt, dieses Produkt zu entwickeln, haben Sie natürlich nur sehr geringe Möglichkeiten, die Teamzusammensetzung innerhalb des Unternehmens zu beeinflussen.

Es muss also eine gewisse Auswahlmöglichkeit zwischen Personen und Teams bestehen.

Freiheit und Anarchie funktionieren nicht

Mehr als einmal habe ich es nun erlebt: Das Management möchte Freiheit geben und startet für neue Teams mit der Ansage: “Sucht euch euer Team selbst!”. Diese Veränderung der Teamzusammensetzung ist zum einen sehr groß. Zum anderen ist die Bedeutung der Teamzusammensetzung so nicht richtig.

Was passiert dann häufig? Es gibt Teams, da wollen alle arbeiten, in anderen aber nur wenige oder gar keiner. Jetzt hat die Organisation ein Problem! Die Mitglieder der zukünftigen Teams versammeln sich verstärkt um die Teams und erwarten nun natürlich, dass sie auch dort arbeiten können. Aus Sicht der Psychologie ist so eine Ansage für eine optimale Teamzusammensetzung nicht hilfreich.

Hier kommen die ganzen Anzeichen zum Vorschein, die es früher auch schon gab - aber durch die Bestimmung einer Führungskraft festgelegt wurde. Die Wünsche waren und sind ähnlich, hier kommen Sie aber ans Tageslicht und erzeugen eine Transparenz. Das ist gut, denn nur so können Sie auch reagieren.

Wir brauchen andere Werkzeuge, um Teams zusammenzustellen. Doch wie machen wir das am besten?

Manche Teamzusammensetzungen ändern sich nicht

Seien wir realistisch. Auch bei aller Euphorie von Teams, dass sie nun etwas selbst zusammenstellen und sich in Teams frei organisieren dürfen, gibt es Rahmenbedingungen, die vorhanden sind und berücksichtig werden müssen. Und gute Mitglieder oder ganze Gruppen eines Unternehmens wissen, was sie gut können und wollen vielleicht auch gar nichts anderes machen. Das betrifft vor allem die Teamrollen. Wenn es zum Beispiel den Architekten in einem Scrum Team nicht gibt, gibt es doch Präferenzen und die Skills werden auch benötigt. Es ist also sehr unwahrscheinlich, dass sich gute Mitglieder so zusammenstellen, dass eben dieser Skill in einem Team fehlt. Das machen Teams oft auch über die vorgegebenen Grenzen hinweg heute schon.

Wie es trotzdem klappen kann: Teamzusammensetzung neu gedacht!

Es geht auch anders. Wer sich etwas über Teamzusammensetzungen Gedanken macht, kann auch mit nicht so einfachen Rahmenbedingungen sich von alten Strukturen lösen. Dabei sollen zwei wichtige Dinge im Fokus stehen:

  • Die Motivation der Gruppen zur Aufteilung auf Teams soll bewahrt und gefördert werden
  • Unternehmerische Strukturen müssen sich in den Teams abbilden

Gerade zu Beginn haben Sie wahrscheinlich viele Rahmenbedingungen. Wenn Sie drei Architekten haben und drei Teams zusammenstellen wollen, die alle einen Architekten brauchen, dann können Sie nicht ohne Regeln diese Teams aufstellen. Denn wenn ein Team an einem Produkt arbeiten soll, das alle Architekten gut finden, dann wollen vielleicht alle darin arbeiten. So etwas ist dann in den unternehmerischen Strukturen zu berücksichtigen.

Werkzeuge für die Teamzusammenstellung

Das Schöne ist, dass Sie nur ein paar wenige Werkzeuge für eine Teamzusammenstellung benötigen. Der Rest funktioniert praktisch alleine. Sie benötigen lediglich zwei einfache Werkzeuge, um Ihre Teamzusammenstellung zum Erfolg werden zu lassen:

  • Stellen Sie Regeln auf, die Ihre benötigten Unternehmerische Strukturen abzubilden.
  • Nutzen Sie ein Format für die Zusammenstellung und etablieren Sie dazu ein kleines Event.
Regeln Teamzusammensetzung

Ich benutze gerne ein Flipchart mit Regeln, die von allen Teams einzuhalten sind. Das können grundlegende Themen sein, die oft allen klar sind, aber ich schreibe sie zum gemeinsamen Verständnis noch einmal auf. Das sind zum Beispiel:

  • Jedes Team hat einen Analysten
  • In jedem Team muss mindestens eine Person aus Bereich A sein
  • Jedes Team hat nicht mehr als X Personen aus Bereich Y
  • Es gibt mindestens 4 Personen in jedem Team
  • ...

Auch Sie werden diese Bedingungen bei einer Teamzusammensetzung haben. Überlegen Sie auch mal an implizite Dinge, die Ihnen sowieso klar erscheinen. Sowas sind oft die ersten Schritte sich an diese Regeln zu machen.

Das Format ist immer wieder Komponente, an der ich variieren kann. Ich nutze zwar auch hier praktisch immer wieder sehr ähnliche Komponenten, aber die Freiheit zur Änderung bestünde - ebenso bei Ihnen. Was aus meiner Sicht gut funktioniert aber etwas Zeit für die Vorbereitung entspricht ist das folgende Vorgehen. Schreiben Sie Stellenbeschreibungen für die Rollen im Team. Jedes Team hat dann eine bestimmte Anzahl von Stellenbeschreibungen. Hier sind dem Format keine Grenzen gesetzt, Sie können also entweder damit beginnen, nur so viele Stellenbeschreibungen zu nutzen, wie sie auch Plätze im Team haben. Oder Sie variieren und machen einen Überhang an möglichen Stellen. Das liegt an Ihnen.

Im folgenden Bild ist ein Teamboard abgebildet. Dort sehen Sie ebenso die Stellenbeschreibungen. Sie können jetzt pro Team so ein Setting bereitstellen.

Stellenbeschreibung Teamrollen

Stellen Sie sich hier eine Art Marktplatz vor: verschiedene Teams haben verschiedene Stellenbeschreibungen und die Mitglieder dürfen sich nun diese Stellenbeschreibungen ansehen.

Auch hier können Sie wieder unterschiedliche Szenarien durchspielen.

First Come, first serve

Ein einfaches Prinzip ist nach FCFS vorzugehen. Nachdem Sie also die Regeln vorgelesen haben, lassen Sie die Mitglieder einfach machen. Wer eine passende Stellenbeschreibung findet, nimmt sich diese und platziert sich beim Team.

Wenn alle Beschreibungen einen Mitarbeiter gefunden haben, haben Sie Glück. In der Regel ist es aber nicht so. Ein oder zwei Mitglieder sind nicht zufrieden oder wollen doch in einem anderen Team arbeiten. Das passiert und ist normal.

Teamzusammensetzung Scrum nur Stellenbeschreibung Team

Hier bietet es sich dann an, die Rollen umzudrehen. Lassen Sie dann die existierenden Teams die Gruppe an über gebliebenen Personen anschauen und überlegen, was dem eigenen Team noch an Kompetenzen fehlt und ob das jemand leisten kann. Aus Sicht der Psychologie ist das spannend: die, die nichts gefunden haben, lernen jetzt kennen, warum sie von anderen doch gebraucht werden. Für die Motivation in der Teamzusammensetzung ist das ein nicht zu unterschätzender Vorteil.

Einstellungsgespräch

Wenn Sie Mitglieder haben, die in diesen Teams einen entschiedenen Anteil haben, können Sie diese auch als Sparringspartner nutzen und alle die, die in das Team wollen müssen die Stellenbeschreibung noch einmal challangen. 

Teamzusammensetzung Scrum

Jeder der eine passende Stellenbeschreibung findet, nimmt sich diese und “bewirbt” sich beim Teamvertreter. Wenn mehrere im Team sind, kann dieser Prozess dann auch gerne vor allen Teammitglieder stattfinden.

Hier ist das warum sehr entscheidend, also das Team sagt ob der auf die Stellenbeschreibung passt und der Interessent muss klar darlegen, warum er denkt, er passt in das Team.

Fazit für Ihre Teamzusammensetzung

Es ist kein großer Schritt für die Führungskräfte, aber ein großer für die Befähigung und Motivation Ihrer Teammitglieder. Machen Sie aus Gruppen im Unternehmen echt Teams, die Ihre Teamrollen mit Begeisterung ausfüllen und leben. Nutzen Sie die oben beschriebenen Werkzeuge für Ihre Veränderung der Teamzusammensetzung. Sie werden sehen, dass mehr Verantwortung, Ermächtigung und Selbstorganisation der Mitarbeiter sich mehr als auszahlt - für Sie als Führungskraft und das ganze Unternehmen.

YouTube ScrumKurs24

Commitment und Schätzung

Das Problem von Commitment und Schätzung

Commitment und Schätzung werden in meiner beruflichen Tätigkeit oft als Synonym verwendet. Ein fataler Fehler, denn kein Team, kein Mitarbeiter traut sich mehr etwas zu schätzen, denn seine Schätzung wird als Commitment aufgefasst und weiter verwendet.

Der Manager nimmt die Schätzung und teilt es dem Vertrieb, dem Geschäftsführer und weitere Stakeholdern mit. Dabei wollte das Team einfach eine Schätzung abgeben, wie lange sie wohl mit der vorhandenen Mannschaft brauchen, um eine Funktionalität zu liefern. Es ist egal und unbedeutend, ob diese Schätzung richtig oder falsch ist. Es war und bleibt eine Schätzung.

Diese Schätzung "wir denken, wir brauchen Zeit X, um diese Funktionalität zu liefern", wird als Commitment (Verpflichtung) interpretiert, "wir liefern in der Zeit X diese Funktionalität".

Commitment heißt Forecast im Scrum Guide

Commitment und Schätzung

Während früher sich das Wort "Commitment" im Scrum Guide gefunden hat, gibt es das nun nur noch in den Scrum Werten, aber nicht mehr bei der Schätzung. 

Es wurde ersetzt. Das neue Wort heißt Forecast. Forecast soll ausdrücken, dass sich in Zeiten von Komplexität und Ungewissheit, keine Verpflichtung auf genau diese X Einträge aus dem Backlog erreichen lässt. Stattdessen gibt das Entwicklungsteam nun eine Vorschau ab - muss es nun keine Verpflichtung mehr geben?


In meinen Augen muss das Entwicklungsteam nach wie vor eine Verpflichtung abgeben. Das Wort wurde zwar in der Beschreibung geändert, aber die Bedeutung hat sich für mich inhaltlich nicht stark geändert. Es hilft aber typischen Außenstehenden Personen einen besseren Einblick zu bekommen. Während früher vielleicht kein Manager zwischen Commitment und Schätzung unterschieden hat, fehlt diesen Personen nun das harte Kriterium. Foreacest klingt weitaus schwächer oder einfacher. Es entschärft die Sprache in meinen Augen.

Commitment

Keine Schätzung ohne Wahrscheinlichkeit!

Commitment und Schätzung lassen sich leicht unterscheiden, wenn die, die Schätzungen vornehmen eine Wahrscheinlich mit angeben.

quote-right

Entwickler: "Mit einer Wahrscheinlichkeit von 60% brauchen wir 7 Tage"

Manager: "Und wie komme ich auf 95%?"

Entwickler: "dazu brauchen wir 47 Tage"

Manager: "was?"

Und plötzlich sind alle Personen in einem Dialog und kommunizieren. Es ist keine absolute Schätzung, sondern hilft, die inhaltliche Diskussion anzustoßen.

Falsche Schätzung und Commitment führt zudem zum Parkinsonschen Gesetz: Wenn ich sage, ich brauche 7 Tage und bin nach 2 Tagen fertig, was tue ich dann? In der Regel füllt sich die vorhandene Zeit mit der Aufgabe. Obwohl wir mehr leisten könnten (wir sind nach 2 Tagen fertig) werden wir die 7 Tage ausnutzen. Denn sonst hätte wir uns ja "verschätzt". Das kann dann bei Vorgesetzten oder Auftraggebern in den falschen Hals kommen.

Puffer Commitment und Schätzung

Zudem generieren Sie hiermit Puffer bei den Mitarbeitern. Ihr Mitarbeiter werden beginnen mehr zu schätzen, als sie brauchen, wenn Sie die Schätzung als Commitment ansehen.

Mehrere Produkte im Team

Mehrere Produkte im Team entwickeln

Das Setting: Mehrere Produkte im Team entwickeln

Mehrere Produkte ein Scrum TeamMehrere Produkte im Team – eine Herausforderung vor der ich einmal mit einem Team stand. In dem besagten Projekt standen die Rahmenbedingungen fest. Ich bin ein Fan von Scrum nach Lehrbuch, da bei allen Derivaten zwar immer Verbesserungen erzielt werden können – nie aber so gigantische, wenn das Framework komplett und vollständig angewendet wird.

Nicht immer sind die Rahmenbedingungen so, wie diese sein sollten. Nicht immer haben wir wirklich alle Ansatzpunkte in der Hand, um Scrum in seiner Gänze zu machen. Auch wenn dann solche Implementierungen streng genommen kein Scrum (vgl. Scrum Guide) sind, kann es eine beachtliche Prozessverbesserung mit sich bringen.

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum Guide

Mehrere Produkte im Team war in diesem Setting die einzige Möglichkeit, denn es gab nicht mehr Teams, es konnten nicht weniger Produkte entwickelt werden und Scrum sollte ausprobiert werden. Es stand damit auch der experimentelle Charakter im Vordergrund.

Um was für Produkte geht es?

ProduktDie Produkte, die durch das Team umgesetzt wurden, waren reine Softwareapplikationen. Es waren teilweise kritische Applikationen im Unternehmen, teilweise auch nicht. Die Wichtigkeit der kritischen Applikationen war enorm, denn darüber verdiente das Unternehmen sein Geld. Dabei wurden die Produkte nicht im klassischen Sinne verkauft, sondern durch die Nutzung und Anwendung dieser Produkte entstand für das Unternehmen Geld.

Nicht jede Applikation wurde neu entwickelt. Es gab diese Applikationen bereits und an einigen wurde mehr neues umgesetzt, an anderen weniger. Mehrere Produkte im Team waren nötig, da diese Produkte durch ein Team betreut wurden und alle Produkte noch Anpassungen bekamen.

Zusammenstellung des Teams

TeamzusammensetzungDas Entwicklungsteam mit Scrum Master befanden sich an einem anderen Standtort als die drei Produkt Owner, aber alle in Deutschland.  Das Team hatte die benötigten Skills aus diesem Produkt ein Produktinkrement herzustellen. Alle Teams waren bei einem Softwareunternehmen tätig. Die Product Owner waren nicht im direkten Konkurrenzkrieg sondern partnerschaftlich unterwegs. Sie stammten auch alle aus dem gleichen Unternehmen, mussten aber für bestimmte Applikationen den Mehrwert im Sinne des Kunden treiben.

Wie wurden mehrere Produkte im Team entwickelt?

Mehrere Produkte im Team zu entwickeln benötigte einige Anpassungen, die sich aber grundsätzlich einfach und unkompliziert durchführen ließen. In diesem Abschnitt gehe ich einmal auf diese Änderungen im Detail ein.

Sprint Planning 1

Scrum Sprint PlanningDas Sprint Planning 1 wurde mit allen Product Ownern der einzelnen Produkte durchgeführt. Dazu gab es im Vorfeld schon eine Abstimmung (PO-Arbeit) zwischen den einzelnen Personen. Die Product Owner haben im Vorfeld Ihre Product Backlog Items (aus drei Backlogs) gegeneinander konsolidiert und sich auch eine Reihenfolge einigen müssen. Für das Team stand genau ein Product Backlog zur Verfügung, in dem alle relevanten Items vorhanden waren. Diese waren beschrieben, geschätzt und in einer Reihenfolge sortiert. Ebenso war der Business Value in jedem Product Backlog Eintrag für das Unternehmen erkennbar.

Die Product Owner haben Ihre Einträge vorgestellt und das Team hat solange Einträge aufgenommen, solange klar war, dass die Product Backlog Einträge noch in den Sprint gepasst haben und zusätzlich auch bei Abhängigkeiten möglich waren.

Backlog Refinement

Backlog Refinement ToolboxIm Backlog Refinement wurden die einzelnen Product Backlog Einträge (PBI) durchgesprochen. Für die Vorstellung und die Durchspräche eines PBI wurde in etwa 20 Minuten benötigt. Vor dem eigentlich Projekt wurden ebenso zwei Refinements unternommen, damit genug Product Backlog Einträge zur Verfügung standen. Bei einigen Einträgen war das Wissen über die Product Backlog Einträge bei allen Product Ownern verteilt und nicht alle Product Owner mussten immer anwesend sein. Um mehrere Produkte im Team zu entwickeln, war es absolut notwendig, dass immer ein Product Owner dabei war, der die Einträge erklären konnte. Das ist natürlich nicht verwunderlich, aber wichtig zu verstehen, ist es trotzdem!

Sprint Ziele

Mehrere Produkte im TeamWie sich jeder vorstellen kann, war es mit den Zielen nicht ganz so einfach, da unterschiedliche Produkte in der Regel auch unterschiedliche Ziele haben. Ebenso war es auch bei diesem Projekt. Es gab zu Beginn Ziele, die alle Teams nutzen konnten. Als die Teams starten gab es mehr “lernende” Ziele und ebenso waren einige “qualitative” Ziele durchaus für alle zu benutzen.

Soweit es wirklich möglich war, haben wir versucht in Abhängigkeit der Vision immer Sprint Ziele zu finden, die für alle Applikationen / Produkte galten. Das war uns wichtig, denn je nach Anzahl der User Stories war es nicht immer leicht für wenige Stories (für ein Produkt) ein extra Ziel zu finden. Es gab aber tatsächlich solche Moment, in denen wir dann pragmatisch diesen Weg gegangen sind.

Vision

Scrum VisionDie Vision hat recht gut funktioniert. Wir haben hier den Weg gewählt, diese in vier Sätzen auf einem Flipchart zu erstellen. Es war hilfreich, dass wir die Applikationen in Summe mehr oder weniger das gleiche Ziel für das Unternehmen hatten, die Vision war also für alle gemein gültig.

Produktinkremente

Mehrere Produkte im Team - mehrere InkrementeMehrere Produkte im Team bedeutete auch mehrere Inkremente, die das Team zeigt und vorstellt. Nun war es so, dass nicht alle Inkremente übermäßig viel Arbeit und Aufwand bedeuteten. Es gab nicht immer für jede Applikation ein Inkrement, sobald aber Product Backlog Items für eine Applikation vorhanden waren, gab es auch ein Inkrement.

Mehrere Produkte im Team – was war nicht so gut?

  • Wenig überraschend, hat ein Team, das mehrere Produkte entwickelt, nicht viel Zeit für jedes Produkt, wie wenn das Team ein Produkt am Stück entwickeln würde. Der Arbeitsfortschritt für die einzelnen Applikationen wäre wohl schneller gewesen, wenn alle Applikationen nacheinander entwickelt worden wären. Das ist der Blick von außen auf alles. Da hier aber teils auch Wartungsarbeiten und kleine Verbesserungen vorgenommen wurden, wäre es nicht trivial, das anders aufzustellen. Die Velocity war damit nicht überragend hoch, reichte aber den Product Owner der jeweiligen Applikationen für Ihre Umsetzungen. Bei Problemen haben die Product Owner Prioritäten und Abhängigkeiten vor dem Sprint Planning mit weiteren Hierarchieebenen besprochen und eine Lösung im Vorfeld gesucht.
  • Mehrere Produkte im Team bot eine neue Herausforderung für die Product Owner in der Releaseplanung. Es war nicht immer klar, wann welche User Story auf Basis der Velocity umgesetzt werden kann. Die finale Abstimmung wurde in der Product Owner Runde besprochen und dann final priorisiert. Das erforderte häufiger eine Neuplanung auf Basis aktueller Product Backlog Items, die nicht wie geplant umgesetzt werden konnten.
  • Man stößt bei dem Thema “Mehrere Produkte im Team” immer wieder an Grenzen. Diese lassen sich in Retrospektiven gut untersuchen. Das haben wir gemacht, aber keine entscheidende Verbesserung aufgrund der Rahmenbedingungen erzielen können. Es wurden mögliche Änderungen identifiziert das Setting “Mehrere Produkte im Team” anzupassen – diese Änderungen wurden dann im Ganzen unter Berücksichtigung aller Pro und Contras mit dem Management nicht mehr adressiert. 
Backlog Refinement

So verbessern Sie Ihr Backlog Refinement

Das Backlog Refinement

Backlog Refinement ToolboxDas Backlog Refinement in Scrum ist eine sehr wichtige entwicklungsbegleitende Tätigkeit, die im Scrum Guide mit etwa 10% der Entwicklungskapazität des Team berechnet wird. Ziel dieser Aktivität ist es, dass Anforderungen aus dem Product Backlog eine gewisse Reife erlangen, um in der Sprint Planung sinnvoll prozesiert werden zu können. Das Entwicklungsteam und der Product Owner haben hier die Möglichkeit das Verständnis zu schärfen: sie detallieren Anforderung, schätzen und schneiden diese.

Das sagt der Scrum Guide zum Refinement

User StoryBei der Frage nach einer ersten Idee zur Umsetzung des Backlog Refinement lohnt sich der Blick in den Scrum Guide. Hier finden wir die folgenden Angaben:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Meine Erfahrung zum Backlog Refinement

Scrum MasterMeine eigenen Erfahrungen und Eindrücke zum Backlog Refinement möchte ich Ihnen hier natürlich auch noch auf den Weg mitgeben:

  • Bevor der erste Sprint startet, finde ich es als hilfreich mit dem Team und dem Product Owner ein bis drei Refinements zu machen, um das initiale Backlog auf einen guten Stand zu bringen. Das müssen Sie natürlich nicht tun, es hilft in meinen Augen aber sehr, dass die nachfolgenden Events in Scrum schnell und gut durchgeführt werden können, da die Basis der Anforderungen auf einem guten Stand ist.
  • Es kann Projekte geben, in dem das Backlog Refinement nur minimal Zeit in Anspruch nimmt. Das hängt immer ganz von den Rahmenbedingungen ab.
  • Ich nutze klare Vereinbarungen zwischen Team und Product Owner: das Backlog Refinement ist – wie die anderen Events auch – ein fester Termin mit Agenda, um das Thema der Komplexität zu verringern und einen Rahmen zu schaffen.
  • Natürlich nicht immer zu halten, aber gerne als Startwert für mich zur Kontrolle: Können die Product Backlog Items im Refinement innerhalb von 20 Minuten besprochen werden? Wenn nein, dann sind sie in der Regel zu groß oder benötigen noch weitere Verfeinerungen. Auch das ist sehr abhängig vom Kontext, stellt für mich aber einen Wert bei der Analyse von neuen Teams dar.

Der Ablauf eines Backlog Refinements

Ablauf im Backlog RefinementIn meinen Augen hilft es oft sehr, sich über so einen Ablauf einmal in Detail Gedanken zu machen. Ich sehe auch das Backlog Refinement immer unter dem Gesichtspunkt einer kontinuierlichen Verbesserung.

Legen Sie das Backlog Refinement als Termin an

Ich empfehle sich im Vorfeld bei der Festlegung der Scrum Umsetzung zwischen Product Owner und Entwicklungsteam das Refinement als festen Platz im Sinne eines Termins festzulegen. Dazu sollten sich Product Owner und Team überlegen, was sie gedenken an Zeit für dieses Meeting zu benötigen. Auch hier gilt, an diesen Wert ist das Team mit dem PO natürlich nicht gebunden, wenn es geändert werden muss, wird es geändert und angepasst. Dazu bietet sich dann auch die Retrospektive an.

Den Termin für das Backlog Refinement kann wahlweise der Product Owner oder auch der Scrum Master einstellen. Für beides gibt es Präferenzen:

  • Wenn bei Ihnen der Scrum Master alle Termine verwaltet, dann kann er es natürlich auch für das Backlog Refinement tun. Der Vorteil ist, dass er sich damit um alle Termine kümmert und wenn zum Beispiel jemand absagt, krank ist oder sonst etwas passiert, er immer direkt am Puls der Zeit ist. Das sollte er zwar so oder so sein, aber aus meiner Erfahrung hilft das trotzdem noch einmal.
  • Wenn der Product Owner bei Ihnen zum Beispiel auch für das Sprint Review einläd, dann wäre auch das Refinement für ihn eine gute Möglichkeit seine Wichtigkeit und den Fokus für das Team auszudrücken. Gefühlt – und je nach Reife des Teams und dessen Zusammensetzung – hat es ein anderes Gewicht, wenn es der Product Owner die Einladung ausspricht.

Der Vorteil als Meeting

Natürlich stellt immer die Frage nach der Sinnhaftigkeit eines zusätzlichen Meetings. Meine Präferenz liegt darin, dass zu Beginn gleich klar ist, dass es dort noch Aufwand für ein Meeting gibt. Es hilft gleich zu Beginn zu überschauen, was an “Management” für den Sprint und den Inahlt wirklich nötig ist.

Agenda und Teilnehmer festlegen

Zu jedem guten Termin gehört eine Einladung und die richtigen Teilnehmer. Auch das gilt es für jedes Mal zu überprüfen. Ein möglicher Einladungstext bzw. Agenda für die elektronischen Kalender könnte wie folgt aussehen:

Backlog Refinement Agenda & Einladungstext

Liebes Scrumteam,

ich möchte euch hiermit zu unserem Backlog Refinement einladen. In diesem Regeltermin kümmern wir uns um die Reife der Einträge im Backlog.

Datum & Zeit:

  • xx.xx.xxxx (ggf. auch Serientermin), um xx.xxUhr

Ziel:

  • Verfeinerung der Product Backlog Items und Schaffen eines gemeinsames Verständnis über Anforderungen

Agenda:

  1. Vorstellung neuer oder wichtiger Product Backlog Items (PBIs) durch den Product Owner
  2. Fragen zu dem PBI durch das Entwicklungsteam
  3. Verfeinerung des PBI durch Überprüfung und ggf. Erweiterung der Akzeptanzkriterien
  4. Überprüfung auf die richtige Größe: kann das PBI im Sprint umgesetzt werden? Wenn nicht, wie schneider wir diese Anforderung?
  5. Schätzen der Anforderungen

Vielen Dank im Voraus für eure Teilnahe und Engagement,

[Scrum Master oder Product Owner]

Nehmen Sie das bitte auch als Vorlage und nicht als reine einzige Umsetzungsmöglichkeit. Überprüfen Sie in wie weit das Ihre Anforderungen an die Einladung vom Backlog Refinement erfüllt und passen Sie es dann entsprechend an.

Das Backlog Refinement als Meeting

Scrum Product OwnerZu dem ausgewählten Termin steht dann das Backlog Refinement als Termin dann an. Der Scrum Master kümmert sich um die Einhaltung der typischen Regeln und hat natürlich auch die Timebox mit seinem Timekeeper im Blick. Es kann hilfreich sein, die entsprechenden Regeln noch einmal auf dem Flipchart zusammenzufassen und im Raum aufhängen, damit jedem gleich noch einmal klar ist, worum es geht. Ja, das wissen die Teilnehmer bereits durch den Kalender, aber gerade in größeren Organisationen habe ich die Erfahrung gemacht, dass es durchaus hilfreich ist dieses noch einmal “analog” im Meeting zu unterstützen.

Der Product Owner stellt vor

Der Product Owner kann beliebige Product Backlog Items vorstellen, die ihm wichtig sind. Das beinhaltet zum Beispiel:

  • Ganz neue Product Backlog Items, die das Team noch gar nicht kennt und die erst kürzlich in das Product Backlog eingezogen sind
  • Bereits geschätzte Product Backlog Einträge, die der Product Owner erneut geschätzt haben möchte, Fragen zur Aufteilung (Schneiden) hat oder Details neue Details einbringen möchte
  • Zukünftige Backlog Items, die noch so weit in der Zukunft liegen, dass diese nicht detailliert genug sind, dem Product Owner aber die Einschätzung des Teams helfen kann für wirtschaftliche Entscheidungen

Der Product Owner sollte auch die Person sein, die neue Erkenntnisse und die Details sowie Änderungen direkt im Backlog vermerkt. Das sollte definitiv nicht der Scrum Master tun, das Backlog gehört dem Product Owner und er ist dafür verantwortlich.

Die Vorstellung und Informationen können variieren und je nach Kontext unterschiedlich sein, der Product Owner…

  • … liest die User Story vor
  • … beschreibt durch Personas eine Zielgruppe oder geht genauer darauf ein
  • … bringt neue Sichten von Kunden mit und diskutiert diese mit dem Team
  • … zeigt die angereichterten Informationen aus einem letzten Workshop mit der Zielgruppe

Das Team schätzt und stellt Frage

Das Entwicklungsteam hört sich die Vorstellung des Product Owners an. Darauf hin sollte es natürlich Fragen stellen, wenn welche vorhanden sind. Hier lohnt es sich als Scrum Master oder agiler Coach auch immer darauf zu achten, wie lange diese Diskussionen dauern. Ich persönlich habe die Erfahrung gemacht, dass 20 Minuten ein erster guter Richtwert darstellt. Das variiert je nach Team, Branche und Aufgabe, aber wenn man noch keine empirischen Daten hat, hangel ich mich immer an diesem Wert entlang.

Dauer von Product Backlog Items

Wenn Sie noch keine empirische Erfahrung haben, dann sollten Sie mit dem Wert 20 Minuten pro Product Backlog Item starten. Ihre Erfahrung wird zeigen, ob dieser Wert für Sie nützlich ist. Damit könnten Sie dann drei Product Backlog Items in einer Stunde schaffen. Hier merken Sie schnell, ob das für Sie reicht oder nicht.

Zeitpunkt für das Backlog Refinement

Das Backlog Refinement ist eine entwicklungsbegleitende Tätigkeit und hat keinen festen Platz, wie ein Event in Scrum. Schauen wir uns einmal die Möglichkeiten an, wo und wie das Backlog Refinement am besten untergebracht werden kann.

Backlog Refinement als Entwicklungsbegleitende Aktion

Scrum EntwicklungsteamIch persönlich finde es prima das Backlog Refinement entwicklungsbegleitend durchzuführen. Achten Sie aber auch hier auf Ihre Rahmenbedingungen, wenn sich Anforderungen nicht zu schnell ändern, dann wählen Sie die Frequenz mit Bedacht.

Backlog Refinement zwischen Sprint Review und Sprint Planning

Sprint ReviewJe nach Sprintlänge kann das Refinement auch direkt nach dem Sprint Review durchgeführt werden. Dann haben Sie zum nächsten Sprint Planning bereits alle aktualisierten Anforderungen vorliegen. Nach dem Sprint Review ist ein guter Zeitpunkt das zu tun, denn wenn die Teams vorgestellt haben, was sie gemacht haben, können Product Owner und Stakeholder das Inkrement erleben und Eindrücke reflektieren.

Nicht zu unterschätzend ist der Fakt, dass sich hier bereits alle wichtigen Personen treffen und so das Backlog Refinement gemeinsam erarbeiten. Das können Sie natürlich auch im Meeting machen, oft sind dann aber nicht alle Stakeholder erreichbar.

Gute User Stories schreiben Titelbild

Gute User Stories schreiben: 10 Tipps

User Stories

Gute User Stories schreiben ist eine herausfordernde Aufgabe! Wer sich mit diesem Kommunikationsversprechen bereits einmal auseinander gesetzt hat weiß, was anfangs leicht klingt, kann ganz schön kompliziert werden. In diesem Artikel zeige ich 10 Tipps, um gute User Stories zu schreiben.

Gute User Stories schreiben ist Übung

Sie müssen bei den User Stories üben, üben, üben. Es ist zwar nicht immer leicht und nicht alle Eigenschaften ergeben sich gleich zu Beginn, die wahre Kraft um gute User Stories schreiben zu können ergibt sich aber nach mehrmaliger Anwendung. Sollten Sie vor den Tipps zurückschrecken oder diese noch nie im Zusammenhang gehört haben, dann machen Sie sich nichts draus. Ein guter Meister ist noch nie vom Himmel gefallen.

10 Tipps, die Sie zur Reflexion nutzen können!

1
Formate Retrospektive

An das bekannte Format halten!

Als <ROLLE> möchte ich <BEDÜRFNIS>, um <GRUND> - dieses einfache Format hilft Ihnen unglaublich beim Schreiben dieser User Stories. Denn so haben Sie immer den Anwender im Blick, wissen wie sein wirkliches Bedürfnis ist und kennen auch noch den Grund. Gute User Stories schreiben beginnt mit dieser einfachen Vorlage, die Sie wirklich beherrschen und anwenden können sollten.

Fragen Sie im beruflichen Umfeld bitte häufiger nach den Gründen! Das was in der User Story fast nebenläufig mit zu finden ist, hilft nicht nur hier, sondern praktisch überall. Wir tun oft zu viel, ohne die genauen Umstände zu kennen!

Auch wenn das Format an sich bekannt ist, finde ich im Scrumumfeld gerne auch die ein oder andere User Story die zum Beispiel nicht den Grund enthält. Was zunächst irrelevant aussehen kann, entpuppt sich aber nicht selten als ernstzunehmendes Problem!

2
Gute User Stories schreiben

Card, Conversation & Confirmation

Verstehen Sie die User Story mehr als nur die typische Karte, angepinnt an einer Wand. Denn das ist lediglich einer der drei ursprünglichen Bereiche, die die User Story abbilden kann.

  • Card: die typische Karte, die wahrscheinlich jeder kennt. Der Inhalt dieser Karte ist unter Punkt 1 aufgeführt. Das repräsentiert das typische User Story Format.
  • Conversation: das Kommunikationsversprechen, das zusichert, zu geeigneter Zeit über diese Karte zu sprechen. Die User Story ist also immer verhandelbar und keine Spezifikation, die bereits bis ins Detail ausspezifiziert ist.
  • Confirmation: Das ist der Akzetanztest für die Karte. Hier muss der Product Owner die Erwartungshaltung ausdrücken, die er mit dieser User Story verbindet. Diese eigenen sich auch als gute Testgrundlage oder als Basis für das Schneiden der User Stories.

Fragen Sie im beruflichen Umfeld bitte häufiger nach den Gründen! Das was in der User Story fast nebenläufig mit zu finden ist, hilft nicht nur hier, sondern praktisch überall. Wir tun oft zu viel, ohne die genauen Umstände zu kennen!

Jon Reffies hat dazu einen guten Artikel geschrieben, der lesenswert ist!​

3
Teamdynamik

Den Benutzer nie aus dem Blick verlieren!

Es passiert schnell, den eigentlich Anforderer zu vergessen! Gute User Stories schreiben sich aber leider nicht ohne den Benutzer. Dieser wird gerne einmal in der Diskussion vergessen. Überlegen Sie immer für wen Sie gerade etwas umsetzen wollen. Es gibt dabei immer einen Anwender, der genau diese Anforderung auch haben möchte.

Arbeiten Sie hier mit Personas. Gute User Stories schreiben bedeutet auch immer seinen Anwender zu kennen! Wenn Sie einmal der Meinung sind, es gibt keinen Anwender, dann arbeiten Sie sich an die Wurzel der Anforderung zurück. Woher kommt diese? Wer hat diese gestellt?

Personas helfen Ihnen ein klares Bild über Ihre Zielgruppe zu bekommen.​

4
Archivierung der Retrospektive

INVEST-Kriterien bei User Stories beachten!

Die sechs INVEST Kriterien helfen Ihnen eine gute User Story zu schreiben. Denn das INVEST Akronym gibt an, wie eine User Story sein sollte.

  • Independent (User Stories sollen nicht von einander abhängig sein)
  • Negotiable (User Stories sollen verhandelbar sein)
  • Valuable (User Stories haben immer einen (Mehr)wert und sind nicht Mittel zum Zweck!)
  • Estimated (User Stories sollen eine Abschätzung haben)
  • Sizable (Eine User Story hat immer die richtige Größe, damit sie auch in einem Sprint bearbeitet werden kann)
  • und Testable (Durch Tests kann eine User Story überprüft werden)

Auch das bietet einen perfekten Anhaltspunkt, gute User Stories zu schreiben.

5
Daily Scrum Kommunikation

Über die User Story diskutieren!

Eine User Story ist immer nur ein Kommunikationsversprechen, welches auch eingelöst werden muss. Das ist eines der drei C's (Communication) einer User Story. Mit dem Kunden und / oder dem Product Owner sollte diese Diskussion geführt werden.

In meinen Augen sprechen wir zu wenig und diskutieren auch zu wenig über Anforderungen. Durch das Kommunikationsversprechen und die nicht komplett fertige Story werden Sie dazu praktisch gezwungen - und das ist auch gut so!​ Fühlen Sie sich frei und diskutieren Sie! Natürlich erst zu dem Zeitpunkt, wenn Sie diese Story auch umsetzen wollen.

6
Akzeptanzkriterien

Akzeptanzkriterien beachten!

Anhand der Akzeptanzkriterien wird das dritte der drei C's einer User Story adressiert: Confirmation! Sie können diese Kriterien immer nutzen, um zum einen die Erwartungshaltungen zu treffen und zum anderen auch die Story zu testen (was oft mit dem ersten Punkt einher geht).

Gute User Stories schreiben bedeutet sich genau hier ausreichend und präzise genug Gedanken zu machen​. Konzentrieren Sie sich als Product Owner hier auf das WAS. Versuchen Sie nicht die Lösung in die Akzeptanzkriterien zu legen.

Beispiel: um von Ort A nach Ort B zu gelangen können Sie heute schnell mit dem Auto sein. Allerdings wäre das Akzeptanzkriterium "Reisemittel ist ein Auto" schon die Lösung. Gehen Sie davon weg und beschreiben Sie wichtige Zeiten oder Umstände (z.B. sehr komfortabel), um die Erwartung zu treffen.​

7
Daily Scrum Kommunikation

Vertikal statt horizontal!

Gute User Stories schreiben bedeutet, sich auch mit der ursprünglichen Intention und dem Durchstich zu befassen. Versuchen Sie die User Story immer so zu schreiben, dass der funktionale Durchstich durch das System gewährleistet ist. Wenn Sie die User Stories horizontal der Wertschöpfungskette schneiden, gewinnen Sie wenig zu anderen Vorgehen!

Beispiel: Versuchen Sie nicht zuerst einen Login Screen zu vergolden und dann die Datenbankanbindung als nächsten Schritt zu implementieren. Dadurch steuern Sie auf das Problem zu, dass das eine nur mit dem anderen genutzt werden kann. Schaffen Sie den Login Screen nicht, können Ihre Stakeholder nichts sehen. Setzen Sie das Konzept des vertikalen Durchstichs ein und machen Sie immer ein wenig von allem, aber immer erlebbar.​

8
Daily Scrum Kommunikation

User Stories aufteilen!

Wenn die User Story einmal zu groß wird und im Sprint nicht bearbeitet werden kann, dann hilft die Aufteilung! Die Aufteilung wird immer dann interessant, wenn das Team zu hohe Story Points schätzen lässt. Die Aufteilung können Sie im ersten Schritt immer anhand der Akzeotanzkriterien vornehmen. Sollte das mal nicht klappen, fragen Sie Team und Product Owner nach einer gute Lösung.

Ist noch zu wenig bekannt und das Team kann keine Lösung finden, dann schlagen Sie eine Analyse / Spike etc. vor​. Das wird benutzt um mehr Gewissheit über bestimmte Sachverhalte zu bekommen.

9
Daily Scrum Kommunikation

User Story mal gemeinsam im Expertenteam lösen!

Bei Ihnen arbeiten auch nur Experten und nicht jeder kann alles? Dieses gern genommene Argument mit Scrum nicht erfolgreich arbeiten zu können, nutzen Sie am besten im nächsten Experiment, in dem Sie gerade die verschiedenen Personen - die Experten sind - einmal gemeinsam versuchen lassen eine User Story lösen zu lassen.

Oft meinen die Experten, sie können weder die anderen Stories schätzen noch an ihnen mitarbeiten. Schlagen Sie das Experiment vor, dass im nächsten Sprint mal etwas neues ausprobiert wird. Bringen Sie zwei Personen zusammen, die gemeinsam an einer Story arbeiten, die es sonst nie getan hätten. Reflektieren Sie dann in Retrospektiven!

10
Daily Scrum Kommunikation

Einfach mal die User Story weglassen!

Auch wenn der zehnte Tipp vielleicht komisch klingt, probieren Sie doch einmal die User Story wegzulassen! Wenn Sie dieses Format nicht mehr nutzen, geht es Ihnen dann besser? Vermissen Sie dann einen entscheidenen Teil?

Probieren Sie es aus und machen Sie ein Experiment, analysieren und bewerten Sie es doch in einer der nächsten Retrospektiven!

Gute User Stories schreiben endet natürlich nicht mit diesen zehn Tipps. Durch die Erfahrung wird es Ihnen erst möglich, Ihren eigenen Stil zu verbessern und effektiver zu sein. Probieren Sie und reflektieren Sie, zum Beispiel in Retrospektiven!

Wie sieht es mir Ihren Tipps aus? Was hilft Ihnen, was hat Ihnen geholfen? Freue mich auf Ihr Feedback!

1 Retrospektive Titelbild

15 Minuten Retrospektive Format

15 Minuten Retrospektive

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

Was braucht es?

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

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

Mehr benötigt es an Vorbereitung und Materialien nicht.

Wie funktioniert die 15 Minuten Retrospektive?

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

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

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

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

Die Kernfrage (gather data)

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

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

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

Die Detallierung und konkrete Aufgaben (generate insights)

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

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

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

Abschluss (close retrospective)

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

Was am Ende noch passieren kann:

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

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

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

Definition of Ready

Wir brauchen keine Definition of Ready

Die Definition of Ready

Definition of ReadyDie Definition of Ready gibt an, ab wann ein Product Backlog Item in das Sprint Planning gelangen darf. Dabei ist diese Vereinbarung zwischen dem Product Owner und dem Entwicklungsteam getroffen. Stellen wir uns diese Vereinbarung einfach als Checkliste vor, ähnlich wie auch die Definition of Done eine solche Checkliste repräsentiert.

In dieser Definition of Ready könnte stehen, dass alle Einträge klein genug sein müssen, damit sie in den Sprint aufgenommen werden dürfen. Hier könnte auch enthalten sein, dass alle Product Backlog Einträge (PBIs) einmal in einem Refinement gewesen sein müssen bevor sie in den Sprint gelangen können. Je nach Rahmenbedingungen oder auch der Branche in der das Team arbeitet, könnten auch benötigte Unterlagen wie Mock-Up’s dort zu finden sein.

Kurz um, alles das, was das Entwicklungsteam benötigt, um an dem entsprechenden PBI arbeiten zu können, ist in dieser Definition of Ready enthalten.

Die Definition of Ready findet sich nicht im Scrum Guide

Wer sich den Scrum Guide genauer ansieht stellt schnell fest, das dort keine Definition of Ready enthalten ist. Warum ist das so? Ist die Definition of Ready vielleicht einfach vergessen worden? Ich denke nicht und glaube dafür gibt es einen sehr guten Grund.

Ich habe allerdings selbst lange mit dieser Vereinbarung gearbeitet. Das Ergebnis war rückblickend nicht so hilfreich, wie zunächst gedacht. Ich stelle diese Erfahrung un den Zusammenhang in diesem Artikel vor.

Betrachten wir dazu das Ziel einer Definition of Ready. Wenn ein PBI in den Sprint aufgenommen werden kann, dann ist das PBI auch ready, denn das Entwicklungsteam kann damit arbeiten. Wenn das PBI nicht fertig ist, dann kann das Entwicklungsteam folglicherweise nicht damit arbeiten. Also lautet das Ziel einer Definition of Ready, dem PBI zu bestätigen, jawohl du bist weit genug ausgearbeitet, du darfst in den Sprint!

Die Definition of Ready ist das Refinement

Die Aussage, ob ein PBI in den Sprint darf oder nicht wird im Refinement getroffen (und das finden wir auch wieder im Scrum Guide). Das Entwicklungsteam und der Product Owner arbeiten so lange an den Einträgen, bis sie klein genug sind, abgeschätzt und mit Akzeptanzkriterien versehen sind. Wenn damit alle Beteiligten das gleiche Verständnis haben, dann ist das Product Backlog Item reif genug und darf damit in den Sprint Einzug halten (wenn es das Team basierend auf der Priorität des Backlogs auch zieht).

Dadurch wird ein PBI so lange verfeinert, bis es automatisch in den nächsten Sprint kann. Wenn ein Team zum Beispiel nicht in der Lage ist ein solches Product Backlog Item abzuschätzen, dann kann es auch nicht fertig sein. Damit ist das Ziel auch nicht erreicht, dass das Backlog Item in den nächsten Sprint kann.

Formalitäten hin oder her

Versuchen Sie zunächst nicht die Definition of Ready in den Vordergrund zustellen. Etablieren Sie eine gute Kommunikation im Sinne der Scrum Events über die Product Backlog Einträge und führen Sie diese so zu einer Reife die es erlaubt, die Product Backlog Items in den nächsten Sprint zu nehmen.

Wenn es zwischen dem Entwicklungsteam und dem Product Owner Spannungen gibt, dann finden sich häufiger Definition of Readys – so meine Erfahrung. Wenn die Entwicklungsteams und der Product Owner ein gutes Verhältnis haben, dann gibt es entweder auch eine Definition of Ready, die eher im Sinne einer Checkliste (Haben wir denn auch an alles gedacht) genutzt wird und nicht als hartes Entscheidungskriterium. Oder es gibt sie eben gar nicht mehr, die Definition of Ready.

Grundsätzlich mein Tipp: genau der Argumentation bei dem Wunsch der Definition of Ready zuzuhören. Es kann durchaus ein Zeichen dafür sein, dass es Probleme in den Teams gibt. Im vierten Prinzip des agilen Manifest finden wir die Aussage

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Agiles Manifest

Wenn Sie eine Definition of Ready brauchen, prüfen Sie doch einmal, wie gut Sie dieses Prinzip aus dem agilen Manifest umgesetzt haben. Ist es hier vielleicht auch so, dass zu wenig Zusammenarbeit zwischen den Parteien erfolgt?

User Stories und die Definition of Ready

Zu guter Letzt: Es gibt immer Rahmenbedingungen, die dazu führen können, dass eine Definition of Ready sinnvoll ist. Oft mag es auch helfen, dort gewisse Standards als Erinnerungen abzulegen. Was es nicht sein darf und nicht soll: ein Ersatz für die oben genannte Kommunikation zwischen den Fachexperten und Entwickerln.

Bei meinen ganzen Betrachtungen bin ich davon ausgegangen, dass wir User Stories benutzen. Das müssen Sie natürlich nicht tun und können auch andere Notationsformen verwenden. Eine User Story ist nicht Teil des Scrum Guides und nicht verpflichtend für Scrum. Bei der Benutzung von User Stories wollen wir uns allerdings daran erinnern, dass diese keine Requirementsartefakte sind. Mike Cohn hat es in seinem (englischsprachigen) Blogposting einmal sehr treffend und schön formuliert.

Viele Publikationen die auf die Definition auf Ready eingehen, bewerten diese oft anhand von Kriterien des IEEE Standards im Bereich von Qualität und Anforderungen. Das können Sie natürlich tun, dann dürfen Sie sich aber nicht auf User Stories beziehen, denn genau dieses  Kommunikationsversprechens ist ja genau kein Requirementsartefakt.

User Stories sollten dem INVEST Prinzip folgen, das bedeutet sie sollen unabhängig (independent) von einander sein, verhandelbar (negotiable) bleiben, einen (Mehr)wert haben (valuable), abschätzbar (estimatable) sein, die richtige Größe (size) besitzen und ebenso auch testbar (testable) sein. Das eignet sich bestens als Vorlage und kann dann bei nicht erreichen in der Retrospektive genutzt werden, um zu reflektieren.

Definition of Ready vs. Definition of Done

Definition of Ready

Definition of Ready

Einhaltung durch den Product Owner

Bestimmt wann PBI in den Sprint darf

Liste von Kriterien

Definition of Done

Definition of Done

Einhaltung durch das Team

Bestimmt wann ein PBI fertig ist

Liste von Kriterien

Definition of Ready beschreibt keine Anforderungen an Requirements

Zum Schluss möchte ich die Wichtigkeit adressieren genau auf den Inhalt des Product Backlogs zu schauen. Wenn dort User Stories enthalten sind und auch diese so genutzt werden, wie es gedacht ist, dann kann die Definition of Ready in meinen Augen in vielen Situationen weggelassen werden.
Wenn Sie allerdings eine andere Art von Product Backlog Items führen, dann kann es durchaus der Fall sein, dass Sie die Definition of Ready sinnvoll und teil vielleicht sogar absolut nötig sein.

Scrum Spezifikation: das sind die Fehler!

Scrum Spezifikation?

Scrum Spezifikation

Eine Spezifikation kennt so ziemlich jeder, der sich mit Entwicklung von Produkten befasst. Eine solche Spezifikation beschreibt auf einem sehr detaillierten Level, wie etwas umgesetzt werden soll. Im agilen Projektmanagement Scrum kennen wir das so nicht, aber wie reagieren denn Teams, die von klassisch zu Scrum wechseln? Werfen Sie Ihre Spezifikationen weg? Nein, in der Regel stehen alle vor dem gleichen Problem - sie versuchen die Spezifikation in Scrum abzubilden und scheitern mit einem Wasserfall-Scrum. Einiges im Umgang von Spezifikationen und Scrum in diesem Artikel!

Was ist diese Spezifikation?

Wir finden dazu schnell und abstrakte Hilfe bei Wikipedia. Deshalb erspare ich mir die Details, aber ich denke ich spreche vielen aus der Seele, dass es genau die Dokumente sind, die gerne in einem Office-Schreibprogramm verfasst werden und zahlreiche Elemente und Informationen enthalten. Schnell sind mal 20, 30, 50 oder noch mehr Seiten dazu gekommen. Zudem folgenden ganze Glossare, was denn die einzelnen Begriffe überhaupt bedeuten. Um so ein Dokument ansatzweise zu lesen, ist ein 2-Stunden-Termin im Nu vorbei.

Was passiert in Scrum mit Spezifikationen?

Nicht wenig Teams, die ich in meiner Laufzeit betreut und gesehen habe, starten bei einer Einführung von Scrum immer nach dem folgenden Muster: Wir zerlegen einfach diese Spezifikation in kleinere Teile. Das wird dann gerne auch mal User Story genannt, wobei der Name und die Art keine Rolle spielen.

Wenn die Teams wenig oder keine Erfahrung mit Scrum haben, ist das verständlich. Deshalb findet sich das Muster der Scrum Spezifikation oft dann, wenn die Rahmenbedingungen einer Transition nicht klar sind oder die Grenzen in der Organisation (noch) nicht abgesteckt sind.

Das Team muss sich dann oft den Anforderungen stellen, mit denen es sonst auch arbeitet. Und das ist und bleibt oft die Spezifikation. Ein Vorgehen ist dann in etwa das folgende:

  • Die Spezifikation wird gelesen und der (angehende) PO oder gerne auch der Projektleiter teilt dann die Themen darin auf, er weiß wer das umsetzen kann und verteilt.
  • Diese Aufgaben werden dann in einem der nächsten Sprints versucht umzusetzen.

So funktioniert Scrum aber nicht

So gerne ich trotzdem mit solchen "Scrum Spezifikation"-Teams arbeite und den A-ha-Effekt dieser Teams  erlebe: genau damit steht die Einführung von Scrum unter einem schlechten Licht. Es kann nämlich nicht funktionieren, da die folgenden Dinge auf dieser Ebene immer passieren:

  • Das Team bekommt in dem beschriebenen Fall das WIE vorgegeben und bestimmt es nicht selbst! Zudem muss es sich damit auf eine fremde Lösungen noch committen. Die Motivitaion für ein Team als "verlängerte Werkbank" zu dienen ist nicht gerade hoch.
  • Diese Spezifikation so aufzuarbeiten, dass es im Refinement oder gar im Planning ansatzweise durchgesprochen werden kann ist aufgrund der Länge nicht möglich und verschlingt massiv Zeit!
  • Oft resultieren Fehler aus der Spezifikation, da das WIE so detailliert und verwirrend in "Spezifikationsdeutsch" formuliert wurde, damit sich jede Partei absichert. Dann werden diese Fehler diskutiert und hin und her geschobene, statt Mehrwert für den Kunden zu schaffen.
  • Die Spezifikation wird einfach in kleine Teile geteilt und dann als Aufgaben oder User Stories in den Sprint geschoben. Das kann man machen, ist dann halt Sch... 🙂 Damit fokussieren wir kein Produktinkrement am Ende des Sprints und damit nehmen wir dann auch keinerlei Produktrisiko mehr aus dem Projekt, denn es wird eh alles nur nach dem X. Sprint fertig.
  • Die Scrum Meetings werden plötzlich unglaublich lange und komischerweise dauern die viel länger als im Scrum Guide steht 😉 Ja natürlich, Scrum ist als Framework sehr effektiv. Die Effizienz muss jeder selbst in den Prozess bekommen. Wenn ich aber das falsche im Termin noch so effektiv mache, bringt das dem Projekt rein gar nichts.

Zusammenfassend: die Scrum Spezifikation gibt es nicht und das hat seinen guten Grund. Teams, die im Übergang von einem klassisch geprägten Umfeld, hin zu einer agilen sind, können dem Problem gegenüberstehen. Auch dann hilft nur: verbessern Sie sich immer kontinuierlich. In Scrum machen Sie das mit der Retrospektive, ist die Zeit einmal sehr knapp, probieren Sie doch unterschiedliche Formate der Retrospektive.