Microsoft AZ-400: Agile Planung und Arbeitsmanagement — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Agile Planung und Arbeitsverwaltung in Azure DevOps basieren auf einem klaren Datenmodell, disziplinierten Flow- und Iterationspraktiken sowie teamübergreifender Transparenz. Azure Boards bietet eine robuste Hierarchie von Arbeitselementtypen und flexible Konfigurationen pro Team, während GitHub Projects eine moderne, automatisierungsgesteuerte Planung ermöglicht, die eng mit Issues und Pull Requests integriert ist. Eine effektive Einführung hängt von rigorosen Definitionen (Definition of Done, Akzeptanzkriterien), konsistenter Schätzung (Story Points und relative Größenbestimmung) und umsetzbaren Einblicken (Abfragen, Delivery Plans und Metriken einschließlich DORA) ab. Die folgenden Abschnitte beschreiben, wie diese Praktiken im großen Maßstab entworfen, implementiert und betrieben werden.

Azure Boards-Datenmodell, Prozessvorlagen und Teamkonfiguration

Arbeitselementtypen und deren Hierarchie bilden das Rückgrat der Planung. Im standardmäßigen Agile-Prozess lautet die Portfolio-Hierarchie Epic > Feature > User Story, wobei Task und Bug Elemente auf Ausführungsebene sind. Child-Verknüpfungen erfassen die Dekomposition (User Story → Task), und Bugs können auf derselben Backlog-Ebene wie User Stories verwaltet oder je nach Teamrichtlinie unabhängig triagiert werden. Verknüpfungstypen sind unerlässlich:

Parent/Child: Erfasst die Dekompositionshierarchie und steuert das Rollup von Fortschritt und Aufwand.
Predecessor/Successor: Drückt Zeitplanungs- und Abhängigkeitsbeziehungen zwischen Arbeitselementen aus; diese werden in Delivery Plans als Abhängigkeitslinien angezeigt.
Related/Duplicate/Blocked by: Modelliert nicht-hierarchische Beziehungen und Hindernisse.
Artefakt-Verknüpfungen: Verbindet Arbeitselemente mit Code (Commits, Branches, PRs), Builds und Releases und ermöglicht eine End-to-End-Nachverfolgbarkeit.

Azure DevOps-Prozessvorlagen definieren Zustände, Felder und die Benennung von WITs:

Agile: Das Element auf Anforderungsebene ist die User Story; schnelllebige Teams wählen oft diesen Prozess.
Scrum: Das Element auf Anforderungsebene ist das Product Backlog Item (PBI); Sprints und Scrum-Artefakte sind erstklassig integriert, und Bugs können so konfiguriert werden, dass sie sich wie PBIs verhalten.
CMMI: Das Element auf Anforderungsebene ist ein Requirement und es enthält WITs für Change Request, Risk und Review – wählen Sie diesen Prozess, wenn Sie Risiken und formale Reviews nachverfolgen müssen.
Benutzerdefinierte (geerbte) Prozesse: In Azure DevOps Services können Sie einen Systemprozess über Vererbung (Inheritance) erweitern, um benutzerdefinierte WITs, Zustände, Regeln und Felder hinzuzufügen und gleichzeitig die Servicekompatibilität zu wahren. Verwenden Sie Kategorien, um ein benutzerdefiniertes WIT auf der richtigen Backlog-Ebene zu platzieren. Vermeiden Sie übermäßige Anpassungen, die das Reporting erschweren; standardisieren Sie Felder wie Story Points und Remaining Work.

Teams sind schlanke Partitionen, die konfiguriert werden über:

Area Paths: Legen den Zuständigkeitsbereich (Scope) und die Backlog-Filterung fest; Teams wählen einen oder mehrere Area Paths (und optional untergeordnete Bereiche), um „ihre“ Arbeit zu definieren.
Iteration Paths: Repräsentieren die Release-Kadenz und Sprints; ein Team wählt Standard- und aktuelle Iterationen für die Planung aus.
Team-Backlogs und -Boards: Jedes Team wählt aus, welche Portfolio-Ebenen (Epic, Feature) angezeigt werden sollen, sowie Kartenstile und Spaltenzuweisungen, ohne andere Teams zu beeinträchtigen.
Team-Dashboards: Schaffen gemeinsame Transparenz durch Widgets für Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), Lead/Cycle-Time-Diagramme und benutzerdefinierte Analytics-Ansichten.

