Category Archives for "Scrum Events"

1 Retrospektive Titelbild

Scrum Retrospektive

Was ist die Scrum Retrospektive?

Die Scrum Retrospektive ist ein verpflichtendes Element, das der Scrum Guide für das agile Projektmanagement Framework Scrum beschreibt. In der Retrospektive reflektieren Sie bereits erlebte Situationen in Ihrem bisherigen Sprint. Die Retrospektive in Scrum erwartet aber auch, dass Sie Ihren Prozess umgehen anpassen, wenn dieses nötig ist.

Wann nutzen Sie Retrospektiven in Scrum?

Wenn Sie Scrum etabliert haben, dann gibt es genau einen Platz, an dem die Scrum Retrospektive durchgeführt wird. Wenn das Sprint Review abgehalten wurde und das Sprint Planning noch nicht begonnen hat, genau dort ist Platz für die Retrospektive in Scrum.

Vorteile der Retrospektive

Eine Scrum Retrospektive bringt eine Menge an Vorteilen mit, die ich Ihnen in der Übersicht kurz vorstelle:

  • Die Retrospektive in Scrum gibt Ihnen die Möglichkeit über Herausforderungen im Prozess zu sprechen.
  • Sie verbessern Ihren Prozess kontinuierlich und finden Optimierungspotential, wie sie Abläufe verbessern und die Effizienz erhöhen können.
  • Die Teammitglieder rücken näher zusammen und setzen sich intensiver mit dem Team als solches auseinander. Durch die Retrospektive in Scrum spricht das Team – auch kritische – Themen an und beginnt diese aktiv zu lösen.
  • Sie machen Hindernisse in Prozessen, Abläufen, dem Team und der Organisation transparent. Das ermöglicht erst die Lösung dieser Probleme, die sonst offen nicht zyklisch in Projekten angesprochen werden können.
  • Sie erlangen Wettbewerbsvorteile durch schlanke Prozesse und hoch-performante Teams.

Durchführung der Retrospektive: Die 5 Phasen

In dem Buch Agile Retrospectives von Esther Derby & Diana Larson werden fünf Phasen für die Retrospektive vorgestellt. Die meisten Retrospektiven werden nach diesem Format durchgeführt.

Die Phasen einer Retrospektive

Set the Stage

Set the Stage bei der Scrum RetrospektiveIn dieser Phase geht es darum, dass alle Teilnehmer ankommen.

Es ist wichtig, dass eine gute Atmosphäre herrscht und in der Scrum Retrospektive jeder zu Beginn etwas gesagt hat. Damit erhöht sich auch die Wahrscheinlichkeit, dass später mit diskutiert wird.

Gather Data

Gather Data in der Retrospektive in ScrumIn dieser Phase einer Retrospektive in Scrum geht es um die Sammlung von Daten aus dem letzten Sprint.

Dabei wird der Wert auf die Quantität gelegt und der Fokus aus die Menge der Fakten gerichtet, eine Auswahl und Bewertung erfolgt später.

Generate Insights

Die Scrum Retrospektive - Generate InsightsWir wollen in einer Retrospektive in Scrum immer wissen und verstehen, warum etwas aufgetreten ist. Genau dafür ist dieser Schritt gedacht.

Hier analysiert das Team mit dem Moderator die Ursachen ausgewählter Daten und versucht Einblicke über die Gründe zu bekommen.

Decide what to do

Decide what to do in der Retrospektive in ScrumIn diesem Schritt überlegen Sie, was Sie als nächstes tun wollen.

Dieser Schritt ist sehr wichtig, denn wenn Sie in der Scrum Retrospektive keine wirklichen Schritte definieren, dann verpufft die Wirkung, ohne das etwas passiert.

Close the Retrospective

Scrum RetrospektiveEine Retrospektive in Scrum wird ordentlich abgeschlossen.

Das ist wichtig, um allen Personen Respekt entgegenzubringen und die Zeit zur eigenen Reflexion der Retrospektive zu nutzen. Dieser Schritt kann kurz gehalten sein, sollte aber nicht übergangen werden.

Ihre Tipps für die Scrum Retrospektive

  1. Externe Moderation nutzen. Wenn Sie die Möglichkeit haben, dann sollten Sie die Retrospektive durch einen externen Coach leiten lassen. Wenn das für Sie keine Möglichkeit ist, dann versuchen Sie einen Kollegen aus einer anderen Abteilung zu besorgen, der Ihnen unter die Arme greifen kann. Es hilft sehr die Retrospektive in Scrum durch andere – nicht beteiligte Personen – moderieren zu lassen.
  2. Eine gute Atmosphäre schaffen Sie durch angemessene Räume und Infrastruktur. Das langweile, fensterlose Büro im 60er Jahresstil lässt Gedanken und Ideen förmlich im Keim ersticken. Oft kann ein externer Raum für wenig Geld in einer Co-Working Location gefunden werden. Die Kommunikation toppt in der Regel aber immer den Raum – wenn Sie nur auf eines Wert legen können, achten Sie auf eine gute Kommunikation.
  3. Regeln definieren und auch mal ändern. Definieren Sie gemeinsam mit Team ein Set an Regeln, an das sich alle halten wollen. Gerade wenn zwischenmenschliche Beziehungen auf der Agenda sind, ist es wichtig, dass der Prozess geordnet abläuft. Seien Sie aber nicht dogmatisch, sondern probieren aus. Ändern Sie aktiv Regeln in Ihrer Scrum Retrospektive, wenn etwas nicht klappt!
  4. Klare Abgrenzungen der Phasen. Hüten Sie sich vor Problemen in den Phasen 2 und 3. Moderieren Sie hier gut, denn Phase 2 („Gatter Data“) sammelt erst einmal nur die Daten. Nicht wenig Teams versuchen hier gleich zu bewerten und kritisieren gefundene Daten. Das müssen Sie klar trennen, sonst läuft Ihnen die Zeit davon.
  5. Verändern Sie Abläufe. Führen Sie Ihre Retrospektive in Scrum nicht immer gleich durch! Auch wenn ein mechanischer Ablauf für Sie einfach ist, bewirken andere Formate oft auch Änderungen im Denken, generieren neue Ideen und andere Ansichten.
  6. Machen Sie Pair-Doing. Peppen Sie die Retrospektive auf und arbeiten Sie in Paaren. Dabei darf der, der etwas erzählt oder vorschlägt nicht der gleiche sein, der etwas schreibt!
  7. Bilden Sie Gruppen. Wenn Sie in der Scrum Retrospektive Gruppen bilden, dann hilft Ihnen das, um einzelne Teilnehmer, die vielleicht nicht in großer Runde etwas sagen, in Gruppenarbeit mehr zu motivieren.
  8. Fragen Sie. Als Moderator oder als Person in Paaren, nutzen Sie die Kraft der Fragen. Fragen Sie nach, geben Sie das was Sie aufgenommen haben, an den Gegenüber gespiegelt zurück.
  9. Fokussieren Sie auf den nächsten Sprint. Bei Änderungen fokussieren Sie auf den nächsten Sprint. Es gibt viele Änderungen, aber die wenigstens sind direkt im nächsten Sprint machbar. Ihre Scrum Retrospektive sollte auf kurzfristige Erfolge fokussieren.
  10. Änderung ins Backlog. Wenn Änderungen nicht im Backlog stehen und auch so, dass Sie im nächsten Sprint dran kommen, gehen Sie gerne unter. Sprechen Sie mit dem Product Owner, vereinbaren Sie eine Regel, so dass die Umsetzungen im nächsten Sprint dran kommen können.
  11. Ändern Sie Rahmenbedingungen. Werfen Sie alle Tische aus dem Raum, gehen Sie mal in eine andere Location – was auch immer. Durch Änderungen der Rahmenbedingungen verändern Sie auch die Ergebnisse und die Produktivität der Mitglieder.
  12. Auch Positives wertschätzen. Oft wird in der Retrospektive der Fokus nur auf das Verbesserungswürdige gelegt. Das ist zwar menschlich, doch auch Dinge die gut laufen, sollten einmal wertgeschätzt werden. So kann aus einer guten Praktik vielleicht ein Ritual gemacht werden? Vielleicht wird ein Prozess so besser in der Organisation integriert?
  13. Standortbestimmung für das Team etablieren. Welche Referenz kann das Team nutzen, um sich selbst einzuordnen, wo es steht und wie reif es ist? Versuchen eine individuelle, nach Möglichkeit vom Team kommende, Lösung zu finden, die dem Team helfen kann.

