Scrum und bewährte Methoden

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Besprechungen zur Sprintplanung

Ein Großteil der Sprintplanung umfasst eine Aushandlung zwischen dem Produktbesitzer und dem Team, um den Fokus und die Arbeit zu bestimmen, die im bevorstehenden Sprint angegangen werden soll. Es ist nützlich, die Planungsbesprechung zeitlich zu begrenzen und auf 4 Stunden oder weniger zu beschränken.

Im ersten Teil der Besprechung trifft sich Ihr Produktbesitzer mit Ihrem Team, um die Benutzergeschichten zu besprechen, die möglicherweise im Sprint enthalten sind. Ihr Produktbesitzer teilt Informationen und beantwortet alle Fragen, die Ihr Team zu diesen Geschichten hat. In dieser Unterhaltung werden möglicherweise Details wie Datenquellen und Benutzeroberflächenlayouts angezeigt. Oder es kann die Erwartungen an die Reaktionszeiten und Überlegungen für Sicherheit und Benutzerfreundlichkeit offenlegen. Ihr Team sollte diese Details im Formular für Backlogelemente erfassen. Während dieses Teils der Besprechung lernt Ihr Team, was es erstellen muss.

Während Sie Ihre Sprints planen, können Sie andere Anforderungen zum Erfassen und Hinzufügen zu Ihrem Backlog ermitteln. Stellen Sie sicher, dass sie gut definiert und in der Prioritätsreihenfolge festgelegt ist.

Außerdem kann das Festlegen eines Sprintziels als Teil Ihrer Planungsbemühungen dazu beitragen, dass sich das Team auf das Wichtigste für jeden Sprint konzentriert.

Nachdem Sie Ihren Sprint geplant haben, können Sie den Plan mit wichtigen Projektbeteiligten teilen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Was ist Scrum?
• Whitepaper zur Sprintplanung
• Der Scrum Guide
• Erstellen und Verwalten des Product Backlog-Whitepapers

Festlegen von Sprintzielen

Scrum-Teams verwenden Sprintziele, um ihre Sprintaktivitäten zu konzentrieren. Sie legen dieses Ziel oft während ihrer Sprintplanungsbesprechung fest. Das Ziel fasst zusammen, was das Team bis zum Ende des Sprints erreichen möchte. Durch explizite Angabe des Ziels schaffen Sie ein gemeinsames Verständnis innerhalb des Teams des Kernzwecks. Das Sprintziel kann auch helfen, das Team zu leiten, wenn Konflikte um Prioritäten entstehen.

Tipps aus den Graben: Sprintziele definieren

Das Sprintziel definiert, was der Produktbesitzer und das Team als ultimatives Ziel betrachten, um diesen Sprint zu erreichen. Es ist keine zufällige Auswahl von Backlogelementen, die nicht wirklich eine Beziehung haben, sondern ein kurzer Textabschnitt, der erfasst, was das Team erreichen sollte. Normalerweise legt der Product Owner das Sprintziel fest, bevor er einzelne Elemente für den nächsten Sprint auswählt. Die Elemente für diesen Sprint sollten alle diesem gemeinsamen Ziel entsprechen.

Sprintziele können funktionsorientiert sein, aber auch eine große Prozesskomponente wie Bereitstellungsautomatisierung oder Testautomatisierung haben.

Beispiel:

• Dieser Sprint konzentrieren wir uns auf eine einfache Benutzergeschichte. Wir verwenden es, um zu beweisen, dass die vorgeschlagene Lösung funktioniert.
• Dieser Sprint dreht sich um die Implementierung der Sicherheitsfeatures, die den Verwaltungsabschnitt der Website ordnungsgemäß sichern.
• Dieser Sprint geht es darum, die wichtigsten Zahlungsgateways zu integrieren, damit wir mit dem Sammeln von Geld beginnen können.

Das Festlegen der Sprintziele hilft dem Team, fokussiert zu bleiben. Es erleichtert das Definieren der Priorität von Aufgaben innerhalb eines Sprints und hilft wahrscheinlich, die Anzahl der beteiligten Projektbeteiligten und Endbenutzer einzuschränken.

