Scrum und bewährte Methoden

  • Artikel

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

Sprintplanungsbesprechungen

Ein Großteil der Sprintplanung besteht aus der Verhandlung zwischen dem Produktbesitzer und dem Team, um den Fokus und die Arbeit zu bestimmen, die im bevorstehenden Sprint bewältigt werden soll. Die Planungsbesprechung sollte auf höchstens 4 Stunden begrenzt werden.

Im ersten Teil der Besprechung trifft sich der Produktbesitzer mit dem Team, um die User Storys zu erörtern, die im Sprint enthalten sein können. Der Produktbesitzer informiert entsprechend und beantwortet alle Fragen des Team zu den betreffenden Storys. Diese Diskussion kann Details wie Datenquellen und Layout der Benutzeroberfläche offenlegen. Sie kann auch Erwartungen an Reaktionszeit und Überlegungen zu Sicherheit und Benutzerfreundlichkeit offenlegen. Ihr Team sollte diese Details im Backlog Item-Formular erfassen. In diesem Teil der Besprechung erfährt Ihr Team, was geleistet muss.

Bei der Planung der Sprints können Sie u. U. feststellen, dass weitere Anforderungen erfasst und zum Backlog hinzugefügt werden müssen. Stellen Sie sicher, dass sie gut definiert und in der Prioritätsreihenfolge festgelegt ist.

Darüber hinaus kann das Festlegen eines Sprintziels im Rahmen Ihrer Planungsbemühungen dazu beitragen, dass sich das Team auf das Wesentliche für den jeweiligen Sprint konzentriert.

Nachdem Sie Ihren Sprint geplant haben, können Sie den Plan wichtigen Stakeholdern mitteilen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Festlegen von Sprintzielen

Scrum-Teams verwenden Sprintziele, um die Sprintaktivitäten zu konzentrieren. Dieses Ziel wird häufig bei der Sprintplanungsbesprechung festgelegt. Das Ziel fasst zusammen, was das Team am Ende des Sprints erreicht haben möchte. Durch explizite Festlegung des Ziels entsteht im Team ein gemeinsames Verständnis für den zentralen Zweck. Das Sprintziel kann auch helfen, das Team zu leiten, wenn Konflikte um Prioritäten auftreten.

Tipps aus eigener Erfahrung: Definieren von Sprintzielen

Das Sprintziel definiert, was der Produktbesitzer und das Team als das letztendliche Ziel betrachten, das der jeweilige Sprint erreichen soll. Dabei handelt sich nicht um eine zufällige Auswahl von unzusammenhängenden Backlog Items, sondern um einen kurzen Text, der erfasst, was das Team erreichen sollte. Normalerweise definiert der Produktbesitzer das Sprintziel vor der Auswahl vieler Elemente für den nächsten Sprint. Die Elemente für diesen Sprint sollten alle zum jeweiligen gemeinsamen Ziel passen.

Sprintziele können featureorientiert sein, aber auch eine umfangreiche Prozesskomponente wie Bereitstellungsautomatisierung oder Testautomatisierung aufweisen.

Beispiel:

  • In diesem Sprint konzentrieren wir uns auf eine einfache User Story. Diese wird verwendet, um nachzuweisen, dass die vorgeschlagene Lösung funktioniert.
  • Dieser Sprint dreht sich um die Implementierung der Sicherheitsfeatures, die den administrativen Abschnitt der Website geeignet sichern.
  • Bei diesem Sprint geht es darum, die wichtigsten Zahlungsgateways zu integrieren, um Geldeinzahlungen zu möglichen.

Das Festlegen der Sprintziele hilft dem Team, fokussiert zu bleiben. Dadurch wird die Definition der Priorität von Aufgaben in einem Sprint erleichtert. Außerdem kann so die Anzahl der beteiligten Stakeholder und Endbenutzer möglicherweise begrenzt werden.