Die Checkliste für die Retrospektive in Scrum

In diesem Abschnitt zeige ich Ihnen noch einmal auf was es genau ankommt. Nutzen Sie einfach die folgende Checkliste, um sicher Ihre Retrospektive durchführen zu können.

  • Ist der Termin für die Retrospektive bekannt? Haben alle Terminmitglieder den Termin bekommen und auch bestätigt? Gerade zu Beginn und bei nicht eindeutigen und impliziten Annahmen prüft der Moderator bzw. Scrum Master das Verständnis der Retrospektive explizit ab.
  • Bereiten Sie die Infrastruktur vor. Haben Sie genug Klebezettel? Sind genug Stifte vorhanden? Haben Sie Platz auf Tischen, an Wänden oder an Fenstern, um genug Ergebnisse produzieren zu können? Denken Sie auch an recht banale Dinge wie: frische Luft und etwas zu trinken!
  • Der Scrum Master sollte schon im Vorfeld etwas überlegen und sich an bestimmte Ereignisse im Sprint erinnern. Die Rahmenbedingungen im Kopf haben und je nach Brisanz sich überlegen, wie er dem Team helfen kann, diese Dinge zu erkennen oder anzusprechen, wenn sie sonst ausbleiben. Wichtig ist hierbei: kein Überfallen mit der eigenen Meinung! Vielmehr ist gemeint, dass bei offensichtlichen Probleme, die keiner ansprechen will, der Fokus auf diese gelenkt werden kann. Dieser Punkt für die Scrum Retrospektive ist meistens dann wichtig, wenn das Team noch nicht lange zusammen arbeitet und schlechte Rahmenbedingungen existieren.
  • Die Scrum Retrospektive hängt sehr an der Kommunikation im Team. Der Scrum Master sollte im Vorfeld genau überlegen, mit welchen Formaten er die Kommunikation gut fördern kann.
  • Achten Sie auf Ihren Zeitplan in der Scrum Retrospektive – wenn Sie die 5 Phasen nutzen, dann sollten Sie die Verteilung zu diesem Phasen im Kopf haben (siehe Infografik). Wenn Sie einem anderen Weg folgen, dann machen Sie sich grobe Zeitabschnitte, um mit der richtigen Timebox das Beste aus der Scrum Retrospektive herauszuholen.
  • Achten Sie auf den Fokus innerhalb der Retrospektive in Scrum. Auch wertvolle Diskussionen benötigen Zeit. Prüfen Sie regelmäßig, ob die Diskussion zielführend und Sie sich noch innerhalb der Timebox befinden.
  • Bringen Sie den Teilnehmern Wertschätzung entgegen. Egal ob verbesserungswürdige Dinge angesprochen werden oder auch der zwischenmenschliche Konflikt.
  • Haben Sie konkrete, abgestimmte Maßnahmen für den nächsten Sprint?

Infografik zur Scrum Retrospektive

Infografik zur Scrum Retrospektive

Für Ihre Retrospektive in Scrum habe ich eine kleine Infografik erstellt. Bei Interesse finden Sie die Infografik zur Retrospektive hier. Melden Sie sich einfach über dieses Formular und ich schicke Ihnen gerne die Infografik in unterschiedlichen Formaten zu. Sie dürfen diese gerne benutzen und in Ihren Projekten verwenden.

Da die Scrum Retrospektive in der Regel den 5 Phasen folgt, können Sie hier ohne Probleme diese als Vorlage nutzen und darauf Ihren persönlichen Stil entwickeln.

Wie sollte die Scrum Retrospektive definitiv nicht ablaufen?

Wer gerne eine nicht funktionierende Scrum Retrospektive sehen möchte, dem sei das folgende Video sehr ans Herz gelegt 😉

Die Scrum Retrospektive in 30 Minuten?

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

Weiterführende Links

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.

2 Sprint Planning Lernevent Titel

Das Sprint Review als Lernevent!

Das Event Sprint Review in Scrum

Das Sprint Review in Scrum ist das Meeting, in dem das Team vorstellt, was es in diesem Sprint geleistet hat. Es ist damit eines der Scrum Events das ein agiles Prinzip sehr stark unterstützt: Die Transparenz. Ziel des Sprint Reviews ist es, ein funktionierendes Produktinkrement den Stakeholdern, Endnutzern und anderen Interessenten erlebbar zu machen. Das Sprint Review ist allerdings mehr, es ist ein Lernevent und sollte nicht als „einfache Demo“ verkommen.

