Der Product Owner ist eine wichtige Rolle in Scrum. Ich habe eine Checkliste für diese Rolle erstellt, die auf die wichtigsten Themen für den Product Owner eingeht. In diesem Artikel können Sie sich diese Checkliste kostenlos herunterladen. Dabei ist die Checkliste recht kurz und einfach gehalten und besteht aus den aus meiner Sicht wichtigen Eigenschaften, die sowohl im Backlog als auch im Backlog Refinement relevant sind. Für mich haben sich bei vielen Implementierungen von Scrum immer wieder ähnliche Stolpersteine bei Scrum Events und Probleme bei der Rolle Product Owner und dem Artefakt des Backlogs gegeben.

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!

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. Denn da kommen die Anforderungen, die sonst auch kommen und müssen schließlich gemacht werden. 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.

Wer schon einmal in einem größeren Unternehmen gearbeitet hat, der kennt durchaus Mitarbeiterziele. Die einen lieben sie, weil diese Ziele einen nicht gerade geringen Teil Ihrer Lohnzahlungen ausmachen. Die anderen hassen sie, weil diese Mitarbeiterziele für sie (mit Absicht oder ohne) gar nicht erreichbar sind. Wenn wir uns agile Teams ansehen, dann kann das Thema der Ziele schon sehr spannend sein und einen nicht geringen Einfluss auf die Motivation der Teams haben.

Die erste Frage sollte immer lauten, warum gibt es Mitarbeiterziele? Hier existieren grundsätzlich noch sehr tailoristische Ansätze und das Denken, das Menschen überwiegend durch Geld zu motivieren sind. Das nennt man auch extrinsische Motivation und ist heute eher ungern gesehen, gerade wenn es um neuartige Dinge und Themen geht, die ein Team entwickeln soll.

Im Trend liegt klar die instrinsische Motivation, also der Antrieb aus den Teams selbst heraus. Was der ein oder andere Manager gerne als Kinderkram abtut, setzt sich aber nach und nach durch. Wenn Unternehmen keine spannenden Aufgaben und Projekte haben, werden sich auch keine schlauen und innovativen Teams drumrum ansiedeln.

Soviel zur kurzen Einführung. Ich möchte nun etwas genauer beleuchten was bei Teams Ziele bewirken können und was dann passiert.

In der Vergangenheit sehe ich mehr und mehr Unternehmen, die Ziele in drei Gruppen aufteilen. Dazu gehören in der Regel Unternehmensziele, auf die der Einzelne keinen Einfluss hat. Dann gibt es eine weitere Ebene der Ziele, die sich oft auf Abteilungen oder Bereich im Unternehmen beziehen, in denen der Mitarbeiter zugehörig ist. Diese Ziele kann er zum Teil beeinflussen. Dann gibt es persönliche Ziele, die der Mitarbeiter direkt in der Hand hat.

Da wir in Teams davon ausgehen, die wir auch eine Leistung gemeinsam erbringen, macht es bei agilen Teams auch Sinn, Ziele für die Teams zu vergeben und nicht für die einzelnen Individuen. Das impliziert nämlich sofort wieder, dass einzelne Ziele mit denen der Gruppe konkurrieren können oder sogar gar nicht passen.

Ziele dürfen nicht trivial zu erreichen sein, müssen aber ebenso der Realität und den Rahmenbedingungen des Teams entsprechen. Bekommt das Team Ziele auf die es keinen Einfluss hat, dann ist das zunächst einmal demotivierend. Wird der Sinn von Zielen nicht durch das Team gesehen, ist das ebenso demotivierend. Ist das ganze Warum nicht klar und mit den nicht Zielen in Einklang gebracht, dann ist das noch mehr - Sie ahnen es schon - demotivierend. Weshalb ich jetzt so auf der Motivation rumhacke ist der eingangs erwähnte Zusammenhang zwischen intrinsischer und extrinsischer Motivation. Wenn wir unrealistische Ziele haben und extrinisch motivierbar sind, dann ist die Konsequenz, dass das Team versuchen wird, diese Ziele irgendwie zu erreichen. Es geht schließlich "nur" um das Geld. Es ist unerheblich, ob das Team selbst die Ziele erreichen kann oder andere Personen für das eigene Erreichen dieser Ziele benötigt werden. Im schlimmsten Fall wird das eigene Ziel erreicht und andere Arbeiten, die nicht dem Ziel untergeordnet sind, fallen hinten runter. Diese Arbeiten können aber sehr essentiell wichtig sein.

Anders verhält es sich, wenn das Team intrinsisch motiviert ist. Dann passiert nämlich mit unrealistischen Zielen folgendes: Zum einen werden diese schlicht nicht in den Fokus gestellt und sind damit auch nicht mehr ein Fokus in der täglichen Arbeit. Zum anderen werden diese Ziele viel mehr hinterfragt. Natürlich ist das Hinterfragen erst einmal sehr gut. Mehr als häufig habe ich aber schon erlebt, dass von diesen Zielen - gerade wenn sie nicht wirklich erklärbar sind - seitens des Management (oder denjenigen, die sie vergeben) nicht abgerückt wird. Die eine Abteilung gibt es aus, die anderen Abteilungsleiter müssen es der Hierarchie entlang übernehmen. Ein Einfluss oder ein änderndes Gespräch findet selten statt. Wenn Ziele geändert oder zurückgenommen werden müssen, gleicht das einem Gesichtsverlust oder Zeichen von Schwäche.

