Arbeitsaufgabentypen und Workflow für Scrum-Prozessvorlagen

Zum Planen von Softwareprojekten und Nachverfolgen von Softwarefehlern mit Scrum setzen Teams das Product Backlog Item (PBI)- und den Bug-Arbeitsaufgabentyp (Work Item Type, WIT) ein. Um Einblick in ein Portfolio von Funktionen, Szenarien oder Benutzeroberflächen zu erhalten, können Produktbesitzer und Programmmanager PBIs und Fehler Funktionen zuordnen. Wenn Teams in Sprints arbeiten, werden Aufgaben definiert, die automatisch mit PBIs und Fehlern verknüpft werden.

Scrum 3.0-Arbeitsaufgabentypen

Mithilfe von Microsoft Test-Manager und dem Team Web Access (TWA) können Tester Testfälle erstellen und ausführen sowie Fehler erstellen, mit denen sich defekter Code nachverfolgen lässt. Impedimente verfolgen Blockierungsprobleme nach.

Definieren des Backlog mit PBIs und Fehlern

Wenn Sie ein Product Backlog Item definieren, möchten Sie sich auf den Wert, den die Kunden erhalten, konzentrieren und Beschreibungen vermeiden, wie das Team die Funktion entwickelt. Der Produktbesitzer kann den Produktrückstand basierend auf dem Geschäftswert jedes Elements, dem Aufwand und der relativen Abhängigkeit von anderen Rückstandselementen priorisieren. Mit steigenden geschäftlichen Anforderungen wächst auch der Product Backlog. Typischerweise legen Teams nur für die Elemente mit der höchsten Priorität Details fest oder für solche, die dem aktuellen und dem nächsten Sprint zugewiesen sind.

Sie können PBIs und Fehler im Bereich "Schnelles Hinzufügen" auf der Product Backlog-Seite erstellen.

Dem Produktrückstand ein Element hinzufügen

Später können Sie jedes PBI bzw. Fehler öffnen, um weitere Informationen bereitzustellen und den Aufwand einzuschätzen. Durch Priorisieren der PBIs und Fehler auf der Backlog-Seite (die im Feld "Backlog Priorität" aufgezeichnet wird), können Produktbesitzer angeben, welchen Elementen höhere Priorität zugewiesen werden soll.

Arbeitsaufgabenformular Produktrückstandsobjekt

Durch das Definieren des Aufwands für PBIs und Fehler können Teams anhand der Vorhersagefunktion und Geschwindigkeitsdiagramme zukünftige Sprints oder den Arbeitsaufwand einschätzen. Durch Definieren des Geschäftswerts können Produktbesitzer Prioritäten getrennt von der veränderbaren Backlog-Stapelklassifizierung angeben.

Verwenden Sie die folgenden Anweisungen für diese grundlegenden Felder. Ausführliche Informationen zum Erstellen von Fehlern finden Sie unter Nachverfolgen von Codefehlern weiter unten in diesem Thema.

Feld/Registerkarte

Verwendung

Aufwand

Schätzen Sie den Arbeitsaufwand zum Fertigstellen eines PBI in der vom Team bevorzugten Maßeinheit ab, ob T-Shirt-Größe, Storypunkte oder Zeit.

Von flexiblen Geschwindigkeitsdiagrammen und Vorhersagetools wird auf die Werte in diesem Feld verwiesen. Dies ist ein Pflichtfeld zum Generieren des Release-Burndown-Berichts und des Geschwindigkeit-Berichts.

Weitere Anleitungen finden Sie im Whitepaper zum Thema Schätzung.

Geschäftswert

Geben Sie eine Zahl an, die den relativen Wert eines PBI im Vergleich mit anderen PBIs darstellt. Je größer die Zahl, desto größer ist der Geschäftswert.

Beschreibung (PBIs)

Geben Sie genug Details zur Einschätzung des Arbeitsaufwands zur Implementierung des Elements an. Konzentrieren Sie sich auf die vorgesehenen Anwender der Funktion: Was soll erreicht werden, und weshalb? Beschreiben Sie nicht, wie die Funktion entwickelt werden soll. Stellen Sie ausreichende Informationen bereit, damit das Team Aufgaben und Testfälle schreiben kann, um das Element zu implementieren.