Grundlagen zum Sprint Review

Sprint ReviewZu Beginn möchte ich auf Grundlagen eingehen. Dabei unterscheide ich gerne, ob sich ein Team schon kennt, oder ob es im Zuge einer neuen Produktentwicklung neu zusammengestellt wurde. Während Sie bei eingespielten Teams davon ausgehen können, dass sich die Teilnehmer alle kennen, ist das bei neuen Teams natürlich noch nicht der Fall. Steter Tropfen höhlt den Stein und so ist es auch hier sinnvoll, vielleicht bereits durchgeführte Rituale – wie Teamworkshop – zu erneuern und aufzufrischen: Lassen Sie die Teammitglieder kurz sagen, wer sie sind und wie die Aufgabe ist (gerade bei größeren Runden).

  • Der Product Owner ist die Person, die zu diesem Meeting einladen sollte. Oft übernimmt so etwas der Scrum Master. Läd der Product Owner ein, hat das eine andere Wirkung auf alle Beteiligten. Es zeigt Respekt und Anerkennung, gerade gegenüber dem Entwicklungsteam.
  • Der Product Owner begrüßt und dankt in diesem Event, das alle teilnehmen sowie die Zeit gefunden haben und gibt einen groben Rahmen, wie das Sprint Review ablaufen soll. Das übernimmt alternativ der Scrum Master. Ebenso kümmert sich der Scrum Master um alles, was noch benötigt wird, wie Materialien etc.
  • Ziel ist es im Sprint Review einen Fortschritt über das aktuelle Projekt und damit Produkt zeigen zu können. Dabei unterstützt das potentiell auslieferbare Produktinkrement natürlich ungemein.
  • Der Product Owner nimmt Story ab. Das Sprint Review ist der letztmögliche Zeitpunkt das zutun. Es hindert den Product Owner niemand daran, bereits während des Sprint Story abzunehmen.
  • Der Product Owner kann so zum Beispiel auch schon vorbereitend die Story die gezeigt werden und die, die es nicht werden, an die Interessenten im Vorfeld verteilen.
  • Das Produktinkrement wird vom Team vorgestellt.
  • Der Scrum Guide gibt eine Timebox von vier Stunden für einen einen einmonatigen Sprint für das Sprint Review an.

Lernen Sie im Sprint Review

Probieren Sie ein Experiment: Ihre Checkliste für das Sprint Review. Probieren Sie doch einmal die folgende Punkte in Ihrem nächsten Sprint Review aus und schreiben Sie mir

  • Der Product Owner läd zum Sprint Review ein, nicht der Scrum Master. Wenn es während des Sprints schon abgenommene Stories gibt, verteilt er diese an alle Stakeholder und Interessenten, gemeinsam mit der (aktualisierten) Agenda.
  • Der Product Owner begrüßt alle Teilnehmer und dankt ausdrücklich für die Zeit und das Erscheinen. Im Anschluss geht er noch einmal auf (seine) Produktvision ein.
  • Der Product Owner gibt eine Übersicht über die Erreichung des Sprint Ziels aus seiner Sicht.
  • Das Entwicklungsteam stellt das vor, was auch wirklich als „done“ gewertet werden kann. Hier nutzen Sie eine kurze Übersicht an was im Sprint gearbeitet wurde, was davon „done“ ist und was nicht.
  • Nach dem klar ist, was als „done“ präsentiert wird, startet die eigentliche Demonstration.
  • Lassen Sie das Team kurz vorstellen, was zu zeigen ist. Binden Sie auch Stakeholder und Endbenutzer direkt in das Sprint Review ein. Lassen Sie auch diese mit dem Produkt interagieren. Erlauben Sie es den Stakeholder Formen oder Farben zu entdecken, die Bedienung zu erfahren und das Produkt wirklich zu erleben.
  • Gehen Sie danach auf (Produkt)Probleme und Herausforderungen ein. Was konnten Sie im Team wie lösen und was lernen Sie daraus?
  • Fragen Sie sich, was dieser Sprint für den kommenden Sprint bedeutet! Der Product Owner sollte hier ein Überblick über (Kunden)Meilensteine, Budgets, etc. geben können. Dadurch, dass Sie das Sprint Review zum Lernen benutzen können, kann natürlich auch das Team hier helfen. Wenn der Product Owner vorstellt, was er sich für den nächsten Sprint wünscht, kann gleich wertvolles Feedback vom Team aufgenommen werden.

Beenden Sie das Sprint Review mit Anerkennung

Der Product Owner sollte das Meetings selbst beenden und noch mal allen Teilnehmern bedanken. Besonderen Dank natürlich für das Team, für das Produktinkrement und ebenso für die Stakeholder und Teilnahme. Auch hier kann der Product Owner das Sprint Review nutzen, um besondere Lehrerfahrung hervorzuheben. Nicht selten kommen neue Impulse und Anmerkungen, die der Product Owner wieder direkt für sich nutzen kann.

Hinweise zum Sprint Review und der Abnahme von Product Backlog Items

Achten Sie hier rauf: Wenn Sie als Product Owner immer nur im Sprint Review etwas abnehmen können, läuft etwas falsch. Sie müssen während des Sprints schon in der Lage sein, fertige Stories zu betrachten. Wenn nicht, werden Sie wahrscheinlich sehr viele Abhängigkeiten oder andere Probleme in Ihrem Produkt haben. Es können nicht alle Stories nur am Ende eines Sprints fertig sein! Ein sehr guter Moment für die Retrospektive

 

1 Sprint Planning Titel

Sprint Planning

Das Sprint Planning

Scrum Sprint PlanningDas Sprint Planning in Scrum ist das Event in dem der kommende Sprint geplant wird. Es teilt sich in der Regel in zwei Teile auf. Im ersten gibt der Product Owner an, was er gerne hätte. Im zweiten Teil bestimmt das Entwicklungsteam, wie es sich eine Umsetzung konkret vorstellt. Am Ende der Sprint Planung haben die Beteiligten ein gemeinsames Verständnis der umzusetzenden Arbeiten für den kommenden Sprint. Das Entwicklungsteam hat sich zudem auf den selbst bestimmten Umfang verpflichtet.

Die Voraussetzungen

Damit das Sprint Planning wie gewünscht stattfinden kann, benötigt es einige Voraussetzungen. Zum einen sollte der Termin immer nach der Retrospektive stattfinden. Ein Sprint Planning findet damit immer direkt nach Ende des letzten Sprints statt. Es wird also nicht etwa eine gewisse Zeit gewartet.