Während der Sprintüberprüfung sollten Sie sich die wichtigste Frage stellen, ob Sie es geschafft haben, das Sprintziel zu erreichen. Wie viele Geschichten Sie abgeschlossen haben, ist zweitrangig. Wenn das Ziel erreicht wird, gelingt der Sprint, auch wenn nicht alle Geschichten fertig waren.

Beigetragen von Jesse Houwing, Visual Studio devops Ranger und einem leitenden Berater für Avanade Netherlands.

Tipps zur erfolgreichen Durchführung von Triage-Besprechungen

Das Beheben von Fehlern stellt einen Kompromiss mit anderen Arbeiten dar. Nutzen Sie die Triage-Besprechung, um die Wichtigkeit der Fehlerbehebung gegenüber anderen Prioritäten zu gewichten, die mit Projektumfang, Budget und Zeitplan in Verbindung stehen.

• Legen Sie die Kriterien des Teams fest, um zu bewerten, welche Fehler behoben werden sollen und wie Priorität und Schweregrad zugewiesen werden. Fehler, die mit Features von erheblichem Wert (oder erheblichen Chancenkosten von Verzögerung) oder anderen Projektrisiken verbunden sind, sollten höhere Priorität und Schweregrad zugewiesen werden. Speichern Sie Ihre Triagekriterien mit anderen Teamdokumenten, und aktualisieren Sie sie nach Bedarf.
• Verwenden Sie Ihre Triagekriterien, um zu bestimmen, welche Fehler behoben werden sollen, und wie deren Status, Priorität, Schweregrad und andere Felder festgelegt werden.
• Passen Sie Die Triagekriterien basierend auf der Position, an der Sie sich im Entwicklungszyklus befinden, an. In frühen Phasen kann es sinnvoll sein, die meisten selektierten Fehler zu beheben. Später im Zyklus können Sie jedoch die Triagekriterien erhöhen, um die Anzahl der Fehler zu verringern, die Sie beheben müssen.
• Nachdem Sie einen Fehler analysiert haben, weisen Sie ihn einem Entwickler zu. Der Entwickler kann dann untersuchen und bestimmen, wie ein Fix implementiert wird.

Verwalten Ihrer technischen Schulden

Erwägen Sie die Verwaltung Ihrer Fehlerbürde und technischen Schulden als Teil der Gesamtheit kontinuierlicher Verbesserungsaktivitäten Ihres Teams. Möglicherweise finden Sie diese Ressourcen von Interesse:

• Good and Bad Technical Debt (and how TDD helps) von Henrik Kniberg
• Managing Technical Debt veröffentlicht von Sven Johann & Eberhard Wolff

Tipps aus der Praxis: Fehlerverwaltung

Agile Fehlerverwaltung: Kein Oxymoron
von Gregg Boer, Principal Program Manager, Visual Studio Cloud Services bei Microsoft

Beseitigen von bekannten Fehlerschulden bei jedem Sprint

Bei jedem Sprint betrachtet das Team alle fehler, die im Bug-Backlog verbleiben, und widmet sich der Kapazität, diese bekannte Gruppe von Fehlern auf Null oder nahe Null zu bringen. Unabhängig davon, ob es sich um einen Tag, eine Woche oder den gesamten Sprint handelt, beheben sie zuerst die Fehler. Fehler, die später innerhalb des Sprints gefunden wurden, werden nicht als Teil dieses anfänglichen Engagements betrachtet. Sofern sie keine hohe Priorität haben, werden sie in das Fehlerbacklog für den nächsten Sprint eingefügt.

Viele Teams arbeiten in einer engagementbasierten Organisation. Häufig legt das Management einen hohen Wert auf die Fähigkeit eines Teams, ihre Verpflichtungen zu erfüllen. Die Kapazitätsplanung für mehrere bekannte Fehler macht die Sprintplanung deterministischer und erhöht die Wahrscheinlichkeit, Verpflichtungen zu erfüllen. Alle neu entdeckten Fehler während des Sprints sind nicht Teil der anfänglichen Verpflichtung und können im nächsten Sprint behandelt werden.

Verwalten von Fehlerschulden in einem Unternehmen

Eine Organisation, die zu einer Kultur wechselt, in der Schulden ständig eliminiert werden, geht wahrscheinlich mit der folgenden Frage um: Wie können Sie Teams dazu bringen, ihre Fehleranzahl zu reduzieren, ohne ihnen genau mitzuteilen, was sie tun müssen? Die Führung möchte, dass sich das Team ändert, aber dem Team die Autonomie gibt, um zu bestimmen, wie sie sich ändern. Eine Möglichkeit besteht darin, eine Schutzkappe zu verwenden.