Bei der Sprintüberprüfung sollten Sie sich die entscheidende Frage stellen, ob Sie es geschafft haben, das Sprintziel zu erreichen. Die Anzahl der Storys, die erledigt wurden, kommt an zweiter Stelle. Wenn das Ziel erreicht wird, ist der Sprint erfolgreich, auch wenn nicht alle Storys erledigt wurden.

Beitrag von Jesse Houwing, Visual Studio Devops Ranger und Senior Consultant bei Avanade Netherlands.

Tipps für erfolgreiche Selektierungsbesprechungen

Das Beheben von Fehlern stellt einen Kompromiss mit anderen Arbeiten dar. Verwenden Sie Ihre Selektierungsbesprechung, um zu bestimmen, wie wichtig die Behebung der einzelnen Fehlers im Vergleich mit anderen Prioritäten wie Einhaltung von Projektumfang, Budget und Zeitplans ist.

  • Legen Sie die fest, welche Kriterien des Teams für die Entscheidung gelten, welche Fehler behoben werden sollen, und wie Priorität sowie Schweregrad zugewiesen werden. Fehlern im Zusammenhang mit Features von erheblichem Wert (oder erheblichen Opportunitätskosten durch Verzögerungen) oder anderen Projektrisiken sollten eine höhere Priorität und ein höherer Schweregrad zugewiesen werden. Speichern Sie Ihre Selektierungskriterien mit anderen Teamdokumenten, und aktualisieren Sie sie bei Bedarf.
  • Verwenden Sie Ihre Selektierungskriterien, um zu bestimmen, welche Fehler korrigiert werden sollen, und wie jeweils Zustand, Priorität, Schweregrad und andere Felder festgelegt werden.
  • Passen Sie Ihre Selektierungskriterien abhängig davon an, wo Sie sich im Entwicklungszyklus befinden. In frühen Phasen kann es sinnvoll sein, die meisten selektierten Fehler zu beheben. Später im Zyklus können Sie jedoch die Selektierungskriterien anheben, um die Anzahl der zu behebenden Fehler zu verringern.
  • Nachdem Sie einen Fehler selektiert haben, weisen Sie ihn einem Entwickler zu. Der Entwickler kann dann untersuchen und bestimmen, wie eine Korrektur implementiert werden kann.

Verwalten technischer Schulden

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

Tipps aus eigener Erfahrung: Fehlermanagement

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

Beseitigen von bekannten Fehlerschulden bei jedem Sprint

Das Team prüft bei jedem Sprint alle im Fehlerbacklog verbliebenen Fehler und stellt Kapazität zur Verfügung, um diese bekannten Fehler vollständig oder weitgehend zu beseitigen. Unabhängig davon, ob dies einen Tag, eine Woche oder den gesamten Sprint betrifft, werden die Fehler zuerst behoben. Fehler, die später im Sprints gefunden wurden, werden nicht als Teil dieser anfänglichen Verpflichtung 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 verpflichtungsbasierten Organisation. Häufig legt das Management einen hohen Wert auf die Fähigkeit eines Teams, seine 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 neuen Fehler, die während des Sprints entdeckt werden, sind nicht Teil der anfänglichen Verpflichtung und können im nächsten Sprint behandelt werden.

Verwalten von Fehlerschulden in einem Unternehmen

Beim Übergang zu einer Kultur, in der Schulden ständig beseitigt werden, beschäftigt sich eine Organisation wahrscheinlich mit der folgenden Frage: Wie können wir Teams dazu bringen, die Anzahl der Fehler zu reduzieren, ohne ihnen genau zu sagen, was zu tun ist? Die Führung möchte Änderungen im Team, gibt dem Team jedoch Autonomie bei der Bestimmung, wie die Änderung erfolgt. Eine Möglichkeit ist die Verwendung einer Fehlerobergrenze.