Die Einladungen samt Ziel und Agenda sollten dem Team klar und durch den Scrum Master auch kommuniziert sein.

Das Sprint Planning im zeitlichen Überblick

Scrum Kurs AboFür einen vierwöchigen Sprint lässt sich mit dem Richtwert von 8 Stunden starten. Dabei werden zwei Teile, das Sprint Planning 1 und 2 betrachtet. Wenn der Sprint kürzer ist, dann kann das Sprint Planung anteilig betrachtet werden. Ich persönlich tendiere bei einem guten Backlog Refinement immer dazu, das Sprint Planning 1 so kurz wie möglich zu halten. Das funktioniert immer dann gut, wenn die entsprechenden Product Backlog Einträge…

  • … so groß sind, dass sie das Entwicklungsteam diese theoretisch in einen Sprint nehmen können
  • … bereits geschätzt sind und diese Schätzung nicht zu lange zurückliegt
  • … alle Akzeptanzkriterien vorhanden sind

Wenn das Verständnis über das, was in den Sprint kommt vorhanden ist, geht der erste Teil des Plannings sehr schnell. Wie so oft gibt es verschiedene Rahmenbedingungen die berücksichtigt werden müssen, in den Projekterfahrungen (am Ende) gebe ich dazu auch noch ein paar Richtwerte.

Wer sich nicht sicher ist, startet immer mit der Definition im Scrum Guide und kann erst einmal wenig falsch machen.

Inhalt des Sprint Plannings

Sprint Planning und InhaltWährend die genaue Bezeichnung im Grunde egal ist, ist der Inhalt umso wichtiger. Hier geht es darum, dass zum einen der Product Owner dem Entwicklungsteam vorstellt, was er gerne hätte. Das Entwicklungsteam wählt dabei die Arbeit aus, die es glaubt in der Lage ist zu leisten. Es bestimmt dabei auch die konkrete Umsetzung, also das wie! Ein ganz entscheidender Aspekt ist dabei, dass das Entwicklungsteam auch wirklich an der Lieferung der entsprechenden Aufgaben arbeitet. Das adressiert auch einen der fünf Scrum Werte, nämlich das Commitment.

Je nach Erkenntnisgewinn kann es nötig sein, dass die Definition of Done justiert wird. Das Sprint Ziel ist durch den Product Owner und das Entwicklungsteam ebenso festgelegt. Hier hilft es, wenn der Product Owner mit einem Vorschlag in das Sprint Planning kommt und es gemeinsam mit dem Entwicklungsteam dann verabschiedet. Das Sprint Backlog enthält dann die Stories, die durch das Entwicklungsteam für die Umsetzung ausgewählt wurden.

Abschluss des Sprint Plannings

Abschluss des Sprint PlanningsDas Sprint Planning schließt mit dem gemeinsamen Verständnis der zu leistenden Arbeit für den kommenden Sprint. Nach dem Abschluss des Sprint Plannings geht es direkt in die Umsetzung. Das Sprint Backlog ist erstellt und die Definition of Done ggf. noch einmal angepasst. Ebenso liegt das Sprint Ziel vor. Diese Artefakte sollten beim Team im Teamraum so hängen, dass diese bei der täglichen Arbeit auch wirklich sichtbar sind.

Erfahrungen aus der Praxis

Es gibt immer Teams die auf neue Ideen kommen, die unter bestimmten Rahmenbedingungen auch funktionieren können. Dabei sollen die hier vorgestellten Punkte der Orientierung dienen – sie können weder 1:1 kopiert werden, noch stellen diese eine Empfehlung dar!

  • Ein Aspekt, den ich bei Teams in der Transformation mit ehemaligen Projektleitern immer wieder finde, ist das das Product Owner schon eine Vorstellung des Sprint Backlogs mit in das Sprint Planning bringt. Dann steht das Sprint Backlog „zum Check“ bei dem Entwicklungsteam. Es ist also kein Push der Arbeit und wenn das Entwicklungsteam sagt, es schafft es nicht, dann wird auch von diesem Plan abgewichen und der Product Owner nimmt die Einträge dann zurück ins Backlog.
  • Bei Entwicklungsteams, die (noch) nicht cross-funktional sind, findet sich in dem Sprint Planning der Aspekt, dass die Bestimmung der konkreten Aufgaben, die sich aus der User Story ableiten nicht gemeinsam stattfindet.
  • Wenn das Refinement sehr gut in den Teams läuft, dann ist es durchaus möglich das Sprint Planning 1 bei einem zwei oder drei wöchigen Sprint bei ca. 45 Minuten einpendeln zu lassen. Das hängt natürlich entscheidend davon ab, was die Teams entwickeln, wie die Aufgabenverteilung ist und wie gut die Teams die Umsetzung der Aufgabe annehmen können.
  • Wenn nicht mit User Stories gearbeitet wird und ein oft wasserfallähnliches Scrum durchgeführt wird, dann finden sich nicht selten im Planning 2 Einträge wie entwickeln, integrieren, testen, … Das ist im Sinne von Scrum nicht optimal.audi
4 Retrospektive Titelbild

Kontinuierliche Verbesserung: die Retrospektive

Verbesserungen

Eine Retrospektive in Scrum ist der Motor, mit Sie eine kontinuierliche Verbesserung in Ihrem Scrum Team fördern können. Eine Retrospektive wird in der Regel in fünf Phasen unterteilt und ermöglicht es dem Team, den gelebten Prozess zu reflektieren. Richtig gut werden Retrospektiven dann, wenn es etwas gibt, das die Teams nach der Retrospektive auch aktiv am Prozess angehen.

Auch das agile Manifest kennt die Verbesserung, die sich in der Retrospektive von Scrum findet:

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Agile Manifesto

Der Fokus der Retrospektive

Bei der Retrospektive liegt der Fokus auf dem Prozess, dem Zusammenspiel der Menschen und der Infrastruktur. Nicht im Fokus steht bei der Retrospektive das zu entwickelnde Produkt. Zwar können hier immer Wechselwirkungen vom Prozess zum Produkt entstehen, doch der Fokus liegt auf ersterem. Kurz gesagt, das Produkt findet Betrachtung im Sprint Review und der Prozess und das Zusammenspiel in der Retrospektive.

Retrospektive Infografik