Ich persönlich finde, dass die Teamziele sich immer auf das Team beziehen müssen. Es hilft nichts, dem Team Ziele zu geben, die es nicht in der Hand hat - zumindest nicht alle. Wenn wir Teamziele ausgeben, dann sollten die sich natürlich erreichen lassen und auch das Team an der richtigen Stelle motivieren. Ich finde zum Beispiel Ziele gut, die sich an der Retrospektive orientieren. Wenn das Team regelmäßig Dinge identifiziert, die sich verbessern lassen und diese auch umsetzt, hilft das in meinen Augen beiden Seiten. Dem Team, da es konkrete Umstände, die nicht optimal sind erkennt und dann auch abstellt. Zum anderen natürlich der ganzen Organisation, da sich diese kontinuierlich verbessert. Ich bin der festen Überzeugung, dass das Streben nach besseren Zuständen für beide Parteien eine Win-Win-Situation ist. Ich bin aber auch überzeugt, dass es in viel zu vielen Unternehmen keine Anwendung findet.

Wenn Sie Scrum durchführen, dann haben Sie ein Backlog, in dem Sie alle Anforderungen sammeln. Das ist die Regel und stellt Ihr einziges Artefakt dar, in dem sich die Anforderungen befinden. Jetzt lässt sich schon vermuten, dass es alleine mit dieser Liste nicht getan ist, sondern etwas mehr benötigt. Dieses "etwas mehr" ist mit Sicherheit auch das Backlog Grooming bzw. das Backlog Refinement. Wie Sie dieses Backlog Refinement richtig durchführen, zeige ich Ihnen in diesem Artikel.

Wie auch immer Sie das Kind beim Namen nennen, es macht keinen Unterschied in dem, was Sie tun müssen. Dadurch, dass wir Anforderungen sammeln und diese Anforderungen über die Zeit veränderlich sind, sich Wünsche von Kunden ändern und wir einfach während der Entwicklung mehr dazu lernen, ist es nur logisch, dass sich Anforderungen ändern werden. Da wir die Anforderungen im Backlog festhalten, unterliegt das Backlog einem ständigen Wandel. Das Backlog lebt. Das Backlog Grooming bezeichnet das Erweitern, Verfeinern, Klären von Fragen, Abschätzen, etc. - kurz alles, was Sie benötigen, um das Backlog aktuell zu halten.

Im Grunde läuft das Backlog Grooming sehr ähnlich und immer wieder gleich ab. Es gibt drei Schritte, die zu jedem erfolgreichen Backlog Grooming gehören. Zum einen geht es darum große Aufgaben zu verkleinern: das Schneiden. Das müssen die neuen Einträge natürlich in irgendeiner Art und Weise in der Größe bestimmt werden: das Schätzen. Ebenso muss der Product Owner natürlich eine Vorstellung davon haben, gegen was diese Einträge getestet bzw. abgenommen werden können: die Akzeptanzkriterien.

Um zunächst ein Gefühl zu bekommen, wie lange das Backlog Refinement dauert, lohnt sich der Blick in den Scrum Guide. Hier findet sich eine recht Pauschale Antwort, dass das Grooming nicht länger als 10% der Kapazität des Entwicklungssprint einnehmen darf. Das Vorgehen, an dem Sie sich orientieren können ist das folgende: Der Product Owner stellt das entsprechende Product Backlog Item (User Story) vor. Es empfiehlt sich, das Item laut vorzulesen. Dieses impliziert, dass sich natürlich der Product Owner schon Gedanken zu dem entsprechenden Eintrag gemacht hat. Je reifer das ist, desto schneller wird das Team diese Einträge durchsprechen können.

Das Team kann dann das Item kurz auf sich wirken lassen und Fragen stellen. Ich habe die Erfahrung gemacht, dass in der Regel 10 bis 20 Minuten Zeit dafür anfallen. Das ist aber ein Wert, der sich im Team einspielen muss und auch wird. Nachdem die Fragen geklärt sind, schätzt das Team das Item ab. Auch hier noch einmal der Hinweis, dass sich die Komplexität mit absoluten Werten besser eignet, als aufwandsbezogene Schätzungen. Danach wird das Item im Backlog aktualisiert und dann zum nächsten übergegangen. Das lässt sich dann wiederholen, bis die Timebox beendet ist.

Die Dauer des Backlog Refinements ist unterschiedlich und nicht selten kommt es mal vor, dass es (gerade zu Beginn) aus dem Ruder läuft. Das ist ganz natürlich und jeder möchte gerne seine Sichtweise mit einbringen. Fragen Sie sich, wenn die Zeit aus dem Ruder läuft, die folgenden Fragen:

• Ist der Product Owner vorbereitet in das Refinement Meeting gekommen?
• Versteht das Team die Business Domain?
• Ist das Team in der Lage grundsätzlich Lösungen für das Problem anzubieten?
• Sind die Aufgaben überschaubar?

Nehmen Sie diese Fragen auch gerne mit in die Retrospektive und fragen Sie sich, wie der Ablauf noch weiter verbessert werden kann.