Betrachten Sie beispielsweise eine Fehlerobergrenze von drei Fehlern pro Entwickler. Daher sollte ein Team von 10 Personen nicht mehr als 30 Fehler im Fehlerbacklog haben. Wenn das Team die Obergrenze überschreitet, wird erwartet, dass es die Arbeit an neuen Features beendet, um die Fehlerobergrenze wieder zu unterschreiten. Es wird erwartet, dass ein Team immer unter seiner Obergrenze bleibt, das Team entscheidet jedoch selbst, wie dies vonstatten gehen soll. Die Fehlerobergrenze stellt sicher, dass Teams Fehlerschulden nicht zu lange mit sich tragen. Das Team kann aus den Fehlern lernen, die dazu führen, dass die Fehler überhaupt entstanden sind.

Denken Sie daran, dass die Fehlerobergrenze die Fehler im Fehlerbacklog darstellt. Sie 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.

Fehler tragen zwar zu technischen Schulden bei, stellen aber möglicherweise nicht alle Schulden dar.

Schlechtes Softwaredesign, schlecht geschriebener Code oder kurzfristige Fehlerbehebungen können zu technischen Schulden beitragen. Technische Schulden stellen die zusätzliche Entwicklungsarbeit dar, die sich aus all diesen Problemen ergibt.

Verfolgen Sie die Arbeit, um technische Schulden als Product Backlog Items, User Storys oder Fehler zu beheben. Um den Fortschritt eines Teams beim Verschulden und Beheben technischer Schulden nachzuverfolgen, sollten Sie überlegen, wie Sie das Arbeitselement und die Details, die Sie nachverfolgen möchten, kategorisieren. Sie können Tags zu den einzelnen Arbeitselementen hinzufügen, um diese in einer geeigneten Kategorie zu gruppieren.

Rolle des Scrum Masters

Die Aufgabe der Scrum Master besteht darin, mithilfe von Scrum-Prozessen effektiv arbeitende Teams aufzubauen und aufrechtzuerhalten. Sie leiten, coachen, unterrichten und unterstützen Scrum-Teams bei der richtigen Verwendung von Scrum-Methoden. Scrum Master fungieren auch als Change Agents, um Teams bei der Überwindung von Hindernissen zu helfen und das Team zu signifikanten Produktivitätssteigerungen anzuspornen.

Zu den zentralen Verantwortlichkeiten des Scrum Masters zählen:

  • Unterstützen des Teams bei der Einführung und Durchführung von Scrum-Prozessen. Beispielsweise sollten Sie die tägliche Scrum-Besprechung nicht zu einer offenen Diskussion werden lassen, die 45 Minuten dauert.

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

  • Beheben von Blockaden, die das Team daran hindern, Fortschritte zu machen. Diese Arbeit erfordert möglicherweise die Durchführung kleiner Aufgaben, z. B. das Genehmigen einer Bestellung für einen neuen Buildcomputer oder das Lösen eines Konflikts innerhalb Ihres Teams.

  • Unterstützen des Team bei der Lösung von auftretenden Konflikten und Problemen und Lernen aus dem Prozess.

  • Stellen von Fragen, die verborgene Probleme offenlegen, und Sicherstellen, dass das Kommunizierte vom gesamten Team gut verstanden wird.

  • Identifizieren und Schützen des Teams vor potenziellen Problemen, die zu schwerwiegenden Problemen werden. Genauso wie es billiger ist, einen Fehler kurz nach seiner Entdeckung zu beheben, ist es auch einfacher und weniger störend, ein Teamproblem zu beheben, solange es klein und handhabbar ist.

  • Verhindern, dass das Team während einer Sprintüberprüfungsbesprechung unvollständige User Storys präsentiert.

  • Erfassen, Analysieren und Präsentieren von Daten für Stakeholder im Unternehmen, um zu zeigen, wie sich das Team verbessert und entwickelt. Wenn Ihr Team beispielsweise den erzielten Nutzen erhöht hat, weil weniger Fehler entstanden sind, machen Sie den Nutzen durch regelmäßige Kommunikation mit den Stakeholdern sichtbar.