Sie findet nach dem Sprint Review und vor dem nächsten Sprint Planning statt. Die Retrospektive in Scrum ist damit direkt in Ihren Prozess eingebettet und projektbegleitend. Es ist damit kein typisches Lessons Learned am Ende eines Projektes.

Der Ablauf einer Retrospektive in Scrum

Direkt bevor Sie erneut eine Sprint Planung starten und nachdem Ihr Sprint Review abgeschlossen ist, starten Sie mit der Retrospektive. Es hat sich mittlerweile eingebürgert, dass für Retrospektiven die 5 Phasen nach Esther Derby und Diana Larsen benutzt werden, die im Buch Agile Retrospektives beschrieben sind. Das ist insbesondere bei neuen Teams ein sehr gutes Gerüst, um die Retrospektive zu strukturieren.

Die Phasen einer Retrospektive

Sie können jetzt in jeder Phase unterschiedliche Techniken nutzen. So nutze ich zum Beispiel ganz andere Techniken für Teams die ich ganz neu habe, als für Teams, die schon eingespielt sind.

Dauer der Retrospektive

Der Scrum Guide nennt bis zu drei Stunden bei einem vierwöchigen Sprint. Ist Ihr Sprint kürzer, dann schrumpft auch das Zeitfenster für die Retrospektive. In meinen Augen macht eine Retrospektive unter einer Stunde kaum Sinn. Selbst mit einem sehr einfachen Format dauert es für mich mindestens 60-70 Minuten. 90 Minuten finde ich ganz angenehm.

Für mich ist die Zeitfrage aber immer ein Wechselspiel zwischen dem Format und dem Fokus. Gute Erfahrungen habe ich auch mit den Gegenwartsbäumen gemacht, gerade wenn die Grund-Ursache-Beziehungen zwischen Gründen nicht so einfach sind. Hier sollten Sie aber mindestens zwei Stunden veranschlagen, um ein gutes Ergebnis zu erzielen!

Einladungen und infrastrukturelles

Raum Infrastruktur RetrospektiveDer Scrum Master ist die Person, die sich um das infrastrukturelle kümmert. Er ist es auch, der idealerweise dafür sorgt, dass die Termine (mit Ziel und Agenda) allen Teammitgliedern zur Verfügung stehen. Für alle Formate hat er die notwendigen Materialien vorbereitet und stellt sie im Termin zur Verfügung und leitet die Teilnehmer bei neuen Techniken an.

Es bietet sich an, auch hier wie im Daily Scrum zu verfahren. Nutzen Sie nach Möglichkeit immer gleiche Räumlichkeiten. Immer gleiche Wege und Rituale schleifen sich über die Zeit ein. Sie werden weniger Verspätungen und eine höhere Anwesenheit durch solche einfachen Dinge bekommen können.

Die Formate für die Retrospektive

Formate RetrospektiveEs gibt sehr viele und gute Formate für die Retrospektive in Scrum. Dazu existieren Webseiten und ganze Bücher, in denen man alle möglichen Techniken finden kann. Es ist für jeden etwas dabei. Grundsätzlich empfehle ich zwar verschiedene Formate auszuprobieren, sich dann aber auch ein gutes Set festzulegen. Es gibt zwar Teams, die immer etwas Neues ausprobieren wollen, eine gewisse Konstanz ist aber auch hier nicht verkehrt. Das lässt sich natürlich nur unter Berücksichtigung aller Rahmenbedingungen sagen. Ich persönlich bin ein Fan der Timeline und dem einfachen Plus / Delta. Wenn ich mehr Zeit habe, nutze ich bei Problemen auch gerne einen Gegenwartsbaum.

ich möchte an dieser Stelle zwei sehr einfache Formate vorstellen, die sich immer wieder anbieten. Gerade wenn der Scrum Master oder das Team neu ist.

Plus Delta Format Retrospektive

Plus / Delta

Es werden Themen gesammelt, die im letzten Sprint gut gelaufen sind und ebenso Dinge, die noch ein Delta an „gut gelaufen“ haben oder womit sich einfach noch jemand nicht „ganz so wohl fühl“.

Start Stop Continue Format Retrospektive

Start / Stop / Continue

Bei diesem Format werden Themen gesammelt, mit denen jeweils begonnen werden sollte, die gestoppt gehören und ebenso Themen, die fortgeführt werden.

Achtung!

Wichtig bei der Retrospektive in Scrum ist es immer am Ende eine Idee für eine Verbesserung mitzunehmen. Diese kann zu Beginn jeder Retrospektive auch kurz vorgestellt werden. Sie sollte so klein sein, dass diese auch im Sprint wirklich umgesetzt werden kann.

Input für die Retrospektive

Welcher Input ist für die Retrospektive vorhanden?Ihren Input und alle Daten, die es sich lohnt zu betrachten, können Sie aus allen Artefakten, Events, Rollen, etc. ableiten. Ebenso ein Blick auf die Burn-down oder Burn-up Grafiken sind hier hilfreich. Gibt es Tendenzen? Gibt es Einbrüche? Ist es so wie erwartet? Daten finden sich fast überall, die Frage, die geklärt werden muss ist, ob diese relevant sind. Als Anhaltspunkt können Sie mit den folgenden Themen starten:

  • Burn Down / Burn Up Charts
  • Impediment Backlogs
  • Empfinden der Teammitglieder
  • Geschehnisse in der Organisation
  • Schnittstellen
  • Gefühle / Wohlbefinden

Eine Besonderheit ist für mich immer die erste Retrospektive, wenn ich zu einem neuem Team komme. Wenn ich es kann und die Rahmenbedingungen passen, dann versuche ich mit einer Retrospektive in Scrum direkt zu starten. Das hilft mir einen guten Überblick im Projekt zu bekommen. Dabei spielen eher Aufstellungen anhand von Fragen und Wechselwirkungen von Scrum und den Rahmenbedingungen eine Rolle.

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

Durchführung der Retrospektive

Wenn der Tag der Retrospektive gekommen ist, dann kann der Ablauf wie folgt kurz skizziert werden.

  • Scrum Master hat sich vorbereitet und ein Format ausgewählt (ggf. bei Erfahrung auch spontan nach Teambefinden ausgewählt).
  • Team findet sich zum Event ein.
  • Die 5 Phasen der Retrospektive werden z.B. benutzt um eine Struktur für das Event zu finden.
  • Der vergangene Sprint wird betrachtet
  • Daten werden ermittelt
  • Anhand der Daten wird analysiert, was verbessert werden kann
  • Eine Umsetzung wird entschieden, die klein genug ist, um Sie im nächsten Sprint auszuprobieren
  • Die Retrospektive wird beendet