Release Planning in Scrum ist eine entscheidende Tätigkeit, um eine Aussage darüber zu bekommen, welche Funktion wann erlebbar ist. Das wird - wie in Scrum üblich - so einfach wie möglich aber so genau wie nötig vorgenommen. Es gibt auch hier keine Lösung, die auf alle Situationen passt, es gibt aber einen ersten Ansatz, der verfeinert werden kann. Diesen Ansatz möchte ich im Folgenden nun einmal vorstellen. Zunächst gehe ich auf ein paar Grundlagen des Release Plannings / der Release Planung ein.

Sprints kennt jeder, der mit Scrum einmal gearbeitet hat. Diese Iterationen haben das Ziel, ein sogenanntes potentiell ausieferbares Produktinkrement zu erzeugen. Jedes Mal, wenn Sie Working Software (siehe agiles Manifest) an den Kunden ausliefern ist das in der Regel ein Release, also die veröffentlichte Software. Entscheidend ist bei der Betrachtung des Release immer die Definition of Done für ein Release. Das bedeutet, dass Ihr Release nicht fertig ist, ohne das Sie Tests durchgeführt haben und weitere Kriterien, die Sie dazu bereits im Vorfeld des Releases festgelegt haben. Ebenso sollten Sie beachten, dass Sie ein erlebbares Release für den Kunden haben, dieser also auch etwas mit diesem Release anfangen kann. Im besten Fall ist das Release das Inkrement, ansonsten wird eine bestimmte Summe von Inkrementen zu einem Release führen.

Am besten nutzen Sie dazu das Story Mapping. Für mich ist das eine einfache Methode, die verschiedene Vorteile bietet. Zum einen ist sie sehr einfach und kann sehr schnell erstellt werden. Zum anderen können Stakeholder immer sehen, was auf einer abstrakten Releaseebene geplant ist und müssen sich nicht im Backlog umschauen. Für das Story Mapping habe ich bereits einen Artikel verfasst, der tiefer in die Details einsteigt. Zudem können Sie meinen Onlinekurs Story Mapping - agil Anforderungen erheben auch bei Udemy belegen.

Die Release Planung ist eine Stufe in der Planung die Sie zwischen der Vision und der Sprint Planung recht gut anwenden können. Ich konnte damit ganz gute Erfahrungen sammeln und es hat sehr bei der Übersicht geholfen. So haben auch die Stakeholder und Product Owner immer das Gefühl die Übersicht zu behalten.

Zu beachten ist hier natürlich der Kontext des Projektes: ist das Projekt so umfangreich, dass Sie diese Planung benötigen?

Für eine Release Planung in Scrum gibt es einige Voraussetzungen, die Sie erfüllen müssen.

Sie benötigen eine Velocity im Scrum Team, die eine gewisse Stabilität hat. In der Regel ist das in drei bis vier Sprints der Fall. Es lohnt sich also, diese Sprints abzuwarten. Wenn Sie diese Zeit nicht haben, können Sie mit anderen Erfahrungen oder Durchschnittswerten experimentieren, sollten diese aber nach der oben besagten Zeit unbedingt wieder anpassen und überprüfen. Überhaupt muss eine Releaseplanung häufig überprüft werden. Zudem brauchen Sie eine Aussage über die Größe von dem, was Sie schätzen. Wenn Sie Scrum mit User Stories durchführen, dann sind das die Größe der User Story. Zuletzt ist wichtig, welche Rang die User Story im Backlog einnimmt (Priorität!)

Scrum Events sind zentrale Stellschrauben für das agile Projektmanagement Framework. Obwohl so einfach, merkt man schnell, dass es nicht leicht ist. In diesem Artikel habe ich - inspiriert von einem englischen Artikel - einige meiner Erfahrungen reflektiert und größten vorgestellten Stolperfallen kommentiert.

• Der wohl häufigste Fehler aus meiner Sicht ist, dass das Daily Scrum - daher der Name - nicht täglich durchgeführt wird. Es geht aus meiner Sicht auch nicht darum ein einfaches Format oder Ritual abzunudeln, sondern sich ganz konkret auszutauschen. Kurz, knapp und selbst mit 15 Personen kann ein Daily innerhalb von 15 Minuten erledigt sein - das ist noch möglich! Auch wenn sich viele vielleicht zu Beginn noch nicht vorstellen können, dass das hilft, muss das Team das erst einmal eine Zeit ausprobiert haben. Dann kommt auch das Verständnis.

• Das Team hat das Daily Scrum für sich selbst. Es ist also kein Status Reporting an eine andere Person. Nicht der Scrum Master und auch nicht - wenn durch das Team erlaubt - andere Teilnehmer.
• Abtauchen in die Details. Dads Daily Scrum ist eine operative Synchronisation zwischen den Teilnehmern. Da geht es darum, was geschafft wurde, was ist wichtig für die anderen. An was wird heute gearbeitet? Gibt es Hindernisse? Das kann man - vorbereitet - ohne Probleme recht schnell und zielorientiert schaffen
• In meinen Augen ist es hilfreich, dass das Team das Board aktualisiert hat. Im Daily Scrum kann trotzdem jedes Mitglied über seinen Status berichten. Die Karten hängen schon dort, wo sie hingehören. Das hilft aus meiner Sicht immer in der Vorbereitung auf das Daily Scrum. Jedes Teammitglied weiß dann auch sofort wo was hing und durch das Aktualisieren hat sich jeder Mitglied auch seine Karten noch einmal angesehen. Dann ist das Daily effektiv durchführbar.
• Das Reflektieren der klassischen drei Fragen gegen das Sprintziel ist sinnvoll, um die Referenz zu haben. Dadurch ist auch das Sprintziel ein wichtiges Element, das genutzt werden sollte.