Betrachten Sie z. B. eine Fehlergrenze von drei Fehlern pro Techniker. Daher sollte ein Team von 10 Personen nicht mehr als 30 Fehler im Fehlerrückstand haben. Wenn das Team über seiner Obergrenze liegt, wird erwartet, dass es die Arbeit an neuen Funktionen einstellt und unter die Fehlergrenze geht. Es wird erwartet, dass ein Team immer unter seiner Obergrenze bleibt, das Team entscheidet jedoch selbst, wie dies vonstatten gehen soll. Die Bug-Begrenzung stellt sicher, dass Teams nicht zu lange auf Bug-Schulden sitzen bleiben. Das Team kann aus den Fehlern lernen, die dazu führen, dass die Fehler überhaupt entstanden sind.

Denken Sie daran, dass die Bug-Grenze die Fehler im Bug-Backlog darstellt. Es enthält keine Fehler, die innerhalb des Sprints gefunden und behoben wurden, in dem ein Feature entwickelt wird. Diese Fehler gelten als unerledigte Arbeit, nicht als Schulden.

Während Fehler zu technischen Schulden beitragen, stellen sie möglicherweise nicht alle Schulden dar.

Schlechtes Softwaredesign, schlecht geschriebener Code oder kurzfristige Korrekturen können alle zu technischen Schulden beitragen. Technische Schulden spiegeln zusätzliche Entwicklungsarbeiten wider, die aus all diesen Problemen entstehen.

Verfolgen Sie die Arbeit, um technische Schulden als Product Backlog Items, User Storys oder Fehler zu beheben. Um den Fortschritt eines Teams beim Entstehen und Beheben von technischen Schulden nachzuverfolgen, sollten Sie überlegen, wie Sie die Arbeitsaufgabe und die Details kategorisieren, die Sie nachverfolgen möchten. Sie können jeder Arbeitsaufgabe Tags hinzufügen, um sie in einer Kategorie Ihrer Wahl zu gruppieren.

Rolle des Scrum Master

Scrum Masters helfen dabei, gesunde Teams zu erstellen und aufrechtzuerhalten, indem Scrum-Prozesse verwendet werden. Sie führen, coachen, unterrichten und unterstützen Scrum-Teams bei der richtigen Beschäftigung von Scrum-Methoden. Scrum Masters fungieren auch als Change Agents, um Teams dabei zu helfen, Hindernisse zu überwinden und das Team auf signifikante Produktivitätssteigerungen zu lenken.

Zu den Kernaufgaben von Scrum Masters gehören:

• Unterstützen Sie das Team, Scrum-Prozesse zu übernehmen und zu verfolgen. Sie sollten beispielsweise nicht zulassen, dass die tägliche Scrum-Besprechung zu einer offenen Diskussion wird, die 45 Minuten dauert.

• Verhindern, dass Produktbesitzer oder Teammitglieder Arbeiten nach Beginn des Sprints hinzufügen.

• Löschen Sie Blockierungsprobleme, die verhindern, dass das Team fortschritte macht. Diese Arbeit erfordert möglicherweise, dass Sie kleine Aufgaben ausführen, z. B. die Genehmigung einer Bestellung für einen neuen Buildcomputer oder das Lösen eines Konflikts innerhalb Ihres Teams.

• Helfen Sie dem Team, Konflikte und Probleme zu lösen, die auftreten und aus dem Prozess lernen.

• Stellen Sie Fragen, die verborgene Probleme offenlegen, und stellen Sie sicher, dass das, was die Leute kommunizieren, vom gesamten Team gut verstanden wird.

• Identifizieren und schützen Sie das Team vor potenziellen Problemen, die zu wichtigen Problemen werden. Genau wie es günstiger ist, einen Fehler bald nach der Entdeckung zu beheben, ist es auch einfacher und weniger störend, ein Teamproblem zu beheben, wenn es klein und verwaltbar ist.

• Verhindern, dass das Team unvollständige Benutzergeschichten während einer Sprintüberprüfungsbesprechung vorstellt.