Retrospektive – einfach, oder?

Das Vorgehen in der Retrospektive ist vielfältig. Es gibt mittlerweile eine Auswahl an guten und praktischen Methoden, damit die Retrospektive in Scrum zu Erfolg wird. Dennoch ist die Retrospektive nicht leicht, da die folgenden Probleme und Herausforderungen auf Sie warten!

Konflikt Retrospektive

Konflikte

In Retrospektiven kommt es häufiger zu Konflikten, wenn das Zusammenspiel von Personen angesprochen wird. Das ist ein normaler Prozess und muss besprochen werden.

Archivierung der Retrospektive

Archivierung

Wenn Sie viele Retrospektiven durchgeführt haben, werden Sie auch viele Ergebnisse bekommen. Wie dokumentieren Sie all dieses sinnvoll?

Experiment

Experimente

Ergebnisse von Retrospektiven sind oft Experimente. Sie versuchen etwas und probieren etwas aus, um den Prozess zu verbessern. Das ist essentiell und sollte in Ihr Blut übergehen.

Scrum Fehler

Impediments

Das Impediment Backlog wird häufig während Retrospektiven gefüllt und muss demnach auch wieder geleert werden. Neben nützlichen Themen fallen oft auch behindernde Punkte in den Fokus.

Organisation

Organisationsthemen

Themen in der Retrospektive sind nicht immer im Team zu lösen, sondern betreffen auch die Organisation. Hier muss der Scrum Master aktiv werden.

Teamdynamik

Ungewissheit & Teamdynamik

Die einen finden es spannend, für die anderen regt sich etwas Unbehagen – gerade in der Retrospektive in Scrum kann es diverse Möglichkeiten geben, wie sich die Teamdynamik verhält.

Scrum Master als Moderator

Dem Moderator kommt eine besondere Rolle in der Retrospektiv zu. Er ist Moderator, Schlichter und auch Coach. Er gilt und unterstützt das Team gute Praktiken und Wege zu finden und achtet auch die Umsetzung von Verbesserungsmaßnahmen, die am Ende der Retrospektive feststehen.

Scrum Master

Moderator

Der Scrum Master moderiert die Retrospektive. Dabei hilft er dem Team, Knackpunkte zu finden und unterstützt die Kollegen in der Findung von möglichen Lösungen.

Scrum Master Retrospektive

Materialien

Der Scrum Master hat für die Retrospektive immer einen Koffer an passenden Materialien dabei und ebenso auch die richtigen Techniken im Kopf, um erfolgreich arbeiten zu können.

Scrum Master Schlichter

Schlichter

Wo gehobelt wird, da fallen Späne – das ist in der Retrospektive der Fall. Wenn etwas nicht rund läuft, muss mit Befindlichkeiten und Gefühlen umgegangen werden.

Der Product Owner und die Retrospektive

Scrum Product OwnerKontrovers wird immer über die Teilnahme des Product Owners bei der Retrospektive diskutiert. Ich persönlich finde es unter bestimmten Bedingungen gut, wenn der Product Owner auch teilnimmt. Reflektieren wir dazu noch einmal kurz, warum er nicht teilnehmen sollte.

Der Product Owner vertritt den Kunden und hat die Wirtschaftlichkeit des Produktes vor Augen. Das ist auch gut so. Er hat – gerade wenn er direkt der Kunde ist – vielleicht einen verstärkten Blick auf das Produkt und stellt die Zusammenarbeit nicht unter das gleiche Licht, wie das Team selbst. Zum anderen gibt er aber wertvolle Blickweisen mit in das Team, die helfen können, Situationen zu verstehen und zu verbessern.

Ich finde es sinnvoll den Product Owner mit in die Retrospektive zu nehmen. Es könnte unter bestimmten Bedingungen eine Gefahr vom Product Owner ausgehen, dass dieser die Verbesserungen des Produktes zu Lasten der Teamverbesserungen sieht. Bei einem nicht konsequenten Scrum Master und einem ebenso wenig starken Team, bestünde hier zum Beispiel die Möglichkeit, dass die Retrospektive in eine andere Richtung abdriftet als gewollt.

Persönlich finde ich, dass in den meisten Teams eine recht ausgewogene Rollenverteilung vorhanden ist und auch die Mitglieder mit gesundem Menschenverstand auf die Prozesse schauen und damit die positive Bereicherung der Retrospektive durch die Rolle zu schätzen wissen.

Ist das nicht der Fall, muss die Frage diskutiert werden. Doch auch hier lohnt sich dann ein Blick in das agile Manifest – werden die Werte, Prinzipien oder gar die Scrum Werte hier richtig gelebt?

1 Daily Scrum Meeting

Daily Scrum Meeting

dailyDas Daily Scrum Meeting

Daily Scrum Meeting KommunikationDas Daily Scrum Meeting ist ein operatives Synchronisationsmeeting von und für das Entwicklungsteam. Es findet jeden Tag zur gleichen Zeit am gleichen Ort statt. Sie lernen in jeder Scrum Schulung, dass es elementar ist, dieses Meeting durchzuführen. Und das ist auch korrekt, mit einer Ausnahme, die man in meinen Augen durchaus machen kann.

In diesem Artikel sehen wir uns die Grundlagen vom Daily Scrum an, ich werde aber auch etwas links und rechts des Lehrbuches einen Blick auf das werfen, was mir aus der Erfahrung aufgefallen ist und was ebenso gut funktioniert.

Die Grundlagen für das Daily Scrum Meeting

Das Daily Scrum Meeting findet idealerweise jeden Tag zur gleichen Zeit am gleichen Ort statt. Dabei ist es auf 15 Minuten begrenzt. Dieser fast langweiligGrundlagen Scrum wirkende Ablauf ist essentiell, der er reduziert Komplexität! Nicht selten funktionieren Daily Scrums nicht, wenn diese im Ort und der Zeit wechseln. Die Teammitglieder müssen sich dann nämlich auf weitere Details konzentrieren, die nicht zum Wert eines Produktes beitragen. Sie können darüber lachen oder schmunzeln, aber wenn Sie in der Woche an fünf verschiedenen Plätzen ein Daily Scrum Meeting machen, dann ist das verwirrend und kostet unnötigen Aufwand. Unnötiges versuchen wir in Scrum immer zu vermeiden und deshalb hilft es uns, das Meeting wie beschrieben stattfinden zu lassen. Ebenso ist es hilfreich das Daily Scrum Meeting morgens bzw. vormittags durchzuführen.