• Der Sprint hat ein Ziel, der sich in dem Sprint Ziel ausdrückt. Dafür benötigen Sie auch ein Sprint Ziel. Bei der Planung muss auch dieses Sprint Ziel vom Product Owner und vom Team im Kopf behalten werden, um alles in diesem Sprint darauf auszurichten. Eine Planung ohne dieses Ziel ist nicht angemessen.
• Für alle Beteiligten ist es wohl am schlimmsten wenn die Backlogeinträge nicht feingranular genug sind oder aber nicht genug der feingranularen Einträge vorhanden sind.

• Das Ergebnis des Sprint Plannings muss ein gemeinsames Verständnis generieren, was im Sprint umzusetzen ist. Fehlt dieses Verständnisse, wird es auch schwer etwas gutes zu erstellen.
• Der Product Owner sagt hier dem Team nicht, welche Anzahl sie schaffen müssen und auch nicht, wie etwas zuzusetzen ist.

• Im Sprint Review werden keine Aufgaben gezeigt, die nicht fertig sind. Das verschwendet nur Zeit und wird sowieso nicht abgenommen.
• Vergessen Sie hier nicht, alle möglichen Stakeholder mit einzubeziehen, die ein Feedback zu dem Produkt geben können.
• Wenn Sie das Meeting absagen wollen, weil nichts zu zeigen ist, sollten Sie sich schleunigst mit dem Scrum Master zusammensetzen und eingreifen!

• Die Retrospektive wird aus meiner Sicht zum zahnlosen Tiger, wenn keine Punkte für den nächsten Sprint zur Umsetzung mitgenommen werden. Ebenso gilt auch das Gegenteil: Es kann nicht alles im nächsten Sprint verbessert werden.
• Die Retrospektive muss an die jeweilige Sprintdauer angepasst sein, hier gibt es einige Formate und Ideen dazu.
• Gerade bei der Retrospektive - und deshalb erwähne ich die eingangs erwähnte Aussage - darf diese nie weggelassen werden. Es gibt immer etwas zu verbessern.

• Aus meiner Sicht das Schlimmste ist es, die Sprintlänge während des Sprints zu ändern. Das erzeugt nicht nur grundsätzlich Unruhe und Verwirrung, sondern auch Probleme mit Velocity & Co. sowie Synchronisation mit anderen Teams.
• Das Ende eines Sprints nicht als Ende ansehen und noch schnell eine Aufgabe auf "done" bekommen.
• Innerhalb des Sprints sollte das Team sich nicht zu viele Aufgaben parallel in die Bearbeitung ziehen, das führt zum schädlichen Multitasking.

Wenn Sie Scrum erfolgreich durchführen, dann kennen Sie die Retrospektive. Ich stelle Ihnen in diesem Artikel vier (neue) Ideen vor, wie Sie Ihre Retrospektive in Scrum durchführen können. Probieren Sie dazu einfach die folgenden (neuen) Tipps und Vorgehen aus. Wichtig hierbei ist es, sich auch bei der Retrospektive immer wieder zu fragen, ob und wie diese noch verbessert werden kann.

Die Punkte sollen sich als Gedankenanstöße verstehen, der Artikel beschreibt nicht die Durchführung einer Retrospektive in Scrum selbst. Wenn Sie grundsätzliche Literatur suchen, dann schauen Sie im Artikel meine Empfehlungen an. Die Beispiele sind willkürlich ausgewählt und zielen auf keinen bestimmten Schritt innerhalb der Retrospektive ab.

Wenn Sie kurze Sprintlängen in Ihrem Scrum haben, dann lohnt sich der Blick auf die Plus, Delta Retrospektive. Hier sammeln Sie durch Zuruf oder Erarbeitung der Punkte durch die Teilnehmer die Punkte.

Der Fokus liegt hierbei erst einmal auf dem, was gut läuft und was das Team als förderlich empfunden hat. Dann findet das Team ebenso Dinge, die nicht so optimal waren und wo das Team Verbesserungspotential sieht.

Mike Cohn hat vor kurzer Zeit auf seinem Blog einen Artikel über die Start, Stop & Continue Retrospektive geschrieben. Der hat mir gut gefallen, auch ich kenne diese Art der Retrospektive in Scrum. Hier ist der Fokus leicht anders und es wird darauf geschaut, was einem aus dem Blickwinkel einer Fortsetzung es bringen kann oder eben nicht.

Natürlich sind letztendlich die Arten der Retrospektive verschieden, aber das Ziel ist identisch. Durch die unterschiedlichen Arten werden aber andere Blickwinkel erzeugt.