• Sammeln, analysieren und präsentieren Sie Daten für Geschäftsbeteiligte, um zu veranschaulichen, wie das Team verbessert und wächst. Wenn Ihr Team beispielsweise den Wert erhöht hat, den es bereitgestellt hat, während weniger Fehler generiert werden, machen Sie den Wert durch regelmäßige Kommunikation mit den Geschäftsbeteiligten sichtbar.

Gute Scrum Masters verfügen über hervorragende Kommunikations-, Verhandlungs- und Konfliktlösungskompetenzen. Sie hören aktiv auf die Wörter, die menschen sagen und schreiben. Sie hören auch, wie sie ihre Botschaften liefern, z. B. ihre Körpersprache, Gesichtsausdrücke, Stimmtempo und andere nonverbale Kommunikation.

Genau wie es günstiger ist, einen Fehler bald nach der Entdeckung zu beheben, ist es auch einfacher und weniger störend, ein Teamproblem zu beheben, wenn es klein und verwaltbar ist, bevor es zu einem großen Problem wird.

Tägliche Scrum-Besprechungen

Tägliche Scrum-Besprechungen helfen, ein Team darauf zu konzentrieren, was es am nächsten Tag tun muss. Wenn Sie fokussiert bleiben, kann das Team seine Fähigkeit zur Erfüllung von Sprintverpflichtungen maximieren. Ihr Scrum Master sollte die Struktur der Besprechung erzwingen und sicherstellen, dass sie rechtzeitig beginnt und in 15 Minuten oder weniger endet.

Drei Aspekte erfolgreicher Scrum-Besprechungen sind:

• Jeder steht auf. Das Stehen hilft, die Besprechungen fokussiert und kurz zu halten.
• Sie beginnen und enden rechtzeitig und treten an derselben Stelle jeden Tag auf
• Jeder nimmt teil, jedes Teammitglied beantwortet die drei Scrum-Fragen:
  • Was habe ich seit dem letzten Scrum erreicht?
  • Was kann ich vor dem nächsten Scrum erreichen?
  • Welche Blockierungsprobleme oder Hindernisse können sich auf meine Arbeit auswirken?

Teammitglieder sollten sich bemühen, ihre Fragen schnell und präzise zu beantworten. Beispiel:

Gestern habe ich die Klasse aktualisiert, um das neue Datenelement wiederzugeben, das wir aus der Datenbank abzurufen, und ich habe es geschafft, es in der Schnittstelle erscheinen zu lassen. Diese Aufgabe ist abgeschlossen. Heute stellen wir sicher, dass das neue Datenelement korrekt mit der gespeicherten Prozedur und den anderen Datenelementen in der Tabelle berechnet wird. Ich glaube, ich kann diese Aufgabe heute erledigen. Ich benötige jemanden, um meine Berechnungen zu überprüfen. Ich habe keine Hindernisse oder Blockierungsprobleme."

Diese Antwort vermittelt, was das Teammitglied erreicht hat, was das Teammitglied erreichen will und dass das Teammitglied hilfe beim Betrachten des Codes wünschen soll.

Kontrast zu diesem nächsten Beispiel:

"Gestern habe ich an der Klasse gearbeitet, und es funktioniert. Heute arbeite ich an der Schnittstelle. Keine Blockierungsprobleme."

Das Teammitglied bietet nicht genügend Details darüber, an welcher Klasse es gearbeitet hat, noch darüber, welche Schnittstellenkomponenten es abschließen wird. Tatsächlich kam das wort erreicht nie auf.

Es ist wichtig, dass niemand während der Berichterstattung unterbricht. Jede Person muss ausreichend Zeit haben, um die drei Fragen zu beantworten.

Eingehendere und nachfolgende Gespräche sollten nach der Besprechung stattfinden, wenn die Personen zu ihren Schreibtischen zurückkehren, oder, falls eine erhebliche Menge an Unterhaltungen erforderlich ist, in einer Folgebesprechung.

Viele Teams verzögern Diskussionen mit der Methode „virtueller Parkplatz“. Wenn Themen auftauchen, für die ein Teammitglied weitere Diskussionen erforderlich hält, kann es ruhig zu einem Whiteboard oder Flipchart gehen und das Thema im „Parkplatz“ auflisten. Am Ende der Besprechung bestimmt das Team, wie die aufgelisteten Elemente behandelt werden.