Gute Scrum Master verfügen über oder entwickeln hervorragende Kommunikations-, Verhandlungs- und Konfliktlösungsfähigkeiten. Sie hören aktiv auf das, was gesagt und geschrieben wird. Sie achten auch darauf, wie die Botschaften übermittelt werden, z. B. durch Körpersprache, Mimik, Aussprache und andere nonverbale Kommunikation.

Genauso wie es billiger ist, einen Fehler kurz nach seiner Entdeckung zu beheben, ist es auch einfacher und weniger störend, ein Teamproblem zu beheben, solange es klein und handhabbar ist, bevor es zu einem schwerwiegenden Problem wird.

Tägliche Scrum-Besprechungen

Tägliche Scrum-Besprechungen helfen einem Team dabei, sich darauf zu konzentrieren, was am nächsten Tag erledigt werden muss. Fokussiert zu bleiben, hilft dem Team, seine Fähigkeit zu maximieren, Sprint-Verpflichtungen zu erfüllen. Ihr Scrum Master sollte die Struktur der Besprechung festlegen und sicherstellen, dass sie rechtzeitig beginnt und nicht länger als 15 Minuten dauert.

Drei Aspekte erfolgreicher Scrum-Besprechungen sind:

  • Alle stehen auf. Stehen hilft, die Besprechungen fokussiert und kurz zu halten.
  • Sie beginnen und enden pünktlich und finden jeden Tag zur gleichen Zeit am selben Ort statt.
  • Alle nehmen 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 blockierenden Probleme oder Hindernisse können sich auf meine Arbeit auswirken?

Hinweis

Der Fokus für Scrum-Besprechungen liegt auf dem Status der Arbeit, die von einem Teammitglied an ein anderes Teammitglied weitergegeben werden muss.

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

„Gestern habe ich die Klasse aktualisiert, um das neue Datenelement zu berücksichtigen, das wir aus der Datenbank abrufen, und ich habe sie in der Schnittstelle implementiert. Die Aufgabe ist abgeschlossen. Heute werde ich sicherstellen, dass das neue Datenelement ordnungsgemäß mit der gespeicherten Prozedur und den anderen Datenelementen in der Tabelle berechnet wird. Ich glaube, ich kann diese Aufgabe heute erledigen. Ich brauche jemanden, der meine Berechnungen überprüft. Ich habe keine Hindernisse oder Blockierungsprobleme.“

Diese Antwort vermittelt, was das Teammitglied erreicht hat, was das Teammitglied erreichen wird und dass das Teammitglied Hilfe bei der Überprüfung des Codes wünscht.

Im Gegensatz dazu dieses nächste Beispiel:

„Gestern habe ich an der Klasse gearbeitet, und sie funktioniert. Heute werde ich an der Schnittstelle arbeiten. Keine Blockierungsprobleme.“

Das Teammitglied gibt nicht genügend Details für die bearbeitete Klasse und zu den Schnittstellenkomponenten an, die bearbeitet werden. Tatsächlich wurde nie gesagt, dass was erreicht wurde.

Es ist wichtig, dass keiner einen Berichtsvortrag unterbricht. Jede Person muss ausreichend Zeit haben, um die drei Fragen zu beantworten.

Nach der Besprechung sollten ausführlichere und Folgediskussionen stattfinden, wenn die Personen an ihren Schreibtisch zurückkehren. Wenn umfangreiche Erörterungen erforderlich sind, kann auch eine Folgebesprechung stattfinden.

Viele Teams verzögern Diskussionen mit der „virtueller Parkplatz“-Methode. 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 es mit den aufgelisteten Elementen umgeht.

Sprintüberprüfungsbesprechungen