Gerade wer längere Sprints macht, dem fallen die obigen Retrospektivenarten oft nicht so leicht: man muss schon ganz schön im Gedächtnis kramen, was man denn so alles für Situationen hatte. Hier hilft die Timeline oder der Zeitstrahl Abhilfe.

So lassen sich über einem Zeitstrahl die positiven Ereignisse und unterhalb des Zeitstrahls die negativen Elemente der vorherigen Integration sammeln. Dazu empfiehlt es sich noch Wochentage oder die Wochen zu markieren, um es leichter in der Zuordnung von Ereignissen und Daten zu machen. Am Ende lassen sich bspw. die wichtigen Punkte mit einem Dot-Voting (Teilnehmer priorisieren mit Punkten) heraussuchen und behandeln. Wie man die Punkte dann angehen kann ist unterschiedlich.

Sammeln Sie aus dem Gedächtnis die auffälligen Punkte aus dem letzten Sprint. Machen Sie ein Brainstorming ohne Struktur. Gehen Sie auf die Quantität der Aussagen und sammeln Sie innerhalb eines bestimmten Zeitabschnittes alles was die Teammitglieder nennen.

Ordnen Sie danach gemeinsam die Punkte in einer Eisenhower Matrix in dem Sie die Punkte nach Wichtigkeit und Dringlichkeit sortieren. Aus dem Quadranten "wichtig" und "dringend" sollte etwas im nächsten Sprint umgesetzt / verändert werden. Bei "nicht wichtig" und "dringend" kann aktiv nach Hilfe außerhalb des Teams gesucht werden. Ein Thema für den Scrum Master. Die anderen beiden Quadranten werden nicht umgesetzt oder nur betrachtet, wenn ausreichend Zeit ist.

Negatives Multitasking ist eines der größten Probleme - egal ob Sie nach Scrum, Kanban oder was auch immer arbeiten. Auch die weibliche Gattung, die immer beteuert, sie könne Multitasking, liegt falsch ;-) Scrum bringt von Haus aus schon einiges mit, damit kein Multitasking entsteht. Aber auch hier kann noch etwas verbessert werden. In diesem Artikel schauen wir uns zunächst an, warum Multitasking schlecht ist und dann, was wir in Scrum dagegen tun können.

Zunächst wollen wir klären, was ist dieses negative Multitasking überhaupt? Dazu gibt es eine Reihe von Quellen, wie Forbes, TOC4U oder auch bei Frank Lange. Kurz: je mehr Sie parallel arbeiten und anfangen, desto geringer ist das, was am Ende dabei heraus kommt. Das ist recht einfach verständlich und kann jeder nachvollziehen, der eine volle To-Do-Liste hat und nicht regelmäßig und kostant die Aufgaben ohne Unterbrechungen abarbeitet. Man wird aus einem Thema herausgerissen, muss sich in das andere Thema hineindenken. Dabei entstehen sogenannte Transaktionskosten. Diese stiehlt Ihnen wertvolle für Ihre eigentliche Arbeit, die dann natürlich zu kurz kommt. Ihr Durchsatz an Aufgaben verstopft und Sie schaffen weniger!

Betrachten wir das agile Projektmanagement Framework Scrum. Hier gibt es erstmal nicht, was nach einer Begrenzung aussieht. Je weiter wir in das agile Projektmanagement reinschauen, desto scheint sich dieser Verdacht auch zu bestätigen. Im Sprint Planning finden wir dann aber zumindest mal einen Hinweis auf die Begrenzung der Aufgaben in Summe. Das Team wählt das aus, was es im Sprint schaffen kann. Jetzt sind wir im Sprint und auf dem Taskboard. Hier gibt es unterschiedliche Implementierungen, wie Teams das hier umsetzen. Es gibt aber keine Regel, eine Begrenzung der auf dem Task Board befindlichen Aufgaben kann helfen, fokussierter zu arbeiten.

Warum finden wie die einen Produkte "sau cool" und andere nur so "naja"? Wie schaffen es einige große Unternehmen wie Google oder Apple Produkte zu releasen, die die Massen bewegen? Weil diese Produkte entwickeln, die Kunden lieben! Produkte die Kunden lieben, kann jedes Unternehmen unter bestimmten Voraussetzungen erstellen. In den letzten Jahren fand eine starke Tendenz zu neuen Methoden, Techniken, kurz benutzerzentrierten Betrachtungen statt. Wie auch Sie als kleines oder mittelständisches Unternehmen auf solche Tendenzen reagieren und diese nutzen können, zeige ich Ihnen in diesem Artikel. Zudem habe ich Kurse im Angebot, die sich genau mit dieser Thematik befassen und Ihnen helfen und Sie unterstützen.

Nicht immer haben wir schon eine Idee. Wie sieht denn unsere Aufgabenliste für das Produkt, das Kunden lieben aus? Was sollen wir denn überhaupt entwickeln? Wer hier noch keine Vorstellung hat, dem hilft es sich mit Design Thinking zu befassen. Dabei wird sich aus Anwendersicht damit befasst, wie Lösungen aussehen können, die überzeugend sind. Wenn Sie Produkte entwickeln, die Kunden lieben, dann ist das ein guter Startpunkt.

Die zentrale Frage, die wir uns hier stellen können ist, "was entwickeln wir?".