Akzeptanzkriterien

Definieren und beschreiben Sie die Fertigstellungskriterien, anhand derer das Team überprüfen soll, ob das PBI oder die Fehlerkorrektur vollständig implementiert wurde.

Beschreiben Sie vor dem Beginn der Arbeit an einem PBI oder Fehler die Kundenakzeptanzkriterien so klar wie möglich. Durch Gespräche zwischen dem Team und den Kunden zur Bestimmung der Akzeptanzkriterien wird ein allgemeines Verständnis der Kundenerwartungen im Team sichergestellt. Die Akzeptanzkriterien können als Grundlage für Akzeptanztests verwendet werden, damit das Team effektiver auswerten kann, ob ein Element zufriedenstellend abgeschlossen wurde.

Mehr über den Einsatz der Product Backlog-Seite finden Sie hier.

Nachverfolgen des Fortschritts

Teams können mithilfe des Kanban-Boards den Status von PBIs und Fehlern und mithilfe des Sprint-Task Boards den Status von Aufgaben nachverfolgen. Durch Ziehen von Elementen zu einer neuen Zustandsspalte werden die Felder Zustand und Grund aktualisiert.

Element in eine andere Spalte verschieben

Eine typische Workflowprogression für PBIs und Bugs folgt:

  • Der Produktbesitzer erstellt ein PBI oder ein Tester erstellt einen Fehler im Zustand Neu mit dem Standardgrund Neues Backlogelement.

  • Das Element wird vom Produktbesitzer nach Bestätigt verschoben, sobald eine ausreichende Beschreibung vorliegt und das Team den entsprechenden Aufwand schätzen kann. In der Regel befinden sich Elemente im oberen Product Backlog-Bereich im Zustand "Genehmigt", während Elemente in der Mitte oder im unteren Bereich den Zustand "Neu" aufweisen.

  • Der Status wird vom Team auf Zugesichert aktualisiert, wenn die Entscheidung getroffen wird, die Arbeiten in diesem Sprint abzuschließen.

  • Ein Element wird in den Zustand Fertig verschoben, wenn das Team alle zugehörigen Aufgaben abgeschlossen hat und der Produktbesitzer zustimmt, dass es gemäß der Akzeptanzkriterien implementiert wurde.

Durch das Aktualisieren des Workflowstatus erhalten die Teams Informationen darüber, welche Elemente neu sind, sich in Bearbeitung befinden oder abgeschlossen wurden. Die meisten WITs unterstützen den Übergang von jedem Workflowzustand vor- und rückwärts.

Sie können Kanban-Board anpassen, damit weitere Verantwortlichkeitsbereiche oder Spalten unterstützt werden. Sie können auch den Workflow für das PBI und die Aufgaben-WITs anpassen, wodurch die Standardspaltenüberschriften geändert werden.

Zur Verwendung dieser Tools siehe Arbeiten am Kanban-Board und Verwenden von Sprints.

Zuordnen von PBIs zu Funktionen

Wenn Sie eine Gruppe von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Definieren Sie dazu Funktionen und ordnen Sie diesen PBIs zu.

Auf der Funktions-Backlog-Seite können Sie Funktionen genauso schnell hinzufügen wie PBIs.

Funktionen aus dem Funktionsbacklog schnell hinzufügen

Die Funktionsarbeitsaufgabe enthält ähnliche Felder, wie für PBIs bereitgestellt werden. Neben der Priorität und dem Geschäftswert können Sie das Zieldatum angeben, bis zu dem die Funktion implementiert werden soll.

Funktionsarbeitsaufgabenformular

Ziehen Sie von der Backlog-Seite mit aktivierter Zuordnungsfunktion PBIs zu der Funktion, die sie implementieren.

PBI einer Funktion zuordnen

Diese Zuordnung erstellt Links zwischen übergeordneten und untergeordneten Daten von der Funktion zu PBIs, was auf der Registerkarte Implementierung aufgezeichnet wird.

Mithilfe von Portfolio-Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem können Sie Portfoliobacklogs verwenden, um einen Rollup der in Bearbeitung befindlichen Aufgaben für mehrere Teams anzeigen, wenn Sie eine Hierarchie für die Teams festlegen.