Sprintüberprüfungsbesprechungen

Führen Sie Ihre Sprintüberprüfungsbesprechungen am letzten Tag des Sprints durch. Ihr Team veranschaulicht jedes Produktrückstandselement, das im Sprint abgeschlossen wurde. Der Produktbesitzer, die Kunden und die Projektbeteiligten akzeptieren die Benutzergeschichten, die ihren Erwartungen entsprechen, und identifizieren neue Anforderungen. Kunden verstehen ihre Bedürfnisse häufig vollständiger, nachdem Sie die Demonstrationen gesehen haben, und identifizieren möglicherweise Änderungen, die sie sehen möchten.

Basierend auf dieser Besprechung werden einige Benutzergeschichten als abgeschlossen angenommen. Unvollständige Benutzergeschichten verbleiben im Produktrücklog. Neue Benutzergeschichten werden dem Backlog hinzugefügt. Beide Storygruppen werden in der nächsten Sprintplanungsbesprechung bewertet und abgeschätzt bzw. neu abgeschätzt.

Nach dieser Besprechung und der retrospektiven Besprechung plant Ihr Team den nächsten Sprint. Da sich die geschäftlichen Anforderungen schnell ändern, können Sie diese Besprechung mit Ihrem Product Owner, Ihren Kunden und den Projektbeteiligten nutzen, um die Prioritäten des Produkt-Backlogs erneut zu überprüfen.

Sprintretrospektivbesprechungen

Retrospektiven, wenn sie gut und in regelmäßigen Abständen durchgeführt werden, unterstützen eine kontinuierliche Verbesserung.

Die Sprint-Retrospektive-Besprechung tritt in der Regel am letzten Tag des Sprints nach der Sprintüberprüfungsbesprechung auf. In dieser Besprechung erörtert Ihr Team seine Durchführung von Scrum und welche Anpassungen möglicherweise notwendig sind.

Basierend auf Diskussionen kann Ihr Team einen oder mehrere Prozesse ändern, um seine eigene Effektivität, Produktivität, Qualität und Zufriedenheit zu verbessern. Diese Besprechung und die daraus resultierenden Verbesserungen sind entscheidend für das agile Prinzip der Selbstorganisation.

Sehen Sie sich diese Bereiche während Ihrer Team-Sprint-Retrospektive an:

• Probleme, die sich auf die allgemeine Effektivität, Produktivität und Qualität Ihres Teams auswirken.

• Elemente, die sich auf die Gesamtzufriedenheit und den Projektfluss Ihres Teams auswirken.

• Was ist passiert, dass es zu unvollständigen Backlogelementen gekommen ist? Welche Maßnahmen kann das Team ergreifen, um diese Probleme in Zukunft zu verhindern?

  Ziehen Sie beispielsweise ein Team in Betracht, das mehrere Aufgaben hatte, die nur eine Einzelperson im Team ausführen konnte. Die isolierte Expertise schuf einen kritischen Weg, der den Erfolg des Sprints bedrohte. Das einzelne Teammitglied legte zusätzliche Stunden ein, während andere Teammitglieder frustriert waren, dass sie nicht mehr tun konnten, um Hilfe zu leisten. In Zukunft beschloss das Team, eXtreme Programming zu üben, um dieses Problem im Laufe der Zeit zu beheben.

Arbeiten Sie als Team daran, zu bestimmen, ob ein oder mehrere Prozesse angepasst werden sollen, um das Auftreten von Problemen während des Sprints zu minimieren.

Möglicherweise muss Ihr Team einige Schritte unternehmen, um eine Verbesserung zu implementieren. Beispielsweise entschied sich ein Team, das sich negativ von zu vielen fehlgeschlagenen Builds betroffen fand, um eine kontinuierliche Integration zu implementieren. Da sie den Prozess nicht stören wollten, benötigten sie einige Stunden, um einen Test-Build einzurichten, bevor sie ihn in ihrem Produktions-Build aktivierten. Um diese Arbeit darzustellen, wurde ein Spike erstellt und die Arbeit mit dem Rest des Product Backlogs abgeglichen.

Verwandte Inhalte

• Ende der Sprintaktivitäten
• Was ist Scrum?
• Agile Retrospektive: Gute Teams großartig machen