Wir bekommen also ein erstes Gespür davon, um was es geht. Was wünscht sich der (mögliche) Kunde überhaupt. Wenn Sie sich auf dieser Ebene bewegen, dann ist Design Thinking bestimmt etwas für Sie auf dem Weg, um Produkte zu entwickeln, die Ihr Kunden lieben wird!

Auch wenn ich ehrlich gesagt den Hype um das Buch Lean Start-Up ganz und gar nicht nachvollziehen kann und ich auch kaum etwas neues darin finde, hat sich der Begriff doch gefestigt. Ich konzentriere mich allerdings lieber auf Running Lean (Lean Canvas) von Ash Maurya. Letztendlich ist das aber zweitrangig, denn wer einmal das kundenzentrierte Mindset verstanden hat, für den sind Design Thinking, Lean Start-Up und Scrum sowieso Dinge mit gesundem Menschenverstand. Eine gute Grafik hat das Lean Start-Up aber dennoch hervor gebracht. Diese habe ich links selbst dargestellt und finde diese Abfolge gut. Wer genau hinsieht, der versteht hoffentlich auch, warum ich der Meinung bin, dass Scrum, Design Thinking und Lean Start-Up mal nicht so verschieden sind.

Die zentrale Frage, die wir uns hier stellen können ist, "wollen wir es entwickeln?"

Wir sind hier schon etwas weiter als im ersten Schritt und gehen nun daran, systematisch zu testen, was uns und dem Kunden etwas bringt. Dafür stellen wir eine Reihe von Hypothesen an und prüfen mit Experimenten, ob wir richtig liegen.

Scrum als agiles Projektmanagement Framework ist mein absoluter Liebling! Es ist einfach in der Übersicht aber nicht leicht in der Umsetzung. Trotzdem bietet es mit seinen drei Rollen, drei Artefakte und fünf Elementen eine Menge für die Entwicklung von komplexen Produkten an. Produkte die Kunden lieben können mit diesem Framework bestens gebaut werden. Es stellt in kurzen Iterationen den Kunden immer wieder in den Mittelpunkt und holt sich regelmäßig Feedback ein. Das Framework Scrum ist für mich die einzig wahre und logisch Art und Weise, wie ich so einen Prozess zur Entwicklung von Produkten, die Kunden lieben, nutzen kann. Dabei lege ich den Fokus gerne auf kurze Iterationen (Sprint) und eine ausgeprägt Retrospektive sowie ein gutes Sprint Review.

Die zentrale Frage, die wir uns hier stellen können ist, "wie wollen wir es entwickeln?"

Wenn wir wissen, was wir brauchen und welche Variante davon sinnvoll ist, dann kann uns Scrum mit dem wie helfen! Scrum bietet einen Rahmen mit dem Sie in der Lage sind schnell so zu entwickeln und sich Feedback zu holen, wie Sie es brauchen.

Design Thinking und Scrum können Hand-in-Hand gehen und neues Potential fördern. Wo Scrum recht einfach und abstrakt mit der Vision startet - hört Design Thinking auf. Eine Kombination beider Faktoren kann für beide Seite einen Vorteil bringen. Design Thinking erhöht die Wahrscheinlichkeit, dass das zu entwickelnde Produkt auch wirklich ankommt. Scrum kümmert sich um die eigentliche Entwicklung. Doch wenn wir noch genau hinschauen, dann sehen wir ebenso, dass sich die Vorgehensweisen recht nah beieinander liegen: es passt zusammen!

In Scrum wissen wir, es gibt einen Kunden, einen Product Owner und auch eine Vision. Abgeleitet von dieser finden sich viele Möglichkeiten zu einem Produkt zu gelangen. Doch über konkreten Wege schweigt sich auch der Scrum Guide aus - das kann er auch, denn das ist nicht seine Aufgabe.

Trotzdem müssen Sie sich als Unternehmen Gedanken machen, wenn Sie mit Scrum Produkte entwickeln. Ist die Produktentwicklung innerhalb Ihres Hauses, dann ist es für Sie ein "muss" das eben diese so zu gestalten, dass Sie Produkte entwerfen, die auch beim Kunden wirklich gut ankommen. Ist die Entwicklung nicht direkt bei Ihnen (und Sie bieten die Umsetzung als Dienstleistung an), dann ist dieser Fakt nicht immer von so zentraler Bedeutung.

Kunden sind heute anspruchsvoll und die Welt dreht sich schneller denn je. Scrum und Design Thinking sind dazu zwei sehr gute Ansätze, um Produkte zu entwickeln, die Kunden lieben. Design Thinking ist immer dann sehr hilfreich für Sie, wenn der Kunde noch gar nicht genau weiß, was er braucht. Aber auch Kunden, die bisher vielleicht schon wissen (oder glauben zu wissen) was sie wollen, kann ein Perspektivenwechsel helfen.

Wichtig ist es aber auch zu verstehen, dass der Kunde - auch wenn er immer alles vorgibt und meint nur noch die Umsetzung zu brauchen - durchaus dankbar für sinnvolle Erneuerungen ist. Oft hilft einfach eine andere Perspektive, ein anderer Blickwinkel mit Design Thinking und schon werden ganz neue Idee freigesetzt.