Führen Sie Ihre Sprintüberprüfungsbesprechungen am letzten Tag des Sprints durch. Ihr Team demonstriert alle Product Backlog Items, die es im Sprint abgearbeitet hat. Der Produktbesitzer, Kunden und Projektbeteiligte akzeptieren die User Storys, die ihren Erwartungen entsprechen, und identifizieren alle neuen Anforderungen. Kunden verstehen ihre Bedürfnisse häufig umfassender, nachdem sie die Vorführungen gesehen haben, und identifizieren möglicherweise weitere wünschenswerte Änderungen.

Basierend auf dieser Besprechung werden einige User Storys als abgeschlossen akzeptiert. Unvollständige User Storys verbleiben im Product Backlog. Neue User Storys werden zum Backlog hinzugefügt. Beide Storygruppen werden in der nächsten Sprintplanungsbesprechung bewertet und abgeschätzt bzw. neu abgeschätzt.

Nach dieser Besprechung und der Retrospektivebesprechung plant Ihr Team den nächsten Sprint. Da sich Geschäftsanforderungen schnell ändern, können Sie diese Besprechung mit Ihrem Produktbesitzer, den Kunden und Stakeholdern nutzen, um die Prioritäten des Product Backlogs erneut zu überprüfen.

Sprintretrospektivebesprechungen

Gut und in regelmäßigen Abständen durchgeführte Retrospektiven ermöglichen eine kontinuierliche Verbesserung.

Die Retrospektivebesprechung findet in der Regel am letzten Tag des Sprints nach der Sprintüberprüfungsbesprechung statt. In dieser Besprechung untersucht Ihr Team die Scrum-Ausführung und mögliche Optimierungen.

Basierend auf Diskussionen kann Ihr Team Prozesse ändern, um die 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.

Hinweis

Um die Retrospektive Ihres Teams zu unterstützen, sollten Sie die Erweiterung für Retrospektiven im Marketplace installieren. Diese Erweiterung unterstützt das Sammeln von Feedback zu Ihren Projektmeilensteinen, das Organisieren und Priorisieren des Feedbacks sowie das Erstellen und Nachverfolgen von handlungsrelevanten Aufgaben, um Ihrem Team dabei zu helfen, im Laufe der Zeit besser zu werden.

Achten Sie darauf, dass die folgenden Bereiche während der Sprintretrospektiven Ihres Teams berücksichtigt werden:

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

  • Elemente, die sich auf die Gesamtzufriedenheit und den Projektflow Ihres Teams ausgewirkt haben.

  • Wie ist es dazu gekommen, dass nicht erledigte Backlog Items entstanden sind? Welche Maßnahmen kann das Team ergreifen, um diese Probleme in Zukunft zu verhindern?

    Betrachten Sie beispielsweise ein Team, dem mehrere Aufgaben zugewiesen wurden, die nur eine einzige Person im Team ausführen konnte. Durch die isolierte Kompetenz ist ein kritischer Pfad entstanden, der den Erfolg des Sprints gefährdet hat. Das einzelne Teammitglied musste zusätzliche Stunden leisten, während andere Teammitglieder frustriert waren, dass sie nicht mehr tun konnten, um zu helfen. Für die Zukunft entschied sich das Team, eXtreme Programming zu verwenden, um dieses Problem im Laufe der Zeit zu beheben.

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

Ihr Team muss möglicherweise einige Arbeit leisten, um eine Verbesserung zu implementieren. Beispielsweise hat sich ein Team, das sich durch zu viele fehlerhafte Builds beeinträchtigt befand, entschieden, Continuous Integration zu implementieren. Da sie den Prozess nicht unterbrechen wollten, waren vor der Aktivierung im Produktionsbuild einige Stunden notwendig, um einen Testbuild einzurichten. Um diese Arbeit darzustellen, wurde ein Spike erstellt und die Arbeit mit dem Rest des Product Backlogs abgeglichen.