Flow-basiertes Delivery mit Kanban und Governance

Kanban in Azure Boards modelliert den kontinuierlichen Fluss von der Zusage (Commitment) bis zur Fertigstellung. Konfigurieren Sie Spalten so, dass sie den Workflow-Zuständen entsprechen, und teilen Sie optional kritische Zustände in „Doing/Done“-Unterspalten auf, um die Durchsatzmessung zu verbessern und versteckte Warteschlangen zu reduzieren. Setzen Sie explizite WIP-Limits (Work In Progress) pro Spalte und pro Swimlane; setzen Sie diese operativ durch – das Überschreiten eines Limits löst ein Gespräch zur Verbesserung aus, anstatt zu einem stillschweigenden Anwachsen des Backlogs zu führen. Verwenden Sie dedizierte Swimlanes (z. B. Expedite), um Elemente mit hoher Priorität visuell zu trennen und engere WIP-Limits für diese Lane festzulegen.

Die Definition of Done (DoD) verankert Qualität und Vorhersagbarkeit; kodifizieren Sie sie als Board-Richtlinien, Pflichtfelder oder Checklisten bei bestimmten Übergängen sowie durch die Verknüpfung von Akzeptanztests. Fordern Sie beispielsweise eine „Tested By“-Verknüpfung zu einem bestandenen Test Case, bevor ein Element nach „Done“ verschoben wird, und erfassen Sie die Schritte zur Verifizierung des Deployments, wenn es nach „Released“ verschoben wird.

Nutzen Sie Analytics zur Überwachung des Flow-Zustands:

Das Cumulative Flow Diagram validiert das WIP-Gleichgewicht und erkennt Engpässe, wenn sich die Bänder verbreitern.
Die Lead Time misst die verstrichene Zeit von der Erstellung bis zur Fertigstellung; die Cycle Time konzentriert sich auf die Zeit vom Eintritt in den Zustand „Active“ bis zur Fertigstellung. Das Cycle-Time-Diagramm-Widget meldet die verstrichene Zeit, nachdem ein Arbeitselement in den Zustand „Active“ übergegangen ist, was mit der Engpassanalyse übereinstimmt.
Durchsatzdiagramme (Throughput Charts) verfolgen die pro Zeitperiode abgeschlossenen Elemente; überwachen Sie Stabilität und Trend.

Die Sprintplanung wandelt Prioritäten in eine zeitlich begrenzte Verpflichtung (Timebox) um. Das Sprint Backlog listet die PBIs oder User Stories auf, die in die Iteration übernommen und in Tasks mit „Remaining Work“ (verbleibender Arbeit) in Stunden zerlegt werden. Verwenden Sie die Sprint-Kapazität (Sprint Capacity), um die Verfügbarkeit von Personen zu modellieren:

Kapazität pro Person in Stunden/Tag nach Aktivität (Entwicklung (Development), Testen (Testing), UX).
Individuelle und Team-Fehltage, um Feiertage und Urlaub abzubilden.
Lastausgleich auf Aktivitätsebene durch Zuordnung von Tasks zu Aktivitäten und Überprüfung der Kapazität im Vergleich zur geplanten Arbeit.

Die Velocity fasst die gelieferten Story Points pro Sprint zusammen. Verwenden Sie das Velocity-Diagramm, um ein stabiles Band zu etablieren; vermeiden Sie „Punkte-Inflation“. Aktivieren Sie in Product Backlogs die Prognosefunktion (Forecasting), um zu projizieren, wie viele kommende Iterationen benötigt werden, um das Backlog bei der historischen Durchschnitts-Velocity des Teams (basierend auf mehreren letzten Sprints) und der Iterationslänge abzuarbeiten (Burndown). Halten Sie die Prognose ehrlich, indem Sie teilweise abgeschlossene Arbeit ausschließen und eine strikte DoD (Definition of Done) einhalten.