Ein Punkt, der sich für mich immer wieder als wichtig herausstellt ist der, zunächst erst einmal auf "sinnvolle" Ideen zu kommen - gerade abseits der bekannten Pfade. Wenn Sie also bspw. ein neues Produkt entwickeln wollen, um am Markt eine disruptive Innovation zu erzeugen, dann macht es in meinen Augen mehr Sinn, mit Design Thinking zu starten und hier sehr offen und ohne Bewertungen in die Ideenfindung zu gehen. Scrum hilft Ihnen dann dieses Produkt iterativ und inkrementell zu entwickeln. Denn auch bei dem Produkt können natürlich Änderungen eintreten und alles etwas anders aussehen.

Personas sind fiktive erstellte Personen, die eine Zielgruppe repräsentieren. In der Analyse- oder Anforderungsphase sind Personas ein wertvolles Hilfsmittel, um sich den Wünschen und Bedürfnissen der Zielgruppe zu nähern und diese besser kennenzulernen. Personas beschreiben dabei immer eine größere Zielgruppe und stehen nicht nur für eine Einzelperson. Personas sind deshalb so wichtig, weil es die Gruppe an Menschen ist, um die es bei einem Produkt geht: Ihre Kunden!

Es gibt verschiedene Handhabungen und Beschreibungen der Personas. Letztendlich kommt es immer darauf an, was Sie daraus machen. So habe auch ich meine eigene Interpretation der Personas, die sich sicher mit vielen Quellen im Internet übereinstimmt, mit anderen aber nicht. Leiten Sie einen sinnvollen und funktionierenden Prozess aus den Personas für sich ab.

Gibt es in Scrum ein WIP-Limit? Diese Frage wurde in einer Diskussion mit Kunden sichtbar. Wer Kanban nutzt weiß, dass ein WIP-Limit wichtig ist. Das WIP bedeuted work in progress und das Limit sagt aus, dass eben diese Arbeit im aktuellen Schritt limitiert wird. Damit wird vermieden, dass zu viele parallele Aufgaben in einem Schritt angefangen werden und ein negatives Multitasking existiert. Soweit so gut. Was ist mit dem agilen Projektmanagement Scrum, gibt es das hier auch? Eine Spurensuche in diesem Artikel.

Das WIP-Limit ist dazu da, parallele Arbeiten zu vermeiden. In Kanban wird pro Schritt ein Limit festgelegt und das bedeutet, dass sich nicht mehr Arbeit als angegeben in diesem Schritt befinden darf. Ganz einfach gesprochen bedeutet das, dass Sie bei einem WIP-Limit von 3, zu keiner Zeit mehr als drei Aufgaben in diesem Schritt haben dürfen. Wie das im Detail aussieht, zeigen die nächsten Abschnitte. Das WIP-Limit ist auch ein grundlegendes Prinzip von Kanban. Der dahinterliegende Gedanke ist auch für Scrum relevant.

In Kanban ist es sinnvoll jeden Schritt im Prozess zu limitieren, damit die Anzahl der Aufgaben innerhalb des Schrittes geschützt ist. Wenn wir Kanban benutzen, dann ist das für uns fast selbstverständlich ein WIP-Limit zu benutzen. Treten Blockaden auf, können wir darauf reagieren und eine Abhilfe schaffen. Der visuelle Aspekt ist nicht zu unterschätzen und das negative Multitasking das entsteht, wenn zu viele Aufgaben parallel in der Bearbeitung befinden, muss vermieden werden.

Das Daily Scrum ist eine Form des Daily Stand-Up‘s. Ein Meeting, das oft Gefahr läuft, zu einer Last zu werden. Nicht richtig durchgeführt, löst es bei den Teilnehmern Desinteresse und Ablehnung aus. Dass Daily Scrum hat eine Dauer von gerade einmal 15 Minuten. Deshalb ist Vorbereitung und Fokussierung wichtig. Technische Details und weiterführende Themen sind hier fehl am Platz. Auf was Sie achten sollten, damit Ihr Daily Scrum kein Misserfolg wird, finden Sie in diesem Artikel.

Es gibt viele Diskussionen zum Thema Management in Scrum. Die einen verteufeln es, die anderen wollen es nicht, wieder andere legen es sich immer so aus, wie sie es brauchen. Fakt ist aber, das wir immer ein Management benötigen. Es gibt viele organisatorische Themen, Rahmenbedingungen und grundsätzliche Entscheidungen in Unternehmen, die nicht im Team des agilen Projektmanagement gefällt werden (können / sollten). Dieser Artikel gibt eine Übersicht.

Es ist schon blöd - da ist das Scrum Team mit dem Scrum Master, dem Product Owner und dem Entwicklungsteam vollständig beschrieben. Einem jeden Manager wird es nun Angst und Bange - wo bitte bleiben die Manager und Führungskräfte in diesem Szenario? Während sich die Rolle des typischen Projektleiters noch auf diese drei Rollen aufteilen kann, sieht es mit dem klassischen Management etwas anders aus. Sie finden sich im ganzen Framework nicht. Doch halt, heißt das wirklich, dass wir diese nicht mehr brauchen? Nein, das heißt es nicht! Wir benötigen eine neue Sicht der Dinge.