Im Scrum Guide finden wir zum Daily Scrum die folgende Aussage ebenso die folgende Aussage:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity.

Scrum Guide

Innerhalb des Daily Scrum Meeting werden drei Fragen von jedem Mitglied im Entwicklungsteam beantwortet.

  • Was habe ich gestern geschafft,
  • Was werde ich heute tun und
  • Wo gibt es Hindernisse für mich, die mich an meiner Arbeit behindern?

Diese Fragen beantwortet jedes Teammitglied vorbereitet und zügig. Es geht nicht um Details und jede Diskussion, die länger als eine Minute dauert, wird in einem nachgelagerten Meeting besprochen. Die Fragen sollte aber nie ohne Fokus besprochen werden, dazu finden sich im  nächsten Abschnitt weitere Details.

Der notwendige Fokus auf das Sprintziel

Fokus (Daily Scrum Meeting)Das Daily Scrum Meeting kann selbst mit diesen Fragen nicht effizient sein. Diese Effizienz lässt sich aber herstellen, in dem die drei Fragen auf das Sprint Ziel bezogen werden. Die Teammitglieder nutzen die Fragen also immer unter Berücksichtigung des im Planning definierte  Sprint Ziel.

Nehmen wir an, Sie haben als Sprint Ziel „API Anbindung für Facebook realisieren“ oder „Kundenwekenntnisse für den zweiten MVP gewinnen“, dann bentworten die Teammitglieder die oben genannten Fragen immer auf dieses Ziel. Sie werden sehen, dass das Daily Scrum Meeting dadurch automatisch mehr Effizienz bekommt.

Es ist ein Unterschied, ob ich meinem Kollegen im Daily Scrum Meeting erkläre, was ich gestern gemacht habe oder was ich im Bezug zum Sprint Ziel getan habe. Auf das Ziel hat sich das Team commited und alle müssen an diesem Strang ziehen und zusammen arbeiten, damit das realisiert werden kann. Der Fokus der Fragen auf dieses Ziel ist demnach sehr hilfreich!

Kann man das Daily Scrum ausfallen lassen?

TerminDie erste Antwort ist nein, ein klares nein. Die zweite Antwort, die ich immer gebe ist, es kommt drauf an! Ja natürlich ist das erstmal Beratergeschwätz, auf was ich aber aufmerksam machen will ist, dass wir zunächst einmal einen Blick auf das Ziel des Daily Scrum Meetings werfen sollte. Und das bevor wir mit Befindlichkeiten und Fanatismuss für oder gegen eine Aussage zum Ausfall des Daily Scrum Meeting machen.

Grundsätzlich habe ich beim Daily Scrum Meeting die Erfahrung gemacht, dass dieses Event unterschätzt wird, besonders in der Wichtigkeit. Es braucht eine Möglichkeit, sich jeden Tag in aller Kürze abzustimmen und auf den neusten Stand zu bringen. Viele Teams haben das Daily Scrum nicht oder nicht in der Intensität und erreichen nach der richtigen Durchführung des Daily Scrum Meetings deutliche Verbesserungen in der Kommunikation und dem Verteilen von Wissen und Transparenz im Team.

Ich habe auch Teams erlebt, die das Ziel im Daily Scrum auch mit einer nicht konstanten Durchführung des Daily Scrum Meetings das Ergebnis dieses Meetings erreicht haben. Ja, das ist kein Scrum. Ja, das ist nicht nach Lehrbuch. Ich frage mich aber immer gerne, nützt es dem Team? Sind die erforderlichen Ergebnisse vorhanden oder reite ich jetzt auf einem Weg rum, weil er so „im Lehrbuchsteht“?

Der Grad ist sehr schmal und es bedarf richtig guter reifer Teams, so etwas zu ändern und trotzdem auf sehr hohem Niveau zu halten. Wenn Sie mit Scrum starten, dann halten Sie sich am besten genau an das Daily Scrum Meeting, wie es auch im Lehrbuch steht. Damit machen Sie nichts falsch. Beobachten Sie, reflektieren Sie und verbessern Sie dann, wo Sie Verbesserungen identifizieren.

In der Regel gibt es am Tag des Sprint Plannings keine wirkliche Notwendigkeit des Daily Scrum Meetings. Wenn Sie eine lange Sprintdauer haben – zum Beispiel vier Wochen – dann ist Ihr Tag gut ausgefüllt mit eben diesem Meeting. Wenn Sie das Sprint Planning in zwei Teile teilen, dann werden im zweiten Teil Teammitglieder bereits das an Aufgaben ziehen, was Sie bearbeiten (wollen). Das ist ein sehr guter Einstieg in eine unserer drei Fragen. Es ist sofort ersichtlich, was die Teammitglieder im Bezug auf das Sprint Ziel machen wollen und werden.

Sollte es im Sprint Planning Hindernisse geben, dann sind diese eben bei dieser Sprint Planung auch berücksichtigt. Auch diese Frage findet sich in unseren drei Fragen wieder, in der wir die Hindernisse adressieren. Was das Team gestern gemacht hat, ist üblicherweise über das Sprint Review ebenso abgedeckt. Auch hier ist das Team wieder synchron mit den Aufgaben.

Wenn das Sprint Planning deutlich kürzer sein sollte, kann natürlich trotzdem ein Daily Scrum Meeting durchgeführt werden. Die spannende Frage wäre für mich auch, was nützt es dem Team und was wird dann hier besprochen, dass nicht schon durch den Planungstag abgedeckt ist?

Das Daily Scrum Meeting alle zwei Tage

Ein Klassiker falscher Implementierungen ist es, das Daily Scrum Meeting zum Beispiel gleich zu Beginn nur alle zwei Tage durchzuführen. Wenn Sie an diesen Punkt kommen, dann sollten Sie schnellsten Ihre Rahmenbedingungen kontrollieren. Der Grund kann natürlich vielfältig sein. Zum Beispiel wäre es denkbar, dass Sie gar kein Scrum für Ihre Situation brauchen. Es könnte auch ein falsches Verständnis von Scrum als Ganzes sein.

Gehen Sie davon aus, dass Sie das Daily Scrum Meeting jeden Tag benötigen. Sollte diese Situation bei Ihnen auftreten, dann ist es Zeit sich in der Retrospektive genau diese Situation einmal anzusehen. Dafür lässt sich zum Beispiel auch ein Gegenwartsbaum nutzen.