Definieren der Aufgaben, die zur Implementierung von PBIs und Fehlern erforderlich sind

Wenn das Team die Arbeiten in Sprints verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in verschiedene Aufgaben zu untergliedern.

Einem Element im Sprint-Backlog eine Aufgabe hinzufügen

Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit.

Titel und Schätzung der Stunden hinzufügen

Mit Scrum planen die Teams die Arbeit und definieren die Aufgaben zu Beginn jedes Sprints. Dabei führt jedes Teammitglied einen Teil dieser Aufgaben aus. Zu Aufgaben zählen Entwicklung, Tests und andere Arbeitsschritte. Zum Beispiel kann ein Entwickler Aufgaben definieren, um PBIs zu implementieren, und ein Tester kann Aufgaben definieren, um Testfälle zu schreiben und auszuführen.

Wenn der Aufwand in Stunden oder Tagen geschätzt wird, definieren die Teams Aufgaben sowie die optionalen Felder Verbleibende Arbeit und Aktivität.

Feld

Verwendung

Verbleibende Arbeit

Geben Sie an, wie viele Stunden oder Arbeitstage bis zum Abschluss einer Aufgabe verbleiben. Aktualisieren Sie dieses Feld im Verlauf der Arbeit. Es wird zum Berechnen von Kapazitätsdiagrammen, des Sprint-Burndown Diagramms und des Sprint-Burndown (Scrum)-Berichts verwendet.

Wenn Sie eine Aufgabe in Unteraufgaben unterteilen, geben Sie die verbleibende Arbeit nur für die Unteraufgaben an. Sie können die Arbeit in einer die oft ausgegebene Befehlszeilen Maßeinheit angeben, ganz nach Wunsch des Teams.

Aktivität

Wählen Sie den Aktivitätstyp aus, den diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt. Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.

Nachverfolgen des Teststatus

Testen von Product Backlog Items

Im Test Manager oder TWA können Sie Testfälle erstellen, die automatisch eine Verknüpfung zu PBI erstellen.

Testauflistung auswählen und einen Testfall hinzufügen

Der Testfall enthält mehrere Felder, von denen viele automatisiert und in Test Manager und im Buildprozess integriert sind. Eine Beschreibung jedes Felds finden Sie unter Feldverweis für Build- und Testintegration.

Arbeitsaufgabenformular für Testfall

Die Registerkarte Getestete Backlog Items führt alle PBIs und Fehler in einem Testfall auf. Durch das Verknüpfen von PBIs und Fehlern mit Testfällen kann das Team den Fortschritt der Tests nachverfolgen, die für jedes Element ausgeführt werden.

Nachverfolgen von Codefehlern mithilfe von Fehlern

Sie können Fehler über TWA, Visual Studio erstellen oder beim Testen mit Test Manager.

Fehlerarbeitsaufgabenformular für Scrum-Prozessvorlage

Feld/Registerkarte

Verwendung

Reproduktionsschritte

Zeichnen Sie ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens.

Beschreiben Sie die Kriterien, die das Team verwenden soll, um zu überprüfen, dass der Fehler behoben ist.

Schweregrad

Eine subjektive Bewertung der Auswirkungen eines Fehlers auf das Projekt. Zulässige Werte sind:

  • 1: Kritisch

  • 2: Hoch

  • 3: Mittel

  • 4: Niedrig

Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.

Systeminfo

In Build gefunden

In den Build integriert

Wenn Test Manager Fehler erstellt, werden die Felder Systeminfo und In Build gefunden mit Informationen über die Softwareumgebung und den Build, in dem der Fehler auftrat, automatisch ausgefüllt. Mehr über das Definieren der Softwareumgebung erfahren Sie unter Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von DatenGeben Sie beim Beheben des Fehlers unter In den Build integriertden Namen des Builds ein, der den Code enthält, mit dem der Fehler korrigiert wird.

Wenn Sie mit einem Dropdownmenü auf alle Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für "In Build gefunden" und "In Build integriert" aktualisieren, sodass diese auf eine globale Liste verweisen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen dazu finden Sie unter Felder, die die Integration in die Test-, Build- und Versionskontrolle unterstützen.

Weitere Informationen zum Definieren von Buildnamen finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen.

Definieren allgemeiner Felder und Registerkarten von Arbeitsaufgaben