In Scrum ist es mehr denn je wichtig, dass Sie ein Management haben. Das Management hat die Aufgabe die Rahmenbedingungen, die Plattform zu schaffen, auf der überhaupt erst möglich ist, agile Methoden wie Scrum erfolgreich durchzuführen. Es gibt nach wie vor um die Scrum Teams herum das Management, dass durch die Plattform Checkpoints etabliert, um Instabilität und Mehrdeutigkeit vorzubeugen.

Die Welt verändert sich ständig und durch Veränderungen entsteht Änderungsbedarf. Wie so oft gibt es dann Bereiche oder Disziplinen die sich dem Management dieser Bedarfe verschreiben. So ist es auch hier: Wenn Änderungen existieren, dann müssen diese verwaltet werden, was nichts anderes bedeutet, als man muss sich drum kümmern. Mit Scrum und dem Änderungsmanagement ist das nicht anders.

Änderungen im Projektmanagement sind grundsätzlich etwas ganz Normales und deuten nicht automatisch darauf hin, dass das betroffene Projekt falsch oder schlecht geplant worden ist.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Die Welt da draußen ist unbeständig und deshalb werden Änderungen immer passieren. Scrum und das Änderungsmanagement muss ebenso funktionieren, wie außerhalb von Scrum. Die Änderungen, die es auf dieser Welt gibt, sind unabhängig von dem, was Sie einsetzen. Demnach ist das auch kein Thema von Scrum. Natürlich kann Scrum aber genau auf solche Dinge eingehen. Durch das Zusammenspiel von Teams, dem Umfeld und dem Produkt entsteht eine komplexe Struktur, die Sie nie vorhersagen können. Scrum versucht das gar nicht, sondern etabliert ein kontinuierliches Änderungsmanagement, um auf die neuen Änderungen und damit Anforderungen einzugehen.

Scrum betrachtet die Wahrscheinlichkeit von Änderungen an einem Produkt bzw. in einem Projektkontext und bietet durch die Anpassung der Sprintlänge ein Instrument, um auch bestimmte Situationen eingehen zu können. Ist Ihr Projekt sehr unsicher, erwarten Sie viele Änderungen, dann ist die Wahl einer kurzen Sprintlänge sinnvoll. Damit haben Sie nach einer kurzen Zeit (zum Beispiel einer Woche) die Möglichkeit auf Änderungen einzugehen. Sind Änderungen eher unwahrscheinlich, dann können Sie längere Sprintlängen ausprobieren (zum Beispiel vier Wochen). Wie sinnvoll und erfolgreich so etwas ist, hängt von weiteren Faktoren ab, lässt sich als grober Richtwert aber benutzen.

Story Points sind ein Maß, das in Scrum häufig anzutreffen ist und in vielen Teams Verwendung findet. Anstatt in einer Zeiteinheit wie Stunden zu messen, legen Story Points den Fokus auf eine Einheit, die sich nicht direkt in der Zeit ausdrückt. Warum das hilfreich sein kann und wie Sie zu Ihren User Stories kommen, finden Sie in meinem Artikel!

Story Points ist ein Maß für die Abschätzungen von Aufgaben, oft für User Stories in der Verwendung. Dabei ist es fast unerheblich, was Sie messen. Ein Team (und ein häufig anzutreffendes Beispiel in der Realität) bestimmt als Story Points eine Art von Komplexität von einer User Story. Komplexität ist zu definieren und unterscheidet sich von Team zu Team. So wäre es denkbar, Abhängigkeiten und Neuheit in diese Komplexität einfließen zu lassen. Es wird eine Aufgabe / User Story benutzt und dazu eine Referenzaufgabe / -story bestimmt. Es wird festgelegt, dass diese Aufgabe die User Points von bspw. 5 bekommt.

Es wird oft von der Fibonnaci-Folge gesprochen, wenn es um Story Points geht. Allerdings ist die angegebene Zahlenfolge oft nicht die Fibonnaci-Folge, sondern etwas anderes. Mike Cohn war es, der die ursprüngliche Folge etwas angepasst und für die Story Points verändert hat. Das ist für die Abschätzungen ganz brauchbar und hat sich - ohne das sich die Anwender oft im Klaren darüber sind - durchgesetzt.

Die Fibonnaci-Folge ist immer die Summe zwei aufeinander folgender Zahlen. Die Folge ist nicht ganz "so hübsch", wie die von Mike Cohn: 1, 2, 3, 5, 8, 13, 20, 40, 100 (diese finden sich häufig auch auf Planning Poker Karten).

Letztendlich sind die Zahlen auch egal, hilfreich ist aber der immer größer werdende Abstand zwischen diesen. Das symbolisiert auch die typischen Schätzfehler, denen wir (nicht nur bei Story Points) unterliegen. Wenn etwas weit in der Zukunft liegt, ist es egal, ob es "100" Story Points sind oder "40" - es ist einfach zu groß, um es sinnvoll abzuschätzen.

Burn-down und Burn-up Charts sind zwei häufig verwendete Diagramme in Scrum. Sie werden beide für das Projektmanagement genutzt und treffen eine Aussage über die noch zu erledigende Arbeit. 

Sie sind damit ein prima Werkzeug, um den Projektfortschritt zu messen und zu visualisieren. In diesem Artikel betrachte ich beide Arten und stelle diese gegenüber.