Verwalten von Arbeitsaufgaben und Workflow im Scrum-Prozess
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Zum Planen von Softwareprojekten und Nachverfolgen von Softwarefehlern mit Scrum setzen Teams das Product Backlog Item (PBI)- und den Bug-Arbeitselementtyp (Work Item Type, WIT) ein. Um Erkenntnisse zu einem Portfolio von Features, Szenarien oder Benutzeroberflächen zu gewinnen, können Produktbesitzer*innen und Programmmanager*innen PBIs und Fehler Features zuordnen. Wenn Teams in Sprints arbeiten, definieren sie Aufgaben, die automatisch mit PBIs und Fehlern verknüpft werden.
Hinweis
Wenn Sie noch nicht mit dem Scrum-Prozess vertraut sind, finden Sie Informationen unter Sprints, Scrum und Projektverwaltung.
Tester können im Webportal oder in Microsoft Test Manager Testfälle erstellen und ausführen sowie Fehler erstellen, um Codefehler nachzuverfolgen. Impedimente verfolgen Blockierungsprobleme nach.
Definieren von PBIs und Fehlern
Wenn Sie ein Product Backlog Item definieren, konzentrieren Sie sich auf den Wert, den die Kunden erhalten, und vermeiden Sie Beschreibungen, wie das Team die Funktion entwickelt. Produktbesitzer*innen können das Product Backlog basierend auf dem Geschäftswert, dem Aufwand und der relativen Abhängigkeit von anderen Backlog Items der einzelnen Elemente 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 zum schnellen Hinzufügen auf der Product Backlog-Seite erstellen.
Danach können Sie jedes PBI bzw. jeden 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.
Indem sie den Aufwand für PBIs und Fehler definieren, können Teams anhand der Vorhersagefunktion und Geschwindigkeitsdiagramme zukünftige Sprints oder den Arbeitsaufwand einschätzen. Wenn Sie den Geschäftswerts definieren, können Produktbesitzer Prioritäten getrennt von der veränderbaren Backlog-Stapelrangfolge angeben.
Verwenden Sie die folgenden Felder und Felder, die in gemeinsamen Arbeitsaufgabentypen verwendet werden, wenn Sie das Arbeitsaufgabenformular vervollständigen. Weitere Informationen finden Sie unter Verwalten von Fehlern.
Feld/Registerkarte
Verwendung
Geben Sie den geschätzten Arbeitsaufwand zum Fertigstellen eines PBI in der vom Team bevorzugten Maßeinheit an, z. B. Story Points oder Zeit. Es muss ein numerischer Wert angegeben werden.
Agile-Geschwindigkeitsdiagramme und -Vorhersagetools verweisen auf die Werte in diesem Feld. Weitere Informationen finden Sie im Whitepaper Estimating (Schätzung).
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.
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.
Definieren Sie den Zustand „Fertig“, indem Sie die Kriterien beschreiben, 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 Kund*innen 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.
Erfassen von Kommentaren im Abschnitt „Diskussion“
Im Abschnitt Diskussion können Sie Kommentare zur durchgeführten Arbeit hinzufügen und überprüfen.
Die Symbolleiste des Rich-Text-Editors wird unter dem Texteingabebereich angezeigt, wenn Sie den Cursor in ein Textfeld setzen, das die Textformatierung unterstützt.
Hinweis
Es gibt kein Arbeitselementfeld „Diskussion”. Filtern Sie zum Abfragen von Arbeitselementen mit Kommentaren aus dem Bereich „Diskussion“ nach dem Feld Verlauf. Der gesamte Inhalt des Texts, der in das Textfeld „Diskussion“ eingegeben wurde, wird dem Feld „Verlauf“ hinzugefügt.
Erwähnen einer Person, einer Gruppe, eines Arbeitselements oder eines Pull Requests
Wählen Sie eines der folgenden Symbole aus, um ein Menü der letzten Einträge zu öffnen, in denen Sie jemanden erwähnt, ein Arbeitselement oder einen Pull Request verknüpft haben. Alternativ können Sie dasselbe Menü öffnen, indem Sie @, # oder ! eingeben.
Geben Sie einen Namen oder eine Nummer ein, um die Menüliste nach Ihrem Eintrag zu filtern. Wählen Sie den Eintrag aus, den Sie hinzufügen möchten. Um eine Gruppe in die Diskussion zu bringen, geben Sie @ gefolgt vom Gruppennamen ein (z. B. ein Team oder eine Sicherheitsgruppe).
Bearbeiten oder Löschen eines Kommentars
Um Ihre Diskussionskommentare zu bearbeiten oder zu löschen, wählen Sie 
Bearbeiten oder das Aktionssymbol (
) und dann Löschen aus.
Hinweis
Zum Bearbeiten und Löschen von Kommentaren ist Azure DevOps Server 2019 Update 1 oder höher erforderlich.
Nachdem Sie den Kommentar aktualisiert haben, wählen Sie Aktualisieren aus. Um den Kommentar zu löschen, bestätigen Sie, dass Sie ihn löschen möchten. Auf der Registerkarte Verlauf im Arbeitselementformular wird ein vollständiger Überwachungspfad aller bearbeiteten und gelöschten Kommentare beibehalten.
Wichtig
Bei einer lokalen Azure DevOps Server-Bereitstellung konfigurieren Sie einen SMTP-Server, damit Teammitglieder Benachrichtigungen empfangen.
Hinzufügen einer Reaktion auf einen Kommentar
Fügen Sie einem Kommentar Reaktionen hinzu, indem Sie in der oberen rechten Ecke des Kommentars ein Smileysymbol auswählen. Alternativ können Sie die Symbole am unteren Rand eines Kommentars auswählen, die neben vorhandenen Reaktionen angezeigt werden. Um Ihre Reaktion zu entfernen, wählen Sie die Reaktion unten im Kommentar aus. Die folgende Abbildung zeigt ein Beispiel für das Hinzufügen einer Reaktion und die Anzeige von Reaktionen zu einem Kommentar.
Speichern eines Kommentars ohne Speichern des Arbeitselements
Hinweis
Diese Funktion ist ab Azure DevOps Server 2022.1 verfügbar.
Wenn Sie nur die Berechtigung haben, Kommentare zur Diskussion für ein Arbeitselement hinzuzufügen, können Sie dies tun, indem Sie Kommentare speichern. Diese Berechtigung wird über Bereichspfadknoten und die Berechtigung zum Bearbeiten von Arbeitselementkommentaren in diesem Knoten gesteuert. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung – Erstellen untergeordneter Knoten, Ändern von Arbeitselementen unter einem Bereichs- oder Iterationspfad.
Nachdem Sie die Kommentare gespeichert haben, müssen Sie das Arbeitselement nicht mehr speichern.
Hinweis
Wenn Sie Änderungen am Steuerelement Diskussion speichern, wird nur der Kommentar gespeichert. Es werden keine Arbeitselementregeln ausgeführt, die für den Arbeitselementtyp definiert sind.
Nachverfolgen des Status
Im Verlauf der Arbeit ändern Sie das Feld „Zustand“, um den Status zu aktualisieren. Optional können Sie einen Grund angeben. Die Felder „Zustand“ und „Grund“ werden im Kopf des Arbeitselementformulars angezeigt.
Scrum-Workflowstatus
Durch das Aktualisieren des Zustands erhalten 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. Die folgenden Diagramme zeigen die wichtigsten Fortschritts- und Regressionszustände der Arbeitselementtypen „Product Backlog Item“, „Fehler“ und „Aufgabe“.
| Product Backlog Item | Bug | Aufgabe |
|---|---|---|
|
|
|
PBIs und Fehler durchlaufen in der Regel die folgenden Workflowstatus:
- Produktbesitzer*innen erstellen ein PBI, oder Tester*innen erstellen einen Fehler mit dem Zustand Neu und dem Standardgrund Neues Backlog Item.
- Produktbesitzer*innen verschieben das Element in den Zustand Bestätigt, sobald eine ausreichende Beschreibung vorliegt und das Team den entsprechenden Aufwand schätzen kann. In der Regel befinden sich Elemente, die im oberen Product Backlog-Bereich angezeigt werden, im Zustand „Genehmigt“, während Elemente in der Mitte oder im unteren Bereich den Zustand „Neu“ aufweisen.
- Das Team aktualisiert den Status in Committet, wenn es die Entscheidung trifft, in diesem Sprint an dem Element zu arbeiten.
- Ein Element wird in den Zustand Fertig verschoben, wenn das Team alle zugehörigen Aufgaben abgeschlossen hat und der Produktbesitzer zustimmt, dass es gemäß den Akzeptanzkriterien implementiert wurde.
Aktualisieren des Status mit dem Board oder mit Taskboards
Teams können auf dem Board den Status von Product Backlog Items (PBIs) und auf dem Sprint-Taskboard den Status von Aufgaben aktualisieren. Wenn Elemente in eine neue Zustandsspalte gezogen werden, werden sowohl das Feld „Zustand“ als auch das Feld „Grund“ aktualisiert.
Sie können das Board anpassen, um weitere Swimlanes oder Spalten zu unterstützen. Weitere Optionen zur Anpassung finden Sie unter Anpassen Ihrer Arbeitsnachverfolgung.
Zuordnen von PBIs zu Funktionen
Wenn Sie eine Sammlung von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Definieren Sie dazu Features und ordnen Sie PBIs zu Features zu.
Mithilfe von Portfolio Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem können Sie Portfolio Backlogs verwenden, um einen teamübergreifenden Rollup der in Bearbeitung befindlichen Aufgaben anzuzeigen, wenn Sie eine Hierarchie von Teams einrichten.
Definieren von Aufgaben
Wenn das Team die Arbeiten in Sprints verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in verschiedene Aufgaben zu untergliedern.
Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit ab.
Teams planen 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.
Beim Schätzen des Aufwands in Stunden oder Tagen definieren Teams Aufgaben sowie die optionalen Felder Verbleibende Arbeit und Aktivität.
Feld/Registerkarte
Verwendung
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-Burndowndiagramms und des Sprint-Burndownberichts (Scrum) 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.
Wählen Sie den Aktivitätstyp aus, den diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt.
Nachverfolgen des Teststatus
Testen von PBIs
Über das Webportal oder Test Manager können Sie Testfälle erstellen, die automatisch mit einem PBI oder Fehler verknüpft werden. Alternativ können Sie ein PBI oder einen Fehler über die Registerkarte „Links“ (
) mit einem Testfall verknüpfen.
Der Testfall enthält zahlreiche Felder, von denen viele automatisiert und in Test Manager und den Buildprozess integriert sind. Eine Beschreibung der einzelnen Felder finden Sie unter Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern.
Auf der Registerkarte „Links“ () werden die Links zu allen PBIs und Fehlern in einem Testfall erfasst. 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
Sie können Fehler über das Webportal, Visual Studio oder beim Testen mit Test Manager erstellen.
Definitionen für allgemeine Felder zur Arbeitsnachverfolgung
In den meisten Arbeitselementen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. 
Verlauf, Links oder 
Anhänge. Diese drei Registerkarten enthalten einen Änderungsverlauf, eine Ansicht der verknüpften Arbeitselemente sowie Funktionen zum Anzeigen und Anfügen von Dateien.
Das einzige Pflichtfeld für alle Arbeitselementtypen ist Titel. Wenn Sie eine Arbeitsaufgabe speichern, weist das System ihr eine eindeutige ID zu. Das Pflichtfeld ist im Formular gelb hervorgehoben. Informationen zu allen anderen Feldern finden Sie im Index der Arbeitselementfelder.
Hinweis
Je nach Anpassungen, die Sie an Ihrem Prozess und Projekt vornehmen, gibt es möglicherweise weitere Pflichtfelder.
Feld/Registerkarte
Verwendung
Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern.
Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu.
Wenn das Arbeitselement erstellt wird, wird für den Zustand standardmäßig der erste Zustand im Workflow festgelegt. Aktualisieren Sie den Wert im Verlauf der Arbeit mit dem aktuellen Zustand.
Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet.
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 den Bereichen finden Sie unter Definieren von Bereichspfaden und Zuweisen zu einem Team.
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 den Iterationen finden Sie unter Definieren von Iterationspfaden (Sprints) und Konfigurieren von Teamiterationen.
Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf.
Bei jeder Aktualisierung des Arbeitselements 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.
Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw.
Auf dieser Registerkarte werden auch alle Links aufgeführt, die für das Arbeitselement definiert sind.
Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen.
Anpassen von Arbeitsaufgabentypen
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie unter Anpassen eines Vererbungsprozesses.
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie je nach Prozessmodell Ihres Projekts unter Anpassen eines Vererbungsprozesses oder Anpassen des lokalen XML-Prozessmodells.
Nachverfolgen von Impedimenten
Verwenden Sie den Arbeitselementtyp „Impediment“, um Ereignisse nachzuverfolgen, die den Fortschritt oder die Fertigstellung eines PBI möglicherweise blockieren. Verwenden Sie den Arbeitselementtyp „Fehler“ nur zum Nachverfolgen von Codefehlern.
Sie können ein Impediment über das Widget „Neues Arbeitselement“, das einem Teamdashboard hinzugefügt wurde, oder über das Menü Neu auf der Seite Abfragen hinzufügen.
Arbeitselemente, die Sie über das Widget hinzufügen, werden automatisch auf den Standardbereich und die Iterationspfade Ihres Teams beschränkt. Informationen zum Ändern des Teamkontexts finden Sie im Artikel zum Wechseln des Teamkontexts.
Reihenfolge der Backlogliste
Das Feld Backlog Priority wird verwendet, um die relative Rangfolge von PBIs, Fehlern, Features oder Epics nachzuverfolgen. Standardmäßig wird es jedoch nicht im Arbeitselementformular angezeigt. Die Reihenfolge der Elemente auf der Backlogseite richtet sich danach, wo die Elemente auf der Seite hinzugefügt bzw. wohin sie verschoben wurden. Wenn Sie Elemente durch Ziehen verschieben, aktualisiert ein Hintergrundprozess dieses Feld.