Über die Konfiguration und Anpassung von Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Sie können Azure Boards auf vielfältige Weise konfigurieren und anpassen, um Ihr Portfolio, Ihre Abhängigkeiten und die Überwachung besser zu verwalten. Wir empfehlen die in diesem Artikel behandelten Aufgaben insbesondere für Administratoren, die für die Verwaltung von Multiteamprojekten verantwortlich sind.
Schnellzugriff auf allgemeine Aufgaben:
Karten anpassen | Spalten verwalten | Arbeit mit Verantwortlichkeitsbereich beschleunigen | Rückstand konfigurieren.
Hinweis
Die meisten Hinweise in diesem Artikel gelten sowohl für die Cloud- als auch für die lokale Version. Einige der in diesem Artikel beschriebenen Features, wie z. B. Rollup, Analytics und einige Tools für die Portfolioplanung, sind derzeit jedoch nur in der Cloud verfügbar.
Wenn Sie noch nicht lange als Projektadministrator*in tätig sind, lesen Sie auch Erste Schritte als Administrator*in.
Überlegungen
Um Azure Boards optimal nutzen zu können, müssen Sie verstehen, wie Ihre Teams die zugehörigen Tools und Funktionen (z. B. Scrum, Kanban und Scrumban) verwenden und inwieweit diese von Konfigurationen und Anpassungen abhängig sind. In der folgenden Tabelle finden Sie eine Zusammenfassung der wichtigsten Punkte, die Sie bei der Strukturierung Ihres Projekts berücksichtigen sollten.
Projektebene
- Wie viele Teams möchten Sie definieren?
- Wie sollen Bereichspfade zur Unterstützung von Ansichten für das Portfoliomanagement strukturiert werden?
- Anpassung von Feldern
- Benutzerdefinierte Arbeitselementtypen (WITs)
- Portfolio Backlog-Anpassungen
- Anpassung von Workflows
Teamebene
- Wie nutzen Sie das Product Backlog, um Ihre Arbeit zu planen und zu priorisieren?
- Möchten Sie Fehler als Anforderungen oder als Aufgaben nachverfolgen, oder sollen sie gar nicht verwendet werden?
- Werden zur Nachverfolgung von Zeit und Kapazität Aufgaben verwendet?
- Wie setzen Sie Portfolio Backlog-Ebenen ein?
- Wie informieren Sie die obere Führungsebene über Fortschritte, Status und Risiken?
Passen Sie die Bausteine und Tools zur Arbeitsnachverfolgung an Ihre geschäftlichen Anforderungen an, und kommunizieren Sie die Nutzungsrichtlinien an Ihr Team.
Arbeitselementtypen und Portfolio Backlogs
Wenn Sie ein Projekt in Azure Boards erstellen, wählen Sie zunächst einen Prozess aus. Jeder Prozess (Agile, Basic, Scrum und CMMI) unterstützt eine Hierarchie von WITs, einschließlich Produkt- und Portfolio Backlogs. Die standardmäßigen WITs für jeden Prozess sind auf den entsprechenden Registerkarten aufgeführt, wobei Rückstände unter Anforderungen und Aufgaben unter Aufgaben zu finden sind.
Das folgende Bild zeigt die Hierarchie für das Arbeitselement Agile-Prozess-Backlog:
- User-Stories und Aufgaben dienen der Verfolgung der Arbeit.
- Bugs verfolgen Code-Fehler.
- Epics und Funktionen werden verwendet, um die Arbeit in größeren Szenarien zu gruppieren.
Jedes Team kann konfigurieren, wie Fehlerarbeitselemente auf der gleichen Ebene wie User Story- oder Aufgabenarbeitselemente verwaltet werden. Verwenden Sie die Einstellung Arbeiten mit Fehlern. Weitere Informationen zur Verwendung dieser Arbeitselementtypen finden Sie unter Agile-Prozess.
Sie können benutzerdefinierte WITs auf jeder Ebene einfügen und sogar benutzerdefinierte Portfolio Backlogs hinzufügen. Hier sehen Sie zum Beispiel ein Projekt, bei dem Ziele und wichtige Ergebnisse als benutzerdefinierte WITs und entsprechende Portfolio Backlogs in den Scrum-Prozess aufgenommen wurden.
Optionen zur Arbeitsnachverfolgung und empfohlene Verwendung
Teams können wählen, welche WITs sie zur Nachverfolgung ihrer Arbeit verwenden. In der folgenden Tabelle finden Sie eine Zusammenfassung der wichtigsten Optionen, der empfohlenen Verwendung und der unterstützten Aufgaben und Tools.
Optionen zur Arbeitsnachverfolgung
Unterstützte Aufgaben und Tools
Nur Aufgaben
Nicht empfohlen
Es gibt keine Möglichkeit, schnell neue Aufgaben in ein Backlog einzugeben oder ein Backlog mit Aufgaben zu priorisieren. Außerdem werden Kalenderansichten, teamübergreifende Ansichten oder die Portfolioplanung nicht unterstützt
Anforderungen für untergeordnete Aufgaben
Unterstützung von Scrum-Methoden
Empfohlen für Teams, die Scrum-Methoden anwenden und die Arbeitszeit nachverfolgen möchten.
- Schnelles Definieren und Priorisieren von Backlog Items: Product Backlog
- Prognose von Sprints anhand der Teamgeschwindigkeit: Vorhersage
- Planen von Sprints: Backlog-Planungstool
- Planen und Nachverfolgen der Kapazität: Tool zur Sprintkapazität
- Nachverfolgen der geschätzten und verbleibenden Arbeit: Taskboard
- Überwachen des Sprint-Burndowns anhand der verbleibenden Arbeit, z. B. in Stunden oder Tagen: Sprint-Burndown
- Ausführen täglicher Scrums, Aktualisieren und Überwachen des Aufgabenstatus: Sprint-Taskboard
- Einschätzen der Arbeit: Definieren von Story Points, Aufwand oder Größe
- Anzeigen von Statusanzeigen, Anzahl oder Summen von Rollups für Aufgaben: Rollup
- Nachverfolgen der Abhängigkeiten zwischen Teams und Projekten: Lieferpläne
Viele Teams beginnen mit der Verwendung von Scrum-Methoden, um ihre Arbeit mithilfe der im Sprints-Hub verfügbaren Tools nachzuverfolgen und zu planen. Die Sprints-Tools unterstützen die Einschätzung und Nachverfolgung der verbleibenden Arbeit und die Nutzung der Kapazitätsplanung. Wenn Sie diese Tools nicht verwenden möchten, ist das Hinzufügen von Aufgaben, die von untergeordneten Elementen abhängig sind, optional. Entwickler*innen können sie als Checkliste mit Elementen hinzufügen, die sie zur Vervollständigung einer User Story oder zum Erfüllen einer Backlog-Anforderung benötigen.
Nur Anforderungen, z. B. User Storys (Agile), Issues (Basic), Product Backlog Items (Scrum), Anforderungen (CMMI)
Unterstützung von Kanban- und Scrumban-Methoden
Empfohlen für Teams, die Kanban- oder Scrumban-Methoden anwenden, die Arbeit anhand von Story Points, Aufwand oder Größe einschätzen und die Arbeitszeit nicht nachverfolgen.
- Schnelles Definieren und Priorisieren von Backlog Items: Product Backlog
- Planen von Sprints: Backlog-Planungstool
- Einschätzen der Arbeit: Definieren von Story Points, Aufwand oder Größe
- Prognose von Sprints anhand der Teamgeschwindigkeit: Vorhersage
- Überwachen des Sprint-Burndowns basierend auf Anforderungsschätzungen: Sprint-Burndown
- Status von Updateanforderungen: Kanban-Board
- Nachverfolgen der Abhängigkeiten zwischen Teams und Projekten: Lieferpläne
Anforderungen, die unter WITs des Portfolios gruppiert sind, wie z. B. Epics und Features
Unterstützung von Kalenderansichten, teamübergreifenden Ansichten und Portfolioplanung
Empfohlen für Organisationen mit verschiedenen Teams, die mehreren Teams zugeordnete Rollups und Kalenderansichten anzeigen und sämtliche Tools für die Portfolioplanung nutzen möchten.
- Schnelles Definieren und Priorisieren von Portfolioelementen: Portfolio Backlogs
- Schnelles Definieren von untergeordneten User Storys von Portfolioelementen: Portfolio-Checklisten
- Zuordnen von Arbeitselementen zu Features und Epics: Zuordnungstool
- Anzeigen teamübergreifender Kalenderansichten zum Fortschritt: Lieferpläne
- Anzeigen einer Kalenderansicht aller Teamfeatures: Featurezeitachse
- Anzeigen einer Kalenderansicht zu bestimmten Epics: Epic-Roadmap
- Anzeigen von Statusanzeigen, Anzahl oder Summen von Rollups für untergeordnete Elemente: Rollup
- Nachverfolgen der Abhängigkeiten zwischen Teams und Projekten: Lieferpläne
Optionen zum Konfigurieren und Anpassen
Die folgende Tabelle zeigt die Bereiche, die Sie konfigurieren und anpassen können, sowie die Tools, die von diesen Anpassungen betroffen sind. Sie können jeden Bereich wie angegeben auf Organisations-, Projekt- oder Teamebene oder einer Zweier-Kombination dieser Ebenen anpassen. Eine Beschreibung der Standardtools, der Analytics-Tools und der Tools für die Portfolioplanung finden Sie unter Was ist Azure Boards?, Kontextberichte: Arbeitsverfolgung und Planen für Agile im großen Stil.
Konfigurieren oder Anpassen
Standardtools
Analyse
Tools für die Portfolioplanung
Bereichspfade, Projektkonfiguration und Teamabonnements (Projekt, Team)
- Boards > alle Tools
- Backlogs > alle Tools
- Sprints > alle Tools
- Kumuliertes Flussdiagramm
- Geschwindigkeit
- Burndown-Trend
- Lieferpläne
- Featurezeitachse
- Epic-Roadmap
- Portfoliopläne (Beta)
Iterationspfade, Projektkonfiguration und Teamabonnements (Projekt, Team)
- Backlogs > Sprintplanung
- Sprints > Sprint-Backlogs
- Sprints > Sprintkapazität
- Sprints > Taskboard
- Geschwindigkeit
- Burndown-Trend
- Lieferpläne
- Featurezeitachse
- Epic-Roadmap
- Portfoliopläne (Beta)
Anzeigen von Fehlern in Backlogs und Boards (Team)
Benutzerdefinierte WITs, Produkt-Backlog (Prozess)
Benutzerdefinierte WITs, Taskboard (Prozess)
- Boards > Produktboard
- Backlogs > Product Backlog
- Backlogs > Zuordnungstool
- Sprints > Sprint-Backlogs
- Sprints > Taskboard
- Geschwindigkeit
Benutzerdefinierte WITs, Portfolio Backlog (Prozess)
Weitere Portfolio Backlogs (Prozess)
- Boards > Portfolioboards
- Backlogs > Portfolio Backlogs
- Backlogs > Zuordnungstool
- Geschwindigkeit
Benutzerdefinierter Workflow (Prozess)
- Boards > Produktboard
- Boards > Portfolioboards
- Sprints > Taskboard
- Kumuliertes Flussdiagramm
Benutzerdefiniertes Feld (Prozess)
- Boards > Produktboard
- Boards > Portfolioboards
Bereichspfade, Produktteams und Portfoliomanagement
Mithilfe von Bereichspfaden werden Arbeitselemente nach Produkt-, Feature- oder Geschäftsbereichen gruppiert und Teams unterstützt, die für die Arbeit in diesen Bereichen verantwortlich sind. Sie können einen hierarchischen Satz von Bereichspfaden oder einen flachen Satz definieren. Üblicherweise definieren Sie einen hierarchischen Satz von Bereichspfaden, um eine Unternehmenshierarchie zu unterstützen, die den Fortschritt mehrerer Teams nachverfolgen soll.
Bereichspfade und hierarchische Gruppierung
Die beiden wichtigsten Methoden zum Gruppieren von Arbeitselementen sind der Bereichspfad und die Zuordnung zu einem Portfolio-WIT, wie weiter oben in diesem Artikel beschrieben. Die beiden Methoden schließen sich nicht gegenseitig aus. Ihre Unterschiede bestehen aus:
- Einem Team zugewiesene Bereichspfade bestimmen, welche Arbeitselemente in einer Teamansicht angezeigt werden: Product Backlog, Portfolio Backlog, Lieferpläne oder andere Tools für die Portfolioplanung
- Die Gruppierung von Arbeitselementen unter einem übergeordneten Feature oder Epic bestimmt, welche Rollupansichten unterstützt werden und wie die Arbeit in einem Tool für die Portfolioplanung dargestellt wird
Sie können den Arbeitselementen auch Tags zuweisen, um sie für Abfrage- und Filterzwecke zu gruppieren. Daher sollte Ihnen bei der Strukturierung Ihrer Teams und Projekte bewusst sein, wie Sie diese Gruppierungstools zur Unterstützung Ihrer geschäftlichen Anforderungen einsetzen. Ihre Auswahl wirkt sich auf die Verwendung der Tools für die Portfolioplanung aus.
Bereichspfadabhängige Tools
Zum Ausführen der folgenden Aufgaben müssen Sie Bereichspfade definieren:
- Abfrage und grafische Darstellung von Arbeitselementen basierend auf dem Bereichspfad
- Zuweisen von Arbeit zu mehr als einem Team
- Arbeiten mit Verwaltungs- und Featureteams
- Filtern von Backlogs, Abfragen, Boards oder Plänen mithilfe von Bereichspfaden
Tipp
Sie können Ihre Bereichspfadstruktur definieren und den Teams Bereichspfade zuweisen. Alternativ können Sie auch ein Team hinzufügen und dabei den Bereichspfad mit dem Teamnamen erstellen. Wenn die Teams völlig unabhängig voneinander sind, erstellen Sie einen flachen Satz von Bereichspfaden. Wenn Sie jedoch eine Hierarchie von Teams erstellen möchten, dann sollten Sie eine Strukturhierarchie mit Bereichspfaden erstellen. Weitere Informationen finden Sie unter Konfigurieren einer Hierarchie von Teams.
Um die folgenden Tools verwenden zu können, müssen Teams Bereichspfade abonnieren:
Bereichspfade und Teamzuweisungen
Jedes Projekt verfügt über ein Standardteam und einen Standardbereichspfad. In einigen Fällen gibt es nur ein Team, um Arbeit zu planen und nachzuverfolgen. Wenn Organisationen jedoch wachsen, können Sie weitere Teams hinzufügen, um den Backlog und Sprints zu verwalten.
Das folgende Beispiel zeigt Bereichspfade und ihre Zuordnung zu Teams, die Ansichten zum Portfoliomanagement für die Teams zur Kundenbetreuung und Serviceerbringung unterstützen.
Weitere Informationen finden Sie in den folgenden Artikeln:
- Portfoliomanagement
- Informationen zu Bereichspfaden
- Informationen zu Teams und Agile-Tools
- Agile-Kultur.
Empfehlungen:
- Berücksichtigen Sie, was die obere Führungsebene wissen muss und wie Sie diese bestmöglich unterstützen können
- Überlegen Sie, wie Sie Rollup sowohl für ein Team als auch für das Portfoliomanagement nutzen möchten
- Definieren Sie Epics und Szenarien für umfangreiche Initiativen, für deren Umsetzung zwei oder mehr Sprints benötigt werden
- Erstellen Sie hierarchische Bereichspfade zur Unterstützung von Unterkategorien von Features und Produktbereichen
- Definieren Sie Anforderungen für Arbeitsaufgaben, die in einem einzigen Sprint erledigt und einer einzelnen Person zugewiesen werden können
- Definieren Sie Aufgaben, wenn Sie eine detailliertere Nachverfolgung durchführen oder den Zeitaufwand für die geleistete Arbeit erfassen möchten
Tipp
- Sie können ein Arbeitselement nur einer einzelnen Person zuweisen. Berücksichtigen Sie beim Definieren von Arbeitsaufgaben, wie viele Arbeitsaufgaben Sie benötigen und wem sie zugewiesen werden sollen.
- Wählen Sie das Feld
Node Name
als Spaltenoption aus, um den Blattbereichsknoten in einer Backlog-Liste oder Boardkarte anzuzeigen. Weitere Informationen finden Sie unter Customize Cards (Anpassen von Karten). - Erstellen Sie keine Über-/Unterordnungsverknüpfungen zwischen Arbeitselementen desselben Typs, wie z. B. Story-Story, Fehler-Fehler, Aufgabe-Aufgabe.
Die meisten Azure Boards-Tools unterstützen eine gefilterte Ansicht der Arbeitselemente basierend auf dem Bereichspfad oder dem Iterationspfad. Darüber hinaus können Sie weitere Filter auf der Grundlage von Schlüsselwörtern, Zuweisungen, WIT und mehr anwenden.
Fehler als Anforderungen oder Aufgaben
Jedes Team kann wählen, wie es Fehler verwalten möchte. Einige Teams möchten Fehler zusammen mit Anforderungen im Backlog nachverfolgen. Andere Teams möchten Fehler als Aufgaben nachverfolgen, die zur Unterstützung einer Anforderung ausgeführt werden. Diese Fehler werden dann auf ihrem Taskboard angezeigt.
Wenn Sie den Scrum-Prozess verwenden, sieht das Standardsetup vor, dass Fehler zusammen mit Product Backlog Items (PBIs) nachverfolgt werden. Wenn Sie in einem Projekt arbeiten, das auf den Agile- oder CMMI-Prozessen basiert, werden Fehler nicht automatisch in Ihrem Backlog angezeigt.
Bestimmen Sie mit Ihrem Team, wie Sie Fehler verwalten möchten. Anschließend ändern Sie Ihre Teameinstellungen entsprechend.
Tipp
Wenn Sie ein Backlog oder Board aktualisieren und Fehler nicht dort angezeigt werden, wo Sie sie erwarten, lesen Sie Anzeige von geschachtelten Elementen in Backlogs und Boards. Nur Blattknoten geschachtelter Elemente werden auf Sprint-Taskboards angezeigt.
System-WITs in einem Backlog
Um Issues oder Impedimente gemeinsam mit Ihren Anforderungen oder in einem Portfolio Backlog zu verfolgen, fügen Sie sie Ihrem benutzerdefinierten geerbten Prozess hinzu. Weitere Informationen finden Sie unter Anpassen von Backlogs oder Boards (Vererbungsprozess).
Rollup, Hierarchie und Portfolioverwaltung
Mithilfe von Rollupspalten können Sie Statusleisten oder Gesamtsummen von numerischen Feldern oder Nachfolgerelementen innerhalb einer Hierarchie anzeigen. Nachgeordnete Elemente entsprechen allen untergeordneten Elementen innerhalb der Hierarchie. Sie können eine oder mehrere Rollup-Spalten zu einem Produkt- oder Portfolio-Backlog hinzufügen.
Hier wird der Fortschritt nach allen Arbeitsaufgaben angezeigt, wobei Statusbalken für Arbeitsaufgaben in aufsteigender Reihenfolge basierend auf dem Prozentsatz der geschlossenen untergeordneten Elemente angezeigt werden.
Lieferpläne unterstützt Rollupansichten von Epics, Features und anderen benutzerdefinierten Portfolio Backlogs.
Iterationspfade, Sprints, Releases und Versionsverwaltung
Iterationspfade unterstützen Scrum- und Scrumban-Prozesse, bei denen die Arbeit einem festgelegten Zeitraum zugewiesen wird. Iterationspfade ermöglichen Ihnen das Gruppieren von Arbeit in Sprints, Meilensteine oder andere ereignisspezifische oder zeitbezogene Zeiträume. Jede Iteration bzw. jeder Sprint entspricht einem regelmäßigen Zeitintervall, das als Sprintrhythmus bezeichnet wird. Ein typischer Sprintrhythmus beträgt zwei Wochen, drei Wochen oder einen Monat. Weitere Informationen finden Sie unter Bereichs-und Iterationspfade.
Iterationspfade können als flache Liste angegeben oder nach Releasemeilensteinen gruppiert werden, wie in der folgenden Abbildung gezeigt.
Während Iterationspfade keine Auswirkungen auf Boardtools haben, können Sie Iterationspfade als Filter auf Boards verwenden. Weitere Informationen finden Sie unter Filtern der Tafel.
Definieren Sie Iterationspfade, und weisen Sie sie Teams zu, wenn Sie die folgenden Tools verwenden möchten:
- Zuweisen von Arbeitselementen zu Sprints mithilfe des Planungsbereichs
- Abfrage und grafische Darstellung von Arbeitselementen basierend auf dem Iterationspfad
- Prognostizieren Ihres Product Backlogs
- Sprints > alle Tools
- Lieferpläne, Kalenderansicht der Teamlieferleistungen
- Velocity-Diagramm und Diagramm zum Sprint-Burndown
Tipp
Wenn ein Team einen Iterationspfad nicht abonniert oder ausgewählt hat, wird dieser Iterationspfad nicht in einer Teamansicht oder einem Tool angezeigt.
Zeiterfassung
Die meisten Organisationen, die Scrum-Prozesse anwenden, verwenden Zeitschätzungen für die Planung der Sprintkapazität. Die Tools von Azure Boards bieten umfassende Unterstützung für die Zeiterfassung zu diesem Zweck. Das wichtigste Feld ist das Feld für die Aufgabe Remaining Work
, das am Ende des Sprints in der Regel auf Null gesetzt wird.
Einige Organisationen benötigen die Zeiterfassung jedoch für andere Zwecke, z. B. für die Abrechnung oder die Verwaltung von Zeitzuordnungsdatensätzen. Von Interesse sind die Zeitwerte für die geschätzte Arbeit und die abgeschlossene Arbeit. Die Agile- und CMMI-Prozesse bieten diese Felder –Original Estimate
, Completed Work
, Remaining Work
für die Verwendung in der Nachverfolgungszeit. Sie können sie zu diesem Zweck nutzen. Azure Boards bietet jedoch nur begrenzte native Unterstützung für die Zeiterfassung. Deshalb sollten Sie erwägen, zur Unterstützung Ihrer weiteren Zeiterfassungsanforderungen stattdessen eine Marketplace-Erweiterung zu verwenden.
Hinweis
Die Felder Original Estimate
, Completed Work
, Remaining Work
wurden entwickelt, um die Integration in Microsoft Project zu unterstützen. Die Unterstützung der Integration in Microsoft Project ist für Azure DevOps Server 2019 und höhere Versionen (einschließlich des Clouddiensts) veraltet.
Prozessänderungen, die alle Teams betreffen
Jede, an einem Prozess in einem Projekt vorgenommene Änderung wirkt sich auf alle Teams in diesem Projekt aus. Viele Änderungen verursachen keine größeren Störungen für die Teams, die sie unterstützen, aber die Folgenden Änderungen tun das.
Benutzerdefinierte Felder
Wenn Sie einem WIT benutzerdefinierte Felder hinzufügen, wirkt es sich nicht direkt auf ein bestimmtes Tool aus. Stattdessen werden diese Felder innerhalb der entsprechenden Arbeitsaufgaben sichtbar. Wenn Sie beispielsweise ein benutzerdefiniertes numerisches Feld einführen, können Sie es für Rollupberechnungen für Backlogs verwenden. Außerdem können Sie dieses benutzerdefinierte Feld mit den folgenden Berichterstellungstools verwenden. Dieser Effekt ist zwar nicht toolspezifisch, er verbessert jedoch die Fähigkeit, Arbeitsaufgaben an die Bedürfnisse Ihres Projekts anzupassen.
- Kontextbezogener Velocity-Bericht und Dashboard-Widget
- Kontextbezogener Bericht zum Sprint-Burndown und Dashboard-Widget
- Dashboard-Widget für Burndown und Burnup
Hinweis
Alle standardmäßigen und benutzerdefinierten Felder werden von sämtlichen Projekten in einer Sammlung oder Organisation gemeinsam genutzt. Sie können maximal 1.024 Felder für einen Prozess definieren.
Benutzerdefinierte WITs
Die folgende Tabelle zeigt die Auswirkungen des Hinzufügens eines benutzerdefinierten WIT zu einer bestimmten Kategorie.
Aufgabe
Anforderung
Epic oder Feature
- Untergeordnete Arbeitselemente des neuen Arbeitselementtyps werden im Product Backlog angezeigt
- Arbeitselemente, die auf dem neuen WIT basieren, werden in den Sprint-Backlogs und Taskboards angezeigt
- Arbeitsaufgaben basierend auf dem neuen WIT werden im Produktrücklog und \board angezeigt
- Jedes Team muss das "\board" konfigurieren, um das neue WIT zu unterstützen.
- Arbeitsaufgaben basierend auf dem neuen WIT werden auf den entsprechenden Portfolio-Backlogs und -Boards angezeigt
- Jedes Team muss die \Boards für die Unterstützung des neuen WIT konfigurieren.
- Die neuen WITs werden möglicherweise nicht in einem oder mehreren Portfolioplanungstools angezeigt
Benutzerdefinierter Workflow
Jeder Prozess unterstützt einen Standardworkflow. Dieser Workflow definiert die Standardspalten, die auf den Boards und Sprint-Taskboards angezeigt werden.
Workflowstatus: User Story, Agile-Prozess
Gelegentlich möchten Teams eine Statusverfolgung ihrer Arbeit durchführen, die über diese Standardstatuswerte hinausgeht. Dies kann auf folgende Arten unterstützt werden:
- Hinzufügen von benutzerdefinierten Workflowzuständen zum WIT: Diese Option wirkt sich auf alle Teams aus und setzt voraus, dass sie ihre Boardkonfiguration aktualisieren.
- Hinzufügen von Spalten zu einer Tafel: Diese Option wirkt sich nur auf das Team aus, das die Spalten hinzufügt.
Sowohl Workflowzustände als auch Spalten werden im Kumulativen Flussdiagramm für ein Team angezeigt. Die einzelnen Benutzer*innen können auswählen, welche Spalten im Diagramm angezeigt werden. Weitere Informationen finden Sie unter Kumulatives Flussdiagramm.
Wer kann Änderungen vornehmen?
Da Einstellungen auf Prozess-, Projekt- und Teamebene weitreichende Auswirkungen haben können, können Änderungen nur von Benutzern mit den folgenden erforderlichen Berechtigungen vorgenommen werden.
Änderungen auf Prozessebene
Zum Erstellen, Bearbeiten oder Verwalten geerbter Prozesse und deren Anwendung auf Projekte müssen Sie Mitglied der Gruppe Projektsammlungsadministratoren sein. Alternativ müssen die entsprechenden Berechtigungen Prozess erstellen, Prozess löschen, Prozess bearbeiten oder Feld aus Organisation löschen für Sie auf Zulassen festgelegt sein. Siehe Festlegen von Berechtigungen für die Arbeitsnachverfolgung: Anpassen eines geerbten Prozesses.
Weitere Informationen finden Sie in den folgenden Artikeln:
Änderungen auf Projektebene
Zum Hinzufügen von Bereichspfaden oder Iterationspfaden müssen Sie ein Mitglied der Gruppe Projektadministratoren sein.
Um Bereichspfade oder Iterationspfade unter einem bestimmten Knoten hinzuzufügen, zu bearbeiten und zu verwalten, müssen Sie über eine oder mehrere der folgenden Berechtigungen verfügen, die auf Zulassen festgelegt sind:
- Untergeordnete Knoten erstellen
- Diesen Knoten löschen
- Diesen Knoten bearbeiten
- Berechtigungen in diesem Knoten anzeigen
Weitere Informationen finden Sie in den folgenden Artikeln:
- Definieren von Bereichspfaden und Zuweisen zu einem Team
- Definieren von Iterationspfaden (Sprints) und Zuweisen von Teamiterationen
Änderungen auf Teamebene
Für die Konfiguration von Teamtools müssen Sie Teamadministrator*in oder ein Mitglied der Gruppe Projektadministratoren sein.
Teamadministrator*innen führen die folgenden Vorgänge aus:
- Hinzufügen von Teammitgliedern
- Abonnieren von Bereichs- und Iterationspfaden
- Konfigurieren von Backlogs und anderen allgemeinen Teameinstellungen
- Konfigurieren von Boards
- Verwalten von Teambenachrichtigungen
Ausführliche Informationen zum Konfigurieren von Backlogs und Boards finden Sie unter Verwalten und Konfigurieren von Teamtools.