In den meisten Arbeitsaufgabenformularen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. Verlauf, Links oder Anlagen. Auf diesen drei Registerkarten werden jeweils der Änderungsverlauf, eine Ansicht der verknüpften Arbeitsaufgaben sowie die Möglichkeit zum Anzeigen und Anfügen von Dateien bereitgestellt.

Das einzige Pflichtfeld ist Titel. Beim Speichern der Arbeitsaufgabe wird dieser vom System eine eindeutige ID zugewiesen.

Feld/Registerkarte

Verwendung

Titel (erforderlich)

Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern.

Zugewiesen an

Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu. Ja nach dem Kontext der Arbeiten werden im Dropdownmenü nur Teammitglieder oder am Teamprojekt Mitwirkende aufgeführt.

Zustand

Verwenden Sie zunächst den Standardwert. Aktualisieren Sie den Wert im Verlauf der Arbeit mit dem aktuellen Zustand.

Informationen zum Ändern der Dropdownliste mit Zuständen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp.

Grund

Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet.

Informationen zum Ändern der Dropdownliste mit Gründen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp.

Bereich

Wählen Sie den zum Produkt oder Team gehörenden Bereichspfad aus, oder lassen Sie dieses Feld leer, bis ein entsprechender Pfad bei einer Planungsbesprechung zugewiesen wird.

Informationen zum Ändern der Dropdownliste mit Bereichen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden.

Iteration

Wählen Sie den Sprint oder die Iteration aus, in dem bzw. der die Arbeit abgeschlossen werden soll, oder lassen Sie dieses Feld leer, und legen Sie es später bei einer Planungsbesprechung fest.

Informationen zum Ändern der Dropdownliste mit Iterationen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden.

Backlog Priorität

Wird zum Nachverfolgen der relativen Bewertung von PBIs und Fehlern verwendet. Die Reihenfolge der Elemente auf der Product Backlog-Seite richtet sich danach, wo die Elemente auf der Seite hinzugefügt bzw. wohin sie verschoben wurden. Beim Ziehen von Elementen aktualisiert ein Hintergrundprozess dieses Feld, das in der ProcessConfiguration-Datei type="Order" zugewiesen ist.

Alle Links

Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw.

Auf dieser Registerkarte werden außerdem sämtliche für die Arbeitsaufgabe definierten Links aufgeführt, einschließlich der Links von anderen Registerkarten zur Linksteuerung.

Attachments

Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen.

Versionsgeschichte

Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf.

Bei jeder Aktualisierung der Arbeitsaufgabe werden dem Verlauf Informationen hinzugefügt. Der Verlauf enthält das Datum der Änderung, die Person, die die Änderung vorgenommen hat, sowie die geänderten Felder. Sie können dem Verlaufsfeld auch formatierten Text hinzufügen.

Informationen zu anderen Feldern finden Sie im Index von Arbeitsaufgabenfeldern.

Mit dem Nachverfolgen der Arbeit beginnen

Damit Sie mit dem Nachverfolgen der Arbeit beginnen können, benötigen Sie erst ein Teamprojekt. Hier können Sie eines erstellen.

Führen Sie zum Nachverfolgen der Arbeit einen der folgenden Schritte aus:

Fragen und Antworten

F: Welche Workflowzustände unterstützt Scrum?

A: Diese Diagramme zeigen die wichtigsten Fortschritts- und Regressionszustände von Funktion, Product Backlog Item, Fehler und Aufgabe. Den Workflow können Sie hier anpassen.

Funktion

Funktionsworkflowstatus, Scrum-Prozessvorlage

Produktrückstandselement

Backlog-Elementworkflow für Produkt, Scrum-Prozess

Fehler

Fehlerworkflowstatus, Scrum-Prozessvorlage

Aufgabe

Aufgabenworkflowstatus, Scrum-Prozessvorlage

F: Wie behebe ich einen Fehler als Duplikat?

A: Legen Sie den Status auf "Entfernt" fest, und geben Sie bei Grund "Duplikat" an.

F: Wie erstelle ich eine Verknüpfung zu einem vorhandenen Fehler im Test Runner?

A: Informationen finden Sie unter Aktualisieren eines vorhandenen Fehlers während der Verwendung von Test Runner.