Aufgaben und Rollen im Daily Scrum Meeting

Scrum Master

Scrum Master

Der Scrum Master achtet beim Daily Scrum Meeting auf die Zeiten und das das Ziel erreicht wird. Er moderiert das Daily Scrum, wenn es erforderlich ist. Sollte das Team schon sehr reif sein, muss der Scrum Master auch gar nicht mehr am Meeting teilnehmen.

Scrum Product Owner

Product Owner

Der Product Owner ist grundsätzlich nicht im Daily Scrum Meeting dabei. Er darf aber – wenn es das Team wünscht und möchte – dabei sein, nimmt dann aber die Rolle des Zuhörers ein und greift nicht aktiv in das Gespräch ein.

Scrum Entwicklungsteam

Entwicklungsteam

Das Entwicklungsteam führt das Daily Scrum Meeting für sich selbst aus. Es beantwortet sich drei Fragen und ist somit über Aufgaben und Aufwände aller Teammitglieder incl. möglicher Hindernisse informiert.

Was Sie für Ihr Daily Scrum Meeting benötigen

0
Minuten am Tag
100% vom Team
0
Minute (max) pro Teammitglied

Termin

Etablierte Termine

Fokus (Daily Scrum Meeting)

Gleicher Ort, gleiche Zeit

Scrum Master

Scrum Master wenn nötig

 

 

 

10 Keyfacts Daily Scrum: rumstehen will gelernt sein

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

Daily Scrum

​Ob Sie nun ganz genau dem Scrum Guide folgen oder nicht, es gibt für das Daily Scrum ein paar Techniken und Praktiken, die Sie einhalten sollten. Sie können die folgende Liste als Anhaltspunkte nutzen, um Ihr Daily Scrum oder aber auch jedes andere Daily Stand-Up zu verbessern.

​Meetingzeit begrenzen

Das Daily Scrum hat eine Timebox von 15 Minuten. Das bedeutet, es sind nicht 16 Minuten oder 20, sondern 15. Auch wenn Sie hier kein Verfechter vom Scrum Guide sind und in Ihrem Daily Stand-Up die Minuten anders festlegen, gilt: setzen Sie einen festen Rahmen! Und diesen Rahmen gilt es einzuhalten.

Überziehen ist tabu

​Nach 15 Minuten oder Ihrer festgelegten Zeit ist Schluss. Was nicht geschafft ist, ist nicht geschafft. Nutzen Sie diesen Input vom Daily Scrum bzw. Daily Stand-Up und versuchen Sie Ihren Prozess zu verbessern, die Probleme zu identifizieren und zu beseitigen. Ein Wecker sorgt für das sichere Ende.

​Bleiben Sie stehen

​Beim Namen Stand-Up leitet es sich direkt vom Namen ab, aber auch beim Daily Scrum gilt: Sie bleiben stehen! Fangen Sie erst gar nicht an, es sich bequem zu machen. Nutzen Sie Gestiken und kommunizieren Sie direkt mit Ihrem Gegenüber. Bewegen Sie sich, zeigen Sie und binden die Kollegen mit ein.

​Pflichtprogramm

​Der Teilnehmerkreis muss fokussiert sein. Bei einem Daily Scrum ist als Pflichtprogramm immer das Entwicklungsteam an Board. Der Scrum Master ist in der Regel dabei, auch wenn er optional sein kann. Nur wenn die richtigen Personen anwesend sind, lässt sich die Zeit auch optimal nutzen.

​Nutzen Sie das Taskboard

​Ob Sie das Daily Stand-Up bzw. Daily Scrum nun physikalisch durchführen oder auf ein verteiltes Daily Stand-Up zurückgreifen ist nebensächlich. Bei der physikalischen Variante versammeln Sie sich alle um das Board. Beim verteilten, digitalen Daily Scrum sollte das Board geöffnet sein und für jeden sichtbar. Vorteilhaft bei verteilten Daily Stand-Up‘s ist es, wenn die Teammitglieder visuell am Bildschirm sehen, über welche Aufgaben gesprochen wird (Mauszeiger, Farben, Einblendungen, etc.). Bei der physikalischen Variante vom Daily Stand-Up sollten die Teammitglieder einen Bezug durch Zeigen, Anfassen, etc. zu der Aufgabe herstellen, über die sie reden. Das Taskboard ist der zentrale Mechanismus, nutzen Sie ihn auch im Daily Scrum!

​Kleine Abwechslungen einbringen

​Beim Daily Scrum beantworten Sie drei Fragen, die sich um das Sprint Ziel ranken. Auch wenn diese Prozedur fix und fast formal ist, können Sie an anderer Stelle variieren: Nutzen Sie einmal ein Round-Robin-Verfahren um die Fragen zu beantworten, beim nächsten Mal nutzen Sie einen „Sprech-Token“ (bzw. einen kleinen Ball, nur wer den hat, spricht) oder etwas ganz anderes. Sie werden sehen, das tut recht gut!

​Mut zum Verschieben

​Gerade für den Scrum Master gilt: alles was nicht zielorientiert in das Meeting gehört, wird auf nach das Meeting verschoben. Abschweifende Diskussionen werden hier unterbunden. Es ist kein Problem noch eine technische Frage zu haben, aber die wird bitte im Anschluss mit den Beteiligten diskutiert.

​Pünktlich, pünktlich, pünktlich

​Starten Sie immer pünktlich. Es strahlt eine gewisse Wichtigkeit für das Daily Scrum aus, wenn es immer pünktlich beginnt und endet. Pünktlichkeit zeigt auch die Wichtigkeit des Meetings und zollte den anderen Beteiligten Respekt.

​Lächeln und Wertschätzung

​Für alle Teilnehmer ist eine angenehme Atmosphäre wichtig. Hier hilft es, die Teilnehmer beim Daily Stand-Up freundlich zu begrüßen oder am Ende des Daily Scrums nette Worte für das Scrum Team überzuhaben. Ein nettes Wort des Dankes zeigt auch, dass für den Moderator das Thema wichtig ist.

​Fokus, Fokus, Fokus

​Was für eine gute Meeting-Kultur gilt, gilt auch das das Daily Scrum. Es wird sich auf das konzentriert, was Thema ist und nicht nebenbei noch programmiert (soll auch Stand-Up Programmierer geben oder mit dem Smartphone die letzten Emails gecheckt. Nur durch den Fokus kann das Meeting kurz bleiben und artet nicht zu einem langen Unterfangen aus.