Das Backlog Refinement erzwingt Klarheit und relative Schätzungen (Sizing):

Akzeptanzkriterien: Erfassen Sie klare, testbare Anweisungen im Feld „Acceptance Criteria“ des Arbeitselements; bevorzugen Sie das Given-When-Then-Format, um Mehrdeutigkeiten zu reduzieren und das Testdesign zu beschleunigen.
Story Points: Schätzen Sie die relative Komplexität und Unsicherheit auf Anforderungsebene; rechnen Sie Punkte nicht in Stunden um – Tasks haben das Feld „Remaining Work“.
Relative Schätzung (Planning Poker): Verwenden Sie eine gemeinsame Baseline und eine Sequenz (Fibonacci oder modifizierte Fibonacci), um schnell zu einer Einigung zu gelangen. Teams können Marketplace-Erweiterungen nutzen, um Planning Poker direkt in Azure Boards durchzuführen und Schätzungen in die Felder „Story Points“/„Effort“ zu schreiben, um ein konsistentes Reporting zu gewährleisten.

Bugs sollten einer Triage unterzogen und entweder wie Anforderungen behandelt (mit Punkten geschätzt und im Backlog geplant) oder als Tasks innerhalb des Sprints bearbeitet werden; wählen Sie eine Richtlinie pro Team, um die Velocity konsistent zu halten.

Teamübergreifende Planung, Abfragen, Berichterstattung, GitHub Projects und DevOps-Metriken

Große Programme erfordern Transparenz über Teams und Repositories hinweg:

Delivery Plans: Erstellen Sie teamübergreifende Zeitpläne, die nach Bereichs-/Iterationspfaden gefiltert sind. Visualisieren Sie die Arbeit nach Iteration mit Abhängigkeitslinien (aus Predecessor/Successor-Verknüpfungen) und Markierungen für Meilensteine (Release-Termine, externe Verpflichtungen). Zeigen Sie den Rollup-Fortschritt für Features und Epics an und legen Sie benutzerdefinierte Felder (z. B. Risiko) für Governance-Reviews offen.
Abfragen und Berichterstattung: Erstellen Sie Abfragen vom Typ „Flache Liste“, um zu beantworten, „welche Elemente diesen Filtern entsprechen“, Abfragen vom Typ „Struktur von Arbeitselementen“, um mit Rollups in der Hierarchie zu navigieren, und Abfragen vom Typ „Direkte Verknüpfungen“, um einen einzelnen Verknüpfungssprung zu analysieren (z. B. Feature → Stories oder Bug → Commits). Speichern und teilen Sie Abfragen, fügen Sie Diagramme (Kreis-, Balken-, Trenddiagramme) hinzu und heften Sie sie an Dashboards an. Für Berichte auf Analyse-Niveau verwenden Sie den Azure DevOps Analytics-Dienst und OData mit Power BI, um Portfolio-Burndown-Diagramme, Heatmaps für Abhängigkeitsrisiken und DORA-Visualisierungen zu erstellen. Integrierte Berichte umfassen Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time und die Auslastung der Sprint Capacity.

GitHub Projects integriert die Planung mit Issues und PRs:

Project-Boards: Erstellen Sie Kanban- oder Tabellenansichten auf Organisations- oder Repository-Ebene, definieren Sie benutzerdefinierte Felder (Status, Iteration, Priority) und filtern Sie nach Team.
Automatisierungsregeln: Konfigurieren Sie integrierte Workflows, um den Status festzulegen, wenn ein Issue oder PR geöffnet, gemerged oder geschlossen wird; erledigte Elemente automatisch zu archivieren; Zuweisungen oder Labels basierend auf Feldänderungen vorzunehmen; und Elemente zwischen Ansichten zu verschieben. Kombinieren Sie dies mit GitHub Actions für erweiterte Automatisierungen.
Integration von Issues und PRs: Issues und PRs sind erstklassige Elemente in Projects. Verwenden Sie Schlüsselwörter in PR-Beschreibungen (Fixes #123), um Issues zu verknüpfen und automatisch zu schließen. Status und Reviewer sind auf dem Board sichtbar, was eine Rückverfolgbarkeit vom Code zum Plan (Code-to-Plan) ermöglicht.

DevOps-Metriken müssen Code, Deployment und Ergebnisse miteinander verbinden:

DORA-Metriken:
- Deployment-Frequenz: Anzahl der Produktions-Deployments pro Tag/Woche; Quelle sind Pipeline-Release-Ereignisse.
- Durchlaufzeit für Änderungen (Lead Time for Changes): Messen Sie vom Code-Commit (oder PR-Merge) bis zum Produktions-Deployment; stellen Sie sicher, dass Pipelines Deployment-Zeitstempel ausgeben und diese mit Commits korrelieren.
- Fehlerrate bei Änderungen (Change Failure Rate): Verhältnis von Produktions-Deployments, die zu einem kundenrelevanten Vorfall oder einem Rollback führen; integrieren Sie dies mit Tags aus dem Incident-Management und den Pipeline-Ergebnissen.
- Mittlere Wiederherstellungszeit (Mean Time to Restore, MTTR): Verstrichene Zeit vom Beginn des Vorfalls bis zur Wiederherstellung des Dienstes; leiten Sie dies aus Monitoring-Alarmen und den Abschlusszeiten von Vorfällen ab. Korrelieren Sie DORA mit Board-Analysen (Lead/Cycle Time), um festzustellen, ob die Planung oder die Auslieferung der Engpass ist. Verwenden Sie Dashboards, um beide Metrik-Sätze für dasselbe Publikum zur kontinuierlichen Verbesserung sichtbar zu machen.

Praktisches Problemszenario

Die Werbesparte von Microsoft (Advertising Division) koordiniert acht funktionsübergreifende Teams, die eine gemeinsame Plattform für das Kampagnenmanagement bereitstellen. Die Codebasis befindet sich in GitHub; die Organisation benötigt verlässliche Quartalszusagen, klare Sichtbarkeit von Abhängigkeiten sowie handlungsrelevante Flow- und DORA-Metriken, ohne die Tool-Landschaft unnötig zu erweitern.

Wählen Sie den Azure DevOps Agile-Prozess und konfigurieren Sie die Teams

Warum: Agile bietet die Hierarchie Epic > Feature > User Story, die eine gute Balance zwischen Einfachheit und Portfolio-Rollups schafft. Erstellen Sie acht Teams, jedes mit seinem eigenen Bereichspfad und aktuellen/zukünftigen Iterationspfaden. Dies ermöglicht Autonomie bei Boards und Dashboards, während die unternehmensweite Berichterstattung erhalten bleibt.

Definieren Sie die Kanban-Governance und die Board-Konfiguration

Warum: Ein kontinuierlicher Fluss (Continuous Flow) zwischen den Sprints reduziert die Wartezeit. Konfigurieren Sie Spalten, die auf Zustände abgebildet sind, mit „Doing/Done“-Unterteilungen für „In Progress“ und „Code Review“. Legen Sie WIP-Limits pro Spalte fest und fügen Sie eine „Expedite“-Swimlane mit einem niedrigeren WIP hinzu. Fügen Sie Board-Richtlinien hinzu, die die Definition of Done (Unit-Tests erfolgreich, PR genehmigt, Checkliste zur Deployment-Verifizierung abgeschlossen) festlegen, um den Übergang zu „Done“ zu steuern.

Implementieren Sie Backlog Refinement und Disziplin bei der Schätzung

Warum: Vorhersagbare Zusagen erfordern eine konsistente Aufwandsschätzung (Sizing) und Klarheit. Erfassen Sie Akzeptanzkriterien im Given-When-Then-Format in den User Stories. Standardisieren Sie Story Points mittels Planning Poker (Fibonacci 1–13) unter Verwendung einer Azure Boards-Erweiterung und halten Sie Aufgabenschätzungen in Stunden für die verbleibende Arbeit (Remaining Work) fest, um die Sprint Capacity zu unterstützen.

Planen Sie Sprints mit Kapazitäts- und geschwindigkeitsbasiertem Forecasting

Warum: Kapazitätsplanung reduziert übermäßige Verpflichtungen (Overcommitment). Geben Sie individuelle Kapazitäten nach Aktivität und freien Tagen ein. Verwenden Sie das Velocity-Diagramm der letzten sechs Sprints, um ein realistisches Sprint-Ziel festzulegen. Aktivieren Sie das Backlog-Forecasting, um zu prognostizieren, wie viele Sprints benötigt werden, um die quartalsweisen Epic-Ziele zu erreichen, und stimmen Sie so die Erwartungen der Stakeholder ab.

Erstellen Sie Delivery Plans für teamübergreifende Transparenz

Warum: Abhängigkeiten und Meilensteine müssen auf einer einzigen Zeitachse sichtbar sein. Erstellen Sie einen Delivery Plan, der alle acht Teams und die Portfolio-Ebenen umfasst. Fügen Sie Meilenstein-Markierungen für quartalsweise Release-Termine und Marktereignisse hinzu. Verwenden Sie Predecessor/Successor-Verknüpfungen, um Abhängigkeitslinien anzuzeigen und Risiken aufzuzeigen, bei denen sich Elemente über Iterationen erstrecken.

Integrieren Sie GitHub Projects für Repository-zentrierte Ausführungsansichten

Warum: Entwickler arbeiten primär in GitHub; Projects hält den Ausführungskontext nahe am Code. Erstellen Sie ein GitHub Project auf Organisationsebene mit Board- und Tabellenansichten. Fügen Sie Automatisierungsregeln hinzu, um den Status bei Öffnen eines PR auf „In Progress“ und bei Mergen eines PR auf „Done“ zu setzen und geschlossene Issues automatisch zu archivieren. Verwenden Sie „Fixes #<id>“ in PRs, um verknüpfte Issues zu schließen und den Status auf dem Board widerzuspiegeln.

Verknüpfen Sie Code und Arbeitselemente zur Rückverfolgbarkeit

Warum: Eine durchgängige Rückverfolgbarkeit (End-to-End Traceability) ermöglicht genaue Berichte und Audits. Erzwingen Sie die Referenzierung der Azure Boards-Arbeitselement-ID in Commit-Nachrichten und PR-Beschreibungen; verwenden Sie Artefakt-Verknüpfungen bei Arbeitselementen, damit Delivery Plans und Analysen den Fortschritt aus Code-Aktivitäten zusammenfassen (Rollup) können.

Implementieren Sie Flow- und DORA-Metriken auf Dashboards

Warum: Geteilte, automatisierte Metriken treiben die Verbesserung voran. Heften Sie auf Team-Dashboards CFD-, Lead Time- und Cycle Time-Diagramme an, um den Flow zu steuern. Machen Sie auf einem Programm-Dashboard Velocity, die Zusammenfassung des Delivery Plan und DORA-Metriken sichtbar: Berechnen Sie die Deployment-Frequenz und die Durchlaufzeit (Lead Time) mithilfe von Pipeline-Deployment-Ereignissen aus den Produktions-Stages; leiten Sie die Fehlerrate bei Änderungen (Change Failure Rate) und die MTTR ab, indem Sie Incidents taggen und mit Deployments korrelieren. Diese einheitliche Ansicht hebt hervor, ob Engpässe in der Planung (Board Lead/Cycle Time) oder in der Auslieferung (DORA) liegen.

Dieser Ansatz schafft eine Balance zwischen Teamautonomie (teamspezifische Boards, Kapazitäten und Dashboards) und Programm-Governance (Delivery Plans, Abhängigkeiten und Meilensteine). Azure Boards bietet hierarchische Planung und Analysen, GitHub Projects optimiert das tägliche Tracking für Entwickler durch Automatisierung in Verbindung mit Issues und PRs, und DORA-Metriken schlagen die Brücke von der Planung zu den operativen Ergebnissen für glaubwürdige, datengestützte Zusagen.

← Paketverwaltung und Artefaktverwaltung · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →