[{"data":1,"prerenderedAt":779},["ShallowReactive",2],{"/de-de/blog/gitlab-for-agile-software-development":3,"navigation-de-de":41,"banner-de-de":445,"footer-de-de":455,"blog-post-authors-de-de-Victor Wu|Amanda Rueda":660,"blog-related-posts-de-de-gitlab-for-agile-software-development":686,"assessment-promotions-de-de":729,"next-steps-de-de":769},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":30,"isFeatured":13,"meta":31,"navigation":32,"path":33,"publishedDate":22,"seo":34,"stem":38,"tagSlugs":39,"__hash__":40},"blogPosts/de-de/blog/gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development",[7,8],"victor-wu","amanda-rueda",null,"agile-planning",{"slug":12,"featured":13,"template":14},"gitlab-for-agile-software-development",false,"BlogPost",{"title":16,"description":17,"authors":18,"heroImage":21,"date":22,"body":23,"category":10,"tags":24,"updatedDate":29},"So setzt du GitLab für die Agile-Softwareentwicklung ein","Wie Agile-Artefakte auf GitLab-Funktionen abgebildet werden und wie eine Agile-Iteration in GitLab aussieht.",[19,20],"Victor Wu","Amanda Rueda","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","2018-03-05","Hast du dich jemals gefragt, ob GitLab die [Agile-Methode](https://about.gitlab.com/de-de/solutions/agile-delivery/) unterstützt? Wenn du die Verwendung von GitLab in Betracht ziehst, ist es möglicherweise nicht offensichtlich, wie die Funktionen der DevSecOps-Plattform mit Agile-Artefakten übereinstimmen. Daher haben wir sie für dich aufgeschlüsselt.\n\nAgile ist eine der wichtigsten und transformativsten Methoden, die in den letzten Jahrzehnten im Bereich des Software-Engineerings eingeführt wurde. Obwohl sich nicht alle auf die detaillierte Terminologie der Agile-Konzepte einigen können, hat sie sich dennoch deutlich positiv auf die Softwareentwicklungsteams ausgewirkt. Du kannst dank [Agile-Softwareentwicklung](https://about.gitlab.com/de-de/solutions/agile-delivery/) und der Bereitstellungsprozesse effizient kundenorientierte Produkte erstellen.\n\nGitLab ist so konzipiert, dass es flexibel genug ist, um sich an deine Softwareentwicklungsmethodik anzupassen, unabhängig davon, ob es sich um Agile handelt oder davon inspiriert ist. In diesem Beitrag zeigen wir eine einfache Zuordnung von Agile-Artefakten zu GitLab-Funktionen und erklären, wie Kund(inn)en erfolgreich leistungsstarke [Agile-Softwarebereitstellungsteams](https://about.gitlab.com/de-de/solutions/agile-delivery/) mit GitLab unterstützen.\n\n## Inhaltsverzeichnis\n\n- [Zuordnen von Agile-Artefakten zu GitLab-Funktionen](#zuordnen-von-agile-artefakten-zu-gitlab-funktionen)\n  - [Agile-Artefakt → GitLab-Funktion](#agile-artefakt--gitlab-funktion)\n- [Eine Agile-Iteration mit GitLab](#eine-agile-iteration-mit-gitlab)\n  - [User Storys → GitLab-Probleme](#user-storys--gitlab-probleme)\n  - [Aufgabe → Aufgaben](#aufgabe--aufgaben)\n  - [Epics → GitLab-Epics](#epics--gitlab-epics)\n  - [Produkt-Backlog → GitLab-Issue-Übersichten](#produkt-backlog--gitlab-issue-übersichten)\n  - [Sprints → GitLab-Iterationen](#sprints--gitlab-iterationen)\n  - [Punkte und Schätzungen → GitLab-Ticketgewichtung](#punkte-und-schätzungen--gitlab-ticketgewichtung)\n  - [Agile Board → GitLab-Issue-Übersichten](#agile-board--gitlab-issue-übersichten)\n  - [Team-Workload → GitLab-Issue-Übersicht](#team-workload--gitlab-issue-übersicht)\n  - [Abarbeitungen → GitLab-Abarbeitungen](#abarbeitungen--gitlab-abarbeitungen)\n- [Starte deine Agile-Reise mit GitLab](#starte-deine-agile-reise-mit-gitlab)\n\n## Zuordnen von Agile-Artefakten zu GitLab-Funktionen\n\n### Agile-Artefakt → GitLab-Funktion\n- User Story –> [Probleme](https://docs.gitlab.com/ee/user/project/issues/) - Aufgabe –> [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) - Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/) - Punkte und Schätzung –> [Problemgewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) - Produkt-Backlog –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/Iteration –> [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) - Agile Board –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) - Team-Workload –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) - Abarbeitungsdiagramm –> [Abarbeitungsdiagramme](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## Eine Agile-Iteration mit GitLab\n\n### User Storys → GitLab-Probleme\n\nIn der Agile-Softwareentwicklungsmethodik beginnt man oft mit einer User Story, die ein einzelnes Feature erfasst, um den Benutzer(inne)n einen Geschäftswert zu bieten. In GitLab dient ein [Ticket](https://docs.gitlab.com/ee/user/project/issues/) diesem Zweck mit Leichtigkeit. GitLab-Tickets sind für Agile-Teams unerlässlich und bieten eine effektive Methode zum Verwalten von Aufgaben und Projekten. Softwareentwickler(innen) können Tickets erstellen, zuweisen und nachverfolgen, um eine klare Verantwortlichkeit und Sichtbarkeit des Fortschritts zu gewährleisten. Tickets kommen mit robusten Metadaten wie Beauftragte(r), Iteration, Gewichtung und Labels, was die Aufgabenpriorisierung und das Workflow-Management während des gesamten Softwareentwicklungsprozesses verbessert. Darüber hinaus wird die Teamzusammenarbeit bei Tickets mit Diskussionsthreads, Anhängen und Echtzeit-Updates optimiert, um eine effektive Kommunikation und Teamarbeit zu ermöglichen.\n\n![Screenshot eines GitLab-Tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nDas GitLab-Ticket hat einen Titel und einen Beschreibungsbereich in der Mitte, in dem du alle Details wie den Geschäftswert und die relevanten Personas in einer User Story dokumentieren kannst. Die Seitenleiste rechts bietet die Integration mit anderen Agile-kompatiblen Funktionen wie dem übergeordneten Epic, zu dem das Ticket gehört, der Iteration, in der das Ticket bearbeitet werden soll, und der Gewichtung des Tickets, die den geschätzten Aufwand widerspiegelt.\n\n### Aufgabe → Aufgaben\n\nOft wird eine User Story weiter in einzelne Aufgaben unterteilt. GitLab-[Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) rationalisieren das Projektmanagement, da Agile-Teams die Möglichkeit haben, User Storys in einzelne Arbeitsschritte aufzuteilen. Diese Funktion unterstützt das Agile-Framework, indem Softwareentwickler(innen) Aufgaben innerhalb ihrer Projekte erstellen, zuweisen und nachverfolgen können. Durch die direkte Integration des Aufgabenmanagements in GitLab können Teams einen zusammenhängenden Workflow aufrechterhalten, der sicherstellt, dass alle Projektaktivitäten der Softwareentwicklung einfach nachverfolgt und verwaltet werden können.\n\n[!Screenshot mit genauer Aufgabenverwaltung und Projektverfolgung mit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175696/Blog/rd4jnbnddseykj7f9x4q.png)\n\nVerbessere den Nutzen für Benutzer(innen) mit einer präzisen Aufgabenverwaltung und Projektverfolgung mit GitLab. Die Aufgaben sind mit den gleichen Metadaten wie Tickets ausgestattet, einschließlich Beauftragte(r), Iteration, Gewichtung, Label, Zeiterfassung und Funktionen für die Zusammenarbeit. Dieser umfassende Funktionsumfang ermöglicht es Agile-Teams und Projektmanager(innen), Workloads effektiv zu verwalten, Aufgaben zu priorisieren und eine nahtlose Zusammenarbeit zwischen Softwareentwickler(inne)n zu gewährleisten.\n\n### Epics → GitLab-Epics\nAndererseits können Agile-Entwicklungsfachkräfte eine Abstraktion über den User Storys angeben, die oft als Epic bezeichnet wird und auf einen größeren Benutzerfluss hinweist, der aus mehreren Funktionen besteht. In GitLab enthält ein [Epic](https://docs.gitlab.com/ee/user/group/epics/) auch einen Titel und eine Beschreibung, ähnlich wie ein Ticket, aber du kannst mehrere untergeordnete Tickets daran anhängen, um diese Hierarchie anzuzeigen.\n\n![Screenshot von verschachtelten GitLab-Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nMit GitLab-Epics können Agile-Teams große Projekte effizient organisieren und verwalten, indem sie Epics bis zu neun Ebenen tief verschachteln. Diese hierarchische Struktur bietet einen klaren Überblick über die Roadmap des Projekts und hilft Softwareentwickler(inne)n und Projektmanager(inne)n, komplexe Initiativen in überschaubare Komponenten zu unterteilen. Durch die Verwendung von untergeordneten und [verknüpften Epics](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html) können Teams den Fortschritt, die Abhängigkeiten und die Projektmeilensteine besser verfolgen, die Zusammenarbeit verbessern und eine kohärente Agile-Bereitstellung gewährleisten.\n\n### Produkt-Backlog → GitLab-Issue-Übersichten\n\nDie Produkt- oder Geschäftsinhaber(innen) erstellen diese User Storys in der Regel, um die Bedürfnisse des Unternehmens und der Kund(inn)en widerzuspiegeln. Sie werden in einem Produkt-Backlog nach Prioritäten sortiert, um die Dringlichkeit und die gewünschte Reihenfolge der Entwicklung festzuhalten. Die Eigentümer(innen) des Produkts kommunizieren mit den Stakeholdern, um die Prioritäten festzulegen, und verfeinern das Backlog ständig. In GitLab bietet eine [Issue-Übersicht](https://docs.gitlab.com/ee/user/project/issue_board.html), die mit Iterationen als Listen organisiert ist, ein Drag-and-Drop-Workflow-Erlebnis, mit dem du deinen Backlog mühelos priorisieren und Storys einem bevorstehenden Sprint zuweisen kannst.\n\n[Gif der GitLab Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175706/Blog/s6jqjqgqgwaaqc1ywkkn.gif)\n\n### Sprints → GitLab-Iterationen\n\nEin Sprint stellt einen begrenzten Zeitraum dar, in dem die Arbeit abgeschlossen werden soll. Das kann eine Woche, ein paar Wochen oder vielleicht einen Monat oder mehr umfassen. Die Eigentümer(innen) des Produkts und das Entwicklungsteam treffen sich, um zu entscheiden, welche Arbeiten für den kommenden Sprint vorgesehen sind. Die Funktion [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) von GitLab unterstützt dies: Weise Iterationen ein Startdatum und ein Fälligkeitsdatum zu, um den Zeitraum der Iteration zu erfassen. Das Team fügt dann Tickets in den Sprint ein, indem es sie dieser bestimmten Iteration zuweist.\n\nDurch die Verwendung von Iterationen nutzt du die erweiterten Funktionen von GitLab für agiles Projektmanagement und bietest eine bessere Transparenz und Kontrolle über deine Agile-Planung und -Bereitstellung.\n### Punkte und Schätzungen → GitLab-Ticketgewichtung\n\nAuch in diesem Meeting werden User Storys kommuniziert und der technische Aufwand für jede User Story geschätzt. In GitLab haben Tickets eine [Gewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) – Attribute, die du verwenden würdest, um den geschätzten Aufwand anzugeben.\n\nIn dieser Besprechung (oder in den folgenden) werden die User Storys weiter aufgeschlüsselt und manchmal werden technische Pläne und die Architektur dokumentiert. In GitLab können diese Informationen im Ticket oder in der [Beschreibung der Merge Request](https://docs.gitlab.com/ee/user/project/merge_requests/) dokumentiert werden, da die Merge Request oft der Ort ist, an dem die technische Zusammenarbeit stattfindet.\n\nWährend des Sprints (GitLab-Iteration) holen die Mitglieder des Softwareentwicklungsteams User Storys ab, an denen sie nacheinander arbeiten können. In GitLab haben Tickets Beauftragte. Du würdest dich also einem Ticket [zuweisen](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html), um zu zeigen, dass du jetzt daran arbeitest. Wir empfehlen dir, [eine leere und mit dem Ticket verknüpfte Merge Request zu erstellen](https://docs.gitlab.com/ee/user/project/issues/), um sofort mit dem technischen Zusammenarbeitsprozess zu beginnen, noch bevor du eine einzige Codezeile erstellst.\n\n### Agile Board → GitLab-Issue-Übersichten\n\nWährend des gesamten Sprints durchlaufen die Tickets verschiedene Phasen, wie z. B. `Ready for dev`, `In dev`, `In QA`, `In review`, `Done`, abhängig vom Workflow in deiner jeweiligen Organisation. Normalerweise sind dies Spalten in einem Agile Board. In GitLab kannst du mit [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) deine Phasen definieren und Tickets durch sie bewegen. Das Team kann unter Beachtung der Iteration und anderer relevanter Attribute [die Übersicht konfigurieren](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration). Während der täglichen Stand-ups betrachtet das Team das Board gemeinsam, um den Status des Sprints aus einer Workflow-Perspektive zu sehen.\n\n![Screenshot der GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nDie GitLab-Issue-Übersicht greift auch dynamisch auf Probleme zu, ähnlich wie die GitLab-Issue-Liste. Aber sie ermöglicht flexiblere Workflows. Du kannst individuelle Listen in der Übersicht einrichten, um die Phasen des Agile Boards widerzuspiegeln. Dein Team kann dann die User Storys steuern und verfolgen, während sie von z. B. „Bereit für die Entwicklung“ zu „Zur Produktion freigegeben“ wechseln.\n\n### Team-Workload → GitLab-Issue-Übersicht\n\nAgile Teams können ihre Workflows optimieren, indem sie Issue-Übersichten mit Listen erstellen, die den Verantwortlichen in GitLab zugeordnet sind. Mit dieser Funktion kannst du die Verteilung der Aufgaben unter den Teammitgliedern visualisieren und die agile Bereitstellung verbessern. Um es einzurichten, gehe zu deinem Projekt oder deiner Gruppe, erstelle eine neue Übersicht im Abschnitt „Boards“ und [füge Listen](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) für jede(n) Beauftragte(n) hinzu. Weise Teammitgliedern Tickets zu, und sie werden automatisch in den entsprechenden Listen angezeigt. Diese dynamische Ansicht ermöglicht eine ausgewogene Arbeitsbelastung und eine effektive Aufgabenverwaltung.\n\n![Screenshot der organisierten GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\nOrganisiere eine Issue-Übersicht nach beauftragter Person oder nach Team mithilfe von [Labels mit begrenztem Geltungsbereich]. Die Issue-Übersicht von GitLab ist unglaublich vielfältig und unterstützt Workflows über den gesamten Software-Entwicklungsprozess hinweg.\n\n### Abarbeitungen → GitLab-Abarbeitungen\n\nDas Entwicklungsteam möchte in Echtzeit wissen, ob es auf dem richtigen Weg ist, und die entstehenden Risiken mindern. GitLab bietet [Abarbeitungen](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), damit das Team die im aktuellen Sprint „abzuarbeitenden“ Aufgaben visualisieren kann, während sie abgeschlossen wird.\n\nGegen Ende des Sprints stellt das Entwicklungsteam die fertiggestellten Funktionen den verschiedenen Interessengruppen vor. Mit GitLab wird dieser Prozess mithilfe von [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) vereinfacht, sodass auch Code, der noch nicht für die Produktion freigegeben ist, in verschiedenen Test-, Staging- oder UAT-Umgebungen vorgeführt werden kann. Review Apps und [CI/CD-Funktionen](https://docs.gitlab.com/ee/ci/) sind in die Merge Request selbst integriert.\n\nDie gleichen Tools sind auch für Entwickler(innen) und QA-Rollen nützlich, um die Softwarequalität zu sichern, sei es durch automatisierte Tests mit CI/CD oder durch manuelle Tests in einer Review-App-Umgebung.\n\n![Screenshot von GitLab-Abarbeitungen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nDie GitLab-Abarbeitung ermöglicht es einem Team, die „abzuarbeitenden“ Aufgaben zu verfolgen, während sie in einem Sprint abgeschlossen werden. Auf diese Weise kannst du früher auf Risiken reagieren und dich anpassen. So kannst du Geschäfts-Stakeholder darüber informieren, dass bestimmte Funktionen voraussichtlich auf einen zukünftigen Sprint verschoben werden.\n\nTeam-Retrospektiven am Ende des Sprints können im [Wiki] von GitLab (https://docs.gitlab.com/ee/user/project/wiki/index.html) dokumentiert werden, sodass die gewonnenen Erkenntnisse und die Aktionspunkte im Laufe der Zeit nachverfolgt werden können. Während der eigentlichen Retrospektive kann sich das Team den [Iterationsbericht](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report) ansehen, der die Abarbeitung und andere Statistiken des abgeschlossenen Sprints anzeigt.\n\n## Starte deine Agile-Reise mit GitLab\nBist du bereit, dein Agile-Projektmanagement zu verbessern? GitLab bietet eine umfassende Palette von Funktionen, die auf Agile-Teams, Softwareentwickler(innen) und Projektmanager(innen) zugeschnitten sind und eine nahtlose Zusammenarbeit und effiziente Workflows gewährleisten. Erkunde unsere Preisoptionen, starte eine kostenlose Testversion und erfahre, wie GitLab deine Agile-Bereitstellungsprozesse verändern kann.\n\n> [Erfahre mehr über die Agile Planung mit GitLab](https://about.gitlab.com/pricing/) und starte noch heute deine Reise!\n",[25,26,27,28],"agile","features","workflow","collaboration","2025-05-14","yml",{},true,"/de-de/blog/gitlab-for-agile-software-development",{"title":16,"description":17,"ogTitle":16,"ogDescription":17,"noIndex":13,"ogImage":21,"ogUrl":35,"ogSiteName":36,"ogType":37,"canonicalUrls":35},"https://about.gitlab.com/blog/gitlab-for-agile-software-development","https://about.gitlab.com","article","de-de/blog/gitlab-for-agile-software-development",[25,26,27,28],"0pPLiELItE71ZUAeQMI-1RTqWN2CmMzBwWb6NC-NqNU",{"data":42},{"logo":43,"freeTrial":48,"sales":53,"login":58,"items":63,"search":372,"minimal":407,"duo":425,"pricingDeployment":435},{"config":44},{"href":45,"dataGaName":46,"dataGaLocation":47},"/de-de/","gitlab logo","header",{"text":49,"config":50},"Kostenlose Testversion anfordern",{"href":51,"dataGaName":52,"dataGaLocation":47},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":54,"config":55},"Vertrieb kontaktieren",{"href":56,"dataGaName":57,"dataGaLocation":47},"/de-de/sales/","sales",{"text":59,"config":60},"Anmelden",{"href":61,"dataGaName":62,"dataGaLocation":47},"https://gitlab.com/users/sign_in/","sign in",[64,91,187,192,293,353],{"text":65,"config":66,"cards":68},"Plattform",{"dataNavLevelOne":67},"platform",[69,75,83],{"title":65,"description":70,"link":71},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":72,"config":73},"Erkunde unsere Plattform",{"href":74,"dataGaName":67,"dataGaLocation":47},"/de-de/platform/",{"title":76,"description":77,"link":78},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":79,"config":80},"Lerne GitLab Duo kennen",{"href":81,"dataGaName":82,"dataGaLocation":47},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":84,"description":85,"link":86},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":87,"config":88},"Mehr erfahren",{"href":89,"dataGaName":90,"dataGaLocation":47},"/de-de/why-gitlab/","why gitlab",{"text":92,"left":32,"config":93,"link":95,"lists":99,"footer":169},"Produkt",{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":47},"/de-de/solutions/",[100,125,147],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":47},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[109,113,116,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":47,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":76,"config":114},{"href":81,"dataGaLocation":47,"dataGaName":115},"gitlab duo agent platform - product menu",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":47,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":47,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":47,"icon":132},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":47},"Application security testing",{"text":139,"config":140},"Schutz der Software-Lieferkette",{"href":141,"dataGaLocation":47,"dataGaName":142},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":47},"/de-de/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Bewertung",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":47},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Sichtbarkeit und Bewertung",{"href":152,"dataGaLocation":47,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Wertstrommanagement",{"href":162,"dataGaLocation":47,"dataGaName":163},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Analysen und Einblicke",{"href":167,"dataGaLocation":47,"dataGaName":168},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab für",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":47,"dataGaName":176},"/de-de/enterprise/","enterprise",{"text":178,"config":179},"Kleinunternehmen",{"href":180,"dataGaLocation":47,"dataGaName":181},"/de-de/small-business/","small business",{"text":183,"config":184},"den öffentlichen Sektor",{"href":185,"dataGaLocation":47,"dataGaName":186},"/de-de/solutions/public-sector/","public sector",{"text":188,"config":189},"Preise",{"href":190,"dataGaName":191,"dataGaLocation":47,"dataNavLevelOne":191},"/de-de/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"Ressourcen",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Alle Ressourcen anzeigen",{"href":199,"dataGaName":195,"dataGaLocation":47},"/de-de/resources/",[201,234,252],{"title":202,"items":203},"Erste Schritte",[204,209,214,219,224,229],{"text":205,"config":206},"Installieren",{"href":207,"dataGaName":208,"dataGaLocation":47},"/de-de/install/","install",{"text":210,"config":211},"Kurzanleitungen",{"href":212,"dataGaName":213,"dataGaLocation":47},"/de-de/get-started/","quick setup checklists",{"text":215,"config":216},"Lernen",{"href":217,"dataGaLocation":47,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Produktdokumentation",{"href":222,"dataGaName":223,"dataGaLocation":47},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best-Practice-Videos",{"href":227,"dataGaName":228,"dataGaLocation":47},"/de-de/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrationen",{"href":232,"dataGaName":233,"dataGaLocation":47},"/de-de/integrations/","integrations",{"title":235,"items":236},"Entdecken",[237,242,247],{"text":238,"config":239},"Kundenerfolge",{"href":240,"dataGaName":241,"dataGaLocation":47},"/de-de/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":47},"/de-de/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":47},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"Vernetzen",[255,260,265,270,275],{"text":256,"config":257},"GitLab-Services",{"href":258,"dataGaName":259,"dataGaLocation":47},"/de-de/services/","services",{"text":261,"config":262},"Community",{"href":263,"dataGaName":264,"dataGaLocation":47},"/community/","community",{"text":266,"config":267},"Forum",{"href":268,"dataGaName":269,"dataGaLocation":47},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"Veranstaltungen",{"href":273,"dataGaName":274,"dataGaLocation":47},"/events/","events",{"text":276,"config":277},"Partner",{"href":278,"dataGaName":279,"dataGaLocation":47},"/de-de/partners/","partners",{"backgroundColor":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":285,"config":286},"the source promo card",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"Lies die News",{"href":291,"dataGaName":292,"dataGaLocation":47},"/de-de/the-source/","the source",{"text":294,"config":295,"lists":297},"Unternehmen",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"Über",{"href":303,"dataGaName":304,"dataGaLocation":47},"/de-de/company/","about",{"text":306,"config":307,"footerGa":310},"Karriere",{"href":308,"dataGaName":309,"dataGaLocation":47},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":47},{"text":314,"config":315},"Geschäftsführung",{"href":316,"dataGaName":317,"dataGaLocation":47},"/company/team/e-group/","leadership",{"text":319,"config":320},"Team",{"href":321,"dataGaName":322,"dataGaLocation":47},"/company/team/","team",{"text":324,"config":325},"Handbuch",{"href":326,"dataGaName":327,"dataGaLocation":47},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"Investor Relations",{"href":331,"dataGaName":332,"dataGaLocation":47},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"Trust Center",{"href":336,"dataGaName":337,"dataGaLocation":47},"/de-de/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":47},"/de-de/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"Newsletter",{"href":346,"dataGaName":347,"dataGaLocation":47},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"Presse",{"href":351,"dataGaName":352,"dataGaLocation":47},"/press/","press",{"text":354,"config":355,"lists":356},"Kontakt",{"dataNavLevelOne":296},[357],{"items":358},[359,362,367],{"text":54,"config":360},{"href":56,"dataGaName":361,"dataGaLocation":47},"talk to sales",{"text":363,"config":364},"Support-Portal",{"href":365,"dataGaName":366,"dataGaLocation":47},"https://support.gitlab.com","support portal",{"text":368,"config":369},"Kundenportal",{"href":370,"dataGaName":371,"dataGaLocation":47},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":373,"login":374,"suggestions":381},"Schließen",{"text":375,"link":376},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":377,"config":378},"gitlab.com",{"href":61,"dataGaName":379,"dataGaLocation":380},"search login","search",{"text":382,"default":383},"Vorschläge",[384,386,391,393,398,403],{"text":76,"config":385},{"href":81,"dataGaName":76,"dataGaLocation":380},{"text":387,"config":388},"Code Suggestions (KI)",{"href":389,"dataGaName":390,"dataGaLocation":380},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":392},{"href":112,"dataGaName":110,"dataGaLocation":380},{"text":394,"config":395},"GitLab auf AWS",{"href":396,"dataGaName":397,"dataGaLocation":380},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":399,"config":400},"GitLab auf Google Cloud",{"href":401,"dataGaName":402,"dataGaLocation":380},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":404,"config":405},"Warum GitLab?",{"href":89,"dataGaName":406,"dataGaLocation":380},"Why GitLab?",{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Kostenlos testen",{"href":411,"dataGaName":52,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"GitLab-Symbol",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":422},{"href":423,"dataGaName":424,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":426,"mobileIcon":431,"desktopIcon":433},{"text":427,"config":428},"Erfahre mehr über GitLab Duo",{"href":429,"dataGaName":430,"dataGaLocation":412},"/de-de/gitlab-duo/","gitlab duo",{"altText":414,"config":432},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":434},{"src":420,"dataGaName":417,"dataGaLocation":412},{"freeTrial":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"Zurück zur Preisübersicht",{"href":190,"dataGaName":439,"dataGaLocation":412,"icon":440},"back to pricing","GoBack",{"altText":414,"config":442},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":444},{"src":420,"dataGaName":417,"dataGaLocation":412},{"title":446,"button":447,"config":452},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":448,"config":449},"GitLab Transcend jetzt ansehen",{"href":450,"dataGaName":451,"dataGaLocation":47},"/de-de/events/transcend/virtual/","transcend event",{"layout":453,"icon":454},"release","AiStar",{"data":456},{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":652},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,558,585,619],{"title":65,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":74,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":188,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":190,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":130,"dataGaName":137,"dataGaLocation":463},{"text":122,"config":515},{"href":106,"dataGaName":107,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":110,"config":531},{"href":112,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":160,"config":534},{"href":162,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":173,"config":542},{"href":175,"dataGaName":176,"dataGaLocation":463},{"text":178,"config":544},{"href":180,"dataGaName":181,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":185,"dataGaName":186,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":557,"dataGaLocation":463},"/de-de/solutions/finance/","financial services",{"title":193,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583],{"text":205,"config":561},{"href":207,"dataGaName":208,"dataGaLocation":463},{"text":210,"config":563},{"href":212,"dataGaName":213,"dataGaLocation":463},{"text":215,"config":565},{"href":217,"dataGaName":218,"dataGaLocation":463},{"text":220,"config":567},{"href":222,"dataGaName":568,"dataGaLocation":463},"docs",{"text":243,"config":570},{"href":245,"dataGaName":246,"dataGaLocation":463},{"text":238,"config":572},{"href":240,"dataGaName":241,"dataGaLocation":463},{"text":248,"config":574},{"href":250,"dataGaName":251,"dataGaLocation":463},{"text":256,"config":576},{"href":258,"dataGaName":259,"dataGaLocation":463},{"text":261,"config":578},{"href":263,"dataGaName":264,"dataGaLocation":463},{"text":266,"config":580},{"href":268,"dataGaName":269,"dataGaLocation":463},{"text":271,"config":582},{"href":273,"dataGaName":274,"dataGaLocation":463},{"text":276,"config":584},{"href":278,"dataGaName":279,"dataGaLocation":463},{"title":294,"links":586},[587,589,591,593,595,597,599,603,608,610,612,614],{"text":301,"config":588},{"href":303,"dataGaName":296,"dataGaLocation":463},{"text":306,"config":590},{"href":308,"dataGaName":309,"dataGaLocation":463},{"text":314,"config":592},{"href":316,"dataGaName":317,"dataGaLocation":463},{"text":319,"config":594},{"href":321,"dataGaName":322,"dataGaLocation":463},{"text":324,"config":596},{"href":326,"dataGaName":327,"dataGaLocation":463},{"text":329,"config":598},{"href":331,"dataGaName":332,"dataGaLocation":463},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":463},"/sustainability/",{"text":604,"config":605},"Vielfalt, Inklusion und Zugehörigkeit",{"href":606,"dataGaName":607,"dataGaLocation":463},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":609},{"href":336,"dataGaName":337,"dataGaLocation":463},{"text":344,"config":611},{"href":346,"dataGaName":347,"dataGaLocation":463},{"text":349,"config":613},{"href":351,"dataGaName":352,"dataGaLocation":463},{"text":615,"config":616},"Transparenzerklärung zu moderner Sklaverei",{"href":617,"dataGaName":618,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":620,"links":621},"Nimm Kontakt auf",[622,625,630,632,637,642,647],{"text":623,"config":624},"Sprich mit einem Experten/einer Expertin",{"href":56,"dataGaName":57,"dataGaLocation":463},{"text":626,"config":627},"Support",{"href":628,"dataGaName":629,"dataGaLocation":463},"/support/","get help",{"text":368,"config":631},{"href":370,"dataGaName":371,"dataGaLocation":463},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":638,"config":639},"Nutzungsbedingungen",{"href":640,"dataGaName":641,"dataGaLocation":463},"/terms/","terms of use",{"text":643,"config":644},"Datenschutzerklärung",{"href":645,"dataGaName":646,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":648,"config":649},"Cookie-Einstellungen",{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":32},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":463},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":463},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":32},[661,674],{"id":662,"title":19,"body":9,"config":663,"content":665,"description":9,"extension":30,"meta":669,"navigation":32,"path":670,"seo":671,"stem":672,"__hash__":673},"blogAuthors/en-us/blog/authors/victor-wu.yml",{"template":664},"BlogAuthor",{"name":19,"config":666},{"headshot":667,"ctfId":668},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","victorwu",{},"/en-us/blog/authors/victor-wu",{},"en-us/blog/authors/victor-wu","_RaxCS0f7IbUMauxXuHjiPl8yHoiX4KN9SL3QR_TLuA",{"id":675,"title":20,"body":9,"config":676,"content":677,"description":9,"extension":30,"meta":681,"navigation":32,"path":682,"seo":683,"stem":684,"__hash__":685},"blogAuthors/en-us/blog/authors/amanda-rueda.yml",{"template":664},{"name":20,"config":678},{"headshot":679,"ctfId":680},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660008/Blog/Author%20Headshots/amanda_rueda_headshot.png","73IHSOcUmhlsh9XDSEiyjs",{},"/en-us/blog/authors/amanda-rueda",{},"en-us/blog/authors/amanda-rueda","oWTvPkKdNmIvF6Spj5T_HWx1C29ptZ6HORAQ6XZRmGM",[687,701,717],{"content":688,"config":699},{"title":689,"description":690,"heroImage":691,"date":692,"body":693,"category":10,"tags":694,"authors":697},"Planung ohne Kontext-Wechsel – mit GitLab Duo Planner","KI-Agent für Produktmanager: GitLab Duo Planner strukturiert Anforderungen, analysiert Abhängigkeiten und erstellt Status-Reports ohne Tool-Wechsel.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-28","Software-Entwicklungsteams verwalten viele parallele Aufgaben mit begrenzten Ressourcen. Die Planung erfordert kontinuierliche Arbeit: Anforderungen strukturieren, Backlogs pflegen, Delivery tracken und Status-Updates erstellen.\n\nDer Planungsaufwand reduziert die Zeit für strategische Entscheidungen, die Produkte tatsächlich voranbringen.\n\nFür diese Herausforderung haben wir [GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) entwickelt – einen KI-Agent auf Basis der [GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/), der Produktmanager direkt in GitLab unterstützt.\n\nGitLab Duo Planner ist kein generischer KI-Assistent. Die Produkt- und Engineering-Teams bei GitLab haben den Agent gezielt für Planungs-Workflows entwickelt, um Overhead zu reduzieren und gleichzeitig Alignment und Planbarkeit zu verbessern.\n\n## Unterstützung für deine Planung\n\nDrei Herausforderungen in der Planungspraxis:\n\n1. Ungeplante Arbeit – Unkoordinierte Tasks und verwaiste Work Items reduzieren das Vertrauen in die Planung.\n2. Unterbrechungen – Ständige Status-Anfragen unterbrechen den Entwicklungsfluss.\n3. Intransparenz – Risiken werden zu spät sichtbar, um gegenzusteuern.\n\nGitLab Duo Planner unterstützt Teams bei diesen Aufgaben: Der Agent strukturiert vage Ideen in konkrete Anforderungen, identifiziert Backlog-Probleme frühzeitig und wendet Priorisierungs-Frameworks wie RICE und MoSCoW an. Durch die Integration in GitLab hat der Agent Zugriff auf den vollständigen Kontext der Plattform. Die foundational agent architecture ermöglicht GitLab-spezifisches Wissen und Kontext-Awareness.\n\n## Für Teams entwickelt\n\nGitLab Duo Planner arbeitet mit Work Items (Epics, Issues, Tasks) und versteht Work Breakdown Structures, Dependency-Analysen und Aufwandsschätzungen. Dies verbessert Transparenz, Alignment und Planungssicherheit.\n\n**Plattform-Ansatz:** Im Unterschied zu Einzellösungen orchestriert Duo Planner über die gesamte GitLab-Plattform – von der Planung über Development bis Testing. Dies schafft Transparenz über Teams und Workflows hinweg.\n\n**Im Workflow integriert:** Kein Wechsel zwischen Tools oder tiefes Navigieren in GitLab erforderlich. Duo Planner ermöglicht Beiträge, Kollaboration und Transparenz für alle Beteiligten im Software Development Lifecycle.\n\n**Zeitersparnis:** Duo Planner befreit Teams von repetitiver Koordinationsarbeit, verbessert die Planbarkeit von Deliveries und reduziert verpasste Commitments. Der Fokus liegt auf der Arbeit, die tatsächlich Wirkung zeigt.\n\n## Sechs Workflows für Software-Planung\n\nGitLab Duo Planner unterstützt verschiedene Phasen der Software-Planung und arbeitet innerhalb des Planungsbereichs – einer definierten Umgebung mit Projekt-Visibility.\n\nDer Agent deckt sechs Workflows ab:\n\n**Priorisierung:** Frameworks wie RICE, MoSCoW oder WSJF werden angewendet, um Work Items systematisch zu ranken. RICE bewertet nach Reach, Impact, Confidence und Effort. MoSCoW kategorisiert nach Must have, Should have, Could have, Won't have. WSJF (Weighted Shortest Job First) gewichtet nach Business Value, Time Criticality und Risk Reduction.\n\n**Work Breakdown:** Initiativen werden in Epics, Features und User Stories zerlegt, um Anforderungen zu strukturieren. Dies folgt der hierarchischen Work Item-Struktur in GitLab.\n\n**Dependency-Analyse:** Der Agent identifiziert blockierte Arbeit und versteht Beziehungen zwischen Items, um die Velocity aufrechtzuerhalten. Abhängigkeiten werden als Blocker oder \"blocked by\"-Relationen erfasst.\n\n**Planung:** Organisation von Sprints, Milestones oder Quartalsplanungen. Der Agent berücksichtigt dabei die verfügbare Kapazität und bestehende Commitments.\n\n**Status-Reporting:** Generierung von Zusammenfassungen über Projekt-Fortschritt, Risiken und Blocker zum Tracking von Deliveries. Die Reports strukturieren sich nach Overview, Milestone-Status, In-Progress Items, Dependencies und Blockers.\n\n**Backlog Management:** Identifikation veralteter Issues, Duplikate oder Items, die Verfeinerung benötigen. Dies verbessert die Datenhygiene im Backlog.\n\n## Demonstration: Status-Check einer Initiative\n\nHier siehst du, wie GitLab Duo Planner den Status einer Initiative prüft:\n\n\u003Cdiv>\u003Ciframe src=\"https://player.vimeo.com/video/1131065078?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Planner Agent\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\nDuo Planner ist als Custom Agent im Duo Chat Side Panel verfügbar und nutzt den aktuellen Seiten-Kontext.\n\n\u003Cp>\u003C/p>\n\n![Duo Planner als Custom Agent im Duo Chat Side Panel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/ener1mkyj9shg6zvtp4f.png)\n\n\u003Cp>\u003C/p>\n\nWir fragen Duo Planner nach dem Status einer Initiative, indem wir den Epic-Link angeben:\n\n![Abfrage des Initiative-Status durch Angabe des Epic-Links](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/gzv2xudegtjhtesz1oaz.png)\n\n\u003Cp>\u003C/p>\n\nDer Agent liefert eine strukturierte Zusammenfassung mit Overview, aktuellem Status der Milestones, in Bearbeitung befindlichen Items, Dependencies und Blockern sowie umsetzbaren Empfehlungen.\n\n![Strukturierte Zusammenfassung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/guoyqe1b9bstmbjzunez.png)\n\n\u003Cp>\u003C/p>\n\nAls Nächstes fordern wir eine Executive Summary an, um Stakeholder zu informieren. GitLab Duo Planner reduziert den manuellen Analyseaufwand für Reports und unterstützt schnellere Entscheidungen.\n\n![Anforderung einer Executive Summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/xs9zxawqrytfu54ejx2b.png)\n\n\u003Cp>\u003C/p>\n\n![Ausgabe der Executive Summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/bsbpvjaqnymobzg4knhu.png)\n\n\u003Cp>\u003C/p>\n\nWeitere Beispiel-Prompts für GitLab Duo Planner:\n\n* \"Welche Bugs mit dem Label 'boards' sollten wir priorisieren, unter Berücksichtigung der User Impact?\"\n* \"Ranke diese Epics nach strategischem Wert für Q1.\"\n* \"Hilf mir, Technical Debt gegen neue Features zu priorisieren.\"\n* \"Welche Tasks sind erforderlich, um diese User Story zu implementieren?\"\n* \"Schlage einen phasenweisen Ansatz für dieses Projekt vor: (URL einfügen).\"\n\n## Agile-Planung mit GitLab\n\nGitLab Duo Planner konzentriert sich gezielt auf Produktmanager und Engineering Manager in Agile-Umgebungen. Diese Spezialisierung ermöglicht verlässliche, umsetzbare Erkenntnisse statt generischer Vorschläge. Der Agent wurde auf GitLabs Planungs-Workflows und Agile Frameworks trainiert.\n\nDie Agent Platform entwickelt sich weiter: Wir arbeiten an einer Familie spezialisierter Agents, die jeweils für spezifische Workflows optimiert sind und zu einer unified intelligence layer beitragen. Der heutige Planner für Software-Teams ist der erste Schritt für KI-gestützte Priorisierung in verschiedenen Team-Kontexten.\n\n**Integration in deutsche Agile-Prozesse:** GitLab Duo Planner lässt sich in bestehende Scrum- und Kanban-Workflows integrieren. Der Agent arbeitet mit der Standard-Work-Item-Hierarchie in GitLab und respektiert definierte Projekt-Boundaries. Beispielsweise können Teams den Agent für Sprint Planning einsetzen, indem sie Backlog-Items nach RICE bewerten lassen und anschließend die Ergebnisse im Sprint Planning Meeting verwenden.\n\n**Technische Voraussetzungen:** Die Nutzung erfordert GitLab mit aktivierter Duo Chat Funktion. Der Agent operiert innerhalb der konfigurierten Projekt-Visibility und hat Zugriff auf Work Items, für die du Leserechte besitzt. Die Dokumentation erklärt Prerequisites, Anwendungsfälle und Konfiguration im Detail.\n\n> Wenn du GitLab-Kunde bist und GitLab Duo Planner mit eigenen Prompts testen möchtest, findest du in unserer [Dokumentation](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) Prerequisites, Anwendungsfälle und weitere Details.",[695,25,26,696],"AI/ML","product",[698,20],"Aathira Nair",{"featured":32,"template":14,"slug":700},"ace-your-planning-without-the-context-switching",{"content":702,"config":715},{"heroImage":703,"body":704,"authors":705,"updatedDate":709,"date":710,"title":711,"tags":712,"description":714,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","Kommt dir das bekannt vor? Du wechselst ständig zwischen Tabs in GitLab, nur um den\nÜberblick zu behalten, was in deinem Projekt passiert? Vielleicht prüfst du\neine Issue, springst dann zu einem Merge Request und dann zu einem Epic, um\nzu sehen, wie alles zusammenhängt. Ehe du dich versiehst, ist dein Browser\nvoller Tabs und du hast den roten Faden verloren.\n\nKeine Sorge, du stehst nicht alleine da. Viele Teams verschwenden Zeit und Energie damit, zwischen verschiedenen Elementen in ihrer Projektverwaltungssoftware hin und her zu springen, nur um den Überblick über ihre Arbeit zu behalten.\n\nDeshalb haben wir [Embedded Views](https://docs.gitlab.com/user/glql/#embedded-views) entwickelt, angetrieben von [GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/). Mit Embedded Views, [verfügbar ab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), erhältst du Live-Informationen genau dort, wo du bereits in GitLab arbeitest. Kein endloses Kontextwechseln mehr. Keine veralteten Berichte mehr. Nur die Informationen, die du brauchst, genau dann, wenn du sie brauchst.\n\n## Warum Embedded Views wichtig sind\n\nEmbedded Views sind mehr als nur ein neues Feature – sie stellen eine grundlegende Veränderung dar, wie Teams ihre Arbeit in GitLab verstehen und verfolgen. Mit Embedded Views können Teams den Kontext beibehalten, während sie auf Echtzeitinformationen zugreifen, gemeinsames Verständnis schaffen und die Zusammenarbeit verbessern, ohne ihren aktuellen Workflow zu verlassen. Es geht darum, die Arbeitsverfolgung natürlich und mühelos zu gestalten, damit Sie sich auf das Wesentliche konzentrieren können.\n\n## So funktioniert's: Echtzeitdaten genau dort, wo sie am meisten gebraucht werden\n\nMit Embedded Views kannst du Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests einfügen. Das macht sie so nützlich:\n\n### Immer aktuell\n\nGLQL-Abfragen sind dynamisch und rufen bei jedem Seitenladen frische Daten ab. Deine Embedded Views spiegeln also immer den aktuellen Zustand deiner Arbeit wider, nicht den Zustand beim Einbetten der Ansicht. Wenn Änderungen an Issues, Merge Requests oder Milestones auftreten, zeigt eine Seitenaktualisierung diese Updates in Ihrer Embedded View an.\n\n### Kontextbezogenes Bewusstsein\n\nVerwende Funktionen wie `currentUser()` und `today()`, um Abfragen kontextspezifisch zu machen. Deine Embedded Views passen sich automatisch an, um relevante Informationen für die jeweilige Person anzuzeigen, die sie betrachtet, und schaffen so personalisierte Erlebnisse ohne manuelle Konfiguration.\n\n### Leistungsstarke Filterung\n\nFilter nach Feldern wie Zuweisenden, Autor(inn)en, Label, Milestone, Gesundheitsstatus, Erstellungsdatum und mehr. Verwende logische Ausdrücke, um genau die gewünschten Daten zu erhalten. Wir unterstützen mehr als 30 Felder ab Version 18.3.\n\n### Anpassbare Anzeige\n\nDu kannst deine Daten als Tabelle, Liste oder nummerierte Liste anzeigen. Wähle, welche Felder angezeigt werden sollen, lege ein Limit für die Anzahl der Elemente fest und gib die Sortierreihenfolge an, um deine Ansicht fokussiert und handlungsorientiert zu halten.\n\n### Verfügbarkeit\n\nDu kannst Embedded Views in Gruppen- und Projekt-Wikis, Epic- und Issue-Beschreibungen, Merge Requests und Kommentaren verwenden. GLQL ist in allen GitLab-Stufen verfügbar: Free, Premium und Ultimate, auf GitLab.com, GitLab Self-Managed und GitLab Dedicated. Bestimmte Funktionen wie die Anzeige von Epics, Status, benutzerdefinierten Feldern, Iterationen und Gewichtungen sind in den Stufen Premium und Ultimate verfügbar. Die Anzeige des Gesundheitsstatus ist nur in Ultimate verfügbar.\n\n## Embedded Views in Aktion erleben\n\nDie Syntax einer Embedded View-Quelle ist eine Obermenge von YAML. Sie besteht aus:\n\n* Dem `query`-Parameter: Ausdrücke, die mit einem logischen Operator wie `and` verbunden werden.\n* Parametern für die Präsentationsebene wie `display`, `limit` oder `fields`, `title` und `description`,\n  dargestellt als YAML.\n\nEine View wird in Markdown als Codeblock definiert, ähnlich wie andere Codeblöcke wie Mermaid.\n\nZum Beispiel:\n\n> Zeige eine Tabelle der ersten 5 offenen Issues an, die dem authentifizierten Benutzer in `gitlab-org/gitlab` zugewiesen sind.\n>\n> Zeige die Spalten `title`, `state`, `health`, `description`, `epic`, `milestone`, `weight` und `updated`.\n\n````yaml\n```glql\n\ndisplay: table\n\ntitle: GLQL-Tabelle 🎉\n\ndescription: Diese Ansicht listet meine offenen Issues auf\n\nfields: title, state, health, epic, milestone, weight, updated\n\nlimit: 5\n\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n```\n````\nDiese Quelle sollte eine Tabelle wie die folgende rendern:\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\nEine einfache Möglichkeit, erste Embedded View zu erstellen, besteht darin, zum Dropdown-Menü **Weitere Optionen** in der Rich-Text-Editor-Symbolleiste zu navigieren. Wähle dort **Embedded View** aus, wodurch folgende Abfrage in einem Markdown-Codeblock eingefügt wird:\n\n````yaml\n```glql\n\nquery: assignee = currentUser()\n\nfields: title, createdAt, milestone, assignee\n\ntitle: Mir zugewiesene Issues\n```\n````\n\nSpeicher deine Änderungen im Kommentar oder in der Beschreibung, wo der Codeblock erscheint, und schon bist du fertig! Du hast erfolgreich deine erste Embedded View erstellt!\n\n## Wie GitLab Embedded Views nutzt\n\nOb wir Merge Requests für Security-Releases nachverfolgen, Bugs zur Verbesserung der Backlog-Hygiene triagieren oder Team-Onboarding und Milestone-Planung verwalten – wir verlassen uns täglich bei geschäftskritischen Prozessen auf Embedded Views. Dies ist nicht nur ein Feature, das wir entwickelt haben, es ist ein Tool, auf das wir uns verlassen, um unser Geschäft effektiv zu führen. Wenn du Embedded Views einführst, erhältst du eine getestete Lösung, die GitLab-Teams bereits dabei hilft, effizienter zu arbeiten, datengesteuerte Entscheidungen zu treffen und die Transparenz über komplexe Workflows hinweg zu wahren. Einfach ausgedrückt: Embedded Views können verändern, wie dein Team auf die Arbeit zugreift und sie analysiert, die für deinen Erfolg am wichtigsten ist.\n\nUm mehr darüber zu erfahren und zu sehen, wie GitLab Embedded Views intern nutzt, schaue dir [How GitLab measures Red Team impact: The adoption rate metric](https://about.gitlab.com/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric/) und Global Search Release Planning Issues für die Milestones [18.1](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/239), [18.2](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/241) und [18.3](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/245) an.\n\n## Was kommt als Nächstes\n\nEmbedded Views sind nur der Anfang der Vision der [Knowledge Group](https://about.gitlab.com/direction/plan/knowledge/) für die Arbeitsverfolgung. Erfahre mehr über unsere nächsten Schwerpunkte im [Embedded Views Post-GA Epic](https://gitlab.com/groups/gitlab-org/-/epics/15249). Während sich Embedded Views weiterentwickeln, wollen wir sie noch leistungsfähiger und [zugänglicher](https://gitlab.com/gitlab-org/gitlab/-/issues/548722) zu machen.\n\n## Teile deine Erfahrungen\n\nTeile uns dein Feedback mit im [Embedded Views GA Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/509792). Egal ob du innovative Anwendungsfälle entdeckt hast, auf Herausforderungen gestoßen bist oder Verbesserungsideen hast – wir wollen von dir hören.\n",[706,707,708],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21","Embedded Views: Die Zukunft des Work Tracking in GitLab",[25,713,27],"DevSecOps platform","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":13,"template":14,"slug":716},"embedded-views-the-future-of-work-tracking-in-gitlab",{"content":718,"config":727},{"heroImage":719,"body":720,"authors":721,"updatedDate":723,"date":723,"title":724,"tags":725,"description":726,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661979/Blog/Hero%20Images/scrum-project-management.jpg","Die User Story ist ein sehr einfaches Konzept. Trotzdem hat sie die Projektplanung entscheidend verändert \\- und das, obwohl User Stories zum Beispiel in [Scrum](https://about.gitlab.com/de-de/blog/scrum-project-management-how-it-works/) nicht einmal vorkommen. \n\nGerade weil User Storys für die Teamarbeit so wichtig sind, stellen sie eine Herausforderung dar. Diskussionen um die richtige Formulierung einer User Story in Scrum oder ihre korrekte Bearbeitung in [Kanban](https://about.gitlab.com/de-de/blog/what-is-kanban/) können wertvolle Zeit verbrauchen. So empfinden viele das Konzept eher als undeutlich, aufwändig und belastend. \n\nWir glauben fest daran, dass eine tiefe Verinnerlichung von User Storys - gerade in der [agilen Methode](https://about.gitlab.com/de-de/solutions/agile-delivery/) - dich wirklich voranbringen kann. In diesem Artikel werden wir deshalb so praxisnah wie möglich demonstrieren, wie du sie nutzen kannst, um zu besseren Entscheidungen, Prozessen und Produkten zu gelangen.\n\n## Inhaltsverzeichnis\n\n- [Was ist eine User Story?](#was-ist-eine-user-story%3F)\n- [Warum sollte ich mit User Stories arbeiten?](#warum-sollte-ich-mit-user-stories-arbeiten%3F)\n- [Kann ich auch ohne User Stories auskommen?](#kann-ich-auch-ohne-user-stories-auskommen%3F)\n- [Welche Rolle spielen User Stories in Agile?](#welche-rolle-spielen-user-stories-in-agile%3F)\n- [User Stories in Scrum](#user-stories-in-scrum)\n- [Wie schreibe ich eine gute User Story?](#wie-schreibe-ich-eine-gute-user-story%3F)\n  - [Das 3C-Modell](#das-3c-modell)\n  - [INVEST](#invest)\n- [Scrum User Story: Aufbau und Beispiel](#scrum-user-story-aufbau-und-beispiel)\n  - [User-Story-Beispiel Schritt 1: 5 Whys](#user-story-beispiel-schritt-1-5-whys)\n  - [User-Story-Beispiel Schritt 2: Connextra-Template](#user-story-beispiel-schritt-2-connextra-template)\n  - [User-Story-Beispiel Schritt 3: Akzeptanzkriterien](#user-story-beispiel-schritt-3-akzeptanzkriterien)\n  - [Das Gherkin-Format](#das-gherkin-format)\n- [Agile Schätzung](#agile-schatzung)\n- [Story Points: Aufwand vs. Arbeitszeit](#story-points-aufwand-vs-arbeitszeit)\n- [Story Points in der Schätzung](#story-points-in-der-schatzung)\n  - [Planning Poker](#planning-poker)\n  - [Affinity Mapping](#affinity-mapping)\n- [Wer schreibt User Stories?](#wer-schreibt-user-stories%3F)\n\nWir werden dabei definieren, was User Stories sind, über das Schreiben und den Aufbau einer User Story informieren, Beispiele geben und dir zeigen, was eine gute User Story ausmacht. Doch fangen wir mit einer grundlegenden Frage an:\n\n## Was ist eine User Story?\n\nManche bezeichnen eine User Story schlicht als die kleinste Einheit (oder auch als ein „[Werkzeug](https://t2informatik.de/wissen-kompakt/user-story/)”) der agilen Methode. Andere, darunter auch die [Agile Scrum Group](https://scrumguide.de/user-story/), als eine „Beschreibung dessen, was ein Benutzer (User) will.” \n\nAus diesen Definitionsversuchen wird deutlich: **Eine User Story ist eigentlich gar keine „Geschichte”. Sie stellt vielmehr einen Ansatz dar, dein Produkt so zu verändern, dass es aus der Sicht der Kund(innen) ein neues, besseres Erlebnis bietet.** \n\nInnerhalb einer User Story ist ein neues Feature somit nur dann eine Verbesserung, wenn es Anwender(innen) einen ganz bestimmten, erfahrbaren Nutzen bietet. Eine Software zu „optimieren”, ohne nach diesem Nutzen zu fragen, wird dabei als nicht zielführend betrachtet. \n\nGute User Stories zu schreiben, bedeutet, dich in der Entwicklung von Kund(innen) leiten zu lassen und auf ihre Bedürfnisse und Wünsche hinzuarbeiten. Es bedeutet, den Fokus auf Features hinter dir zu lassen und dich in Richtung einer Betrachtungweise zu bewegen, bei der echte Wertschöpfung in den Mittelpunkt gestellt wird. \n\nDennoch wurde der Begriff „Story”, wie Jeff Patton, einer der geistigen Väter der modernen User Story betont hat, mit Bedacht gewählt. Wir werden darauf später noch genauer eingehen. \n\n## Warum sollte ich mit User Stories arbeiten?\n\nDiese Frage stellt sich in einigen Teams wohl so manche(r). Denn in der Praxis nimmt sich die Arbeit mit User Stories nicht immer einfach aus. Dennoch lohnt sich die investierte Mühe zweifelsohne. Denn das Konzept der User Story mag auf dem Papier fast schon banal anmuten. In Wahrheit steckt dahinter eine entscheidende Neuausrichtung der Entwicklungsarbeit:\n\n* User Stories legen den Fokus voll und ganz auf die Anwender(innen) \\- also auf diejenigen, die das Produkt nutzen, bewerten und bezahlen.   \n* Sie verlagern den Schwerpunkt von „objektiven” Features auf das „subjektive” Erlebnis, mit diesen Features zu arbeiten. Hier kommt der „Story-Gedanke” zum Tragen: Wie wertvoll dein Produkt aus Sicht der Kund(innen) ist, hängt von der Geschichte ab, die sich User(innen) darüber bilden.   \n* Damit kombinieren diese Stories beide Sichten auf ein Produkt: Die technisch-funktionale sowie die narrativ-emotionale.   \n* Weil User Stories die Betonung auf den Nutzen legen, der für Kund(innen) entsteht, sind sie in ihrer Umsetzung nicht starr festgelegt. Das Ziel ist nicht die Anwendung, sondern die Vorstellung von einer besseren Erfahrung. Der Weg zu dieser Erfahrung lässt sich auf viele verschiedene Weisen erreichen.   \n* User Storys sind Teil eines kontinuierlichen Verbesserungsprozesses wie der [automatisierten Softwarebereitstellung](https://about.gitlab.com/de-de/solutions/delivery-automation/), mit vielen sofort testbaren Zwischenstufen (*minimal viable product*, das kleinste realisierbare Produkt). Dieser Prozess endet theoretisch mit einem Produkt, das aus Sicht der Kund(innen) nicht mehr optimiert werden kann (und welches somit in der Praxis niemals erreicht werden wird). \n\nIn der Regel helfen User Stories auch dabei, sinnvolle Prioritäten zu setzen, die praxisnah und in einem angemessenen Zeitrahmen realisierbar sind. \n\n## Kann ich auch ohne User Stories auskommen? \n\nUser Stories haben sich fest etabliert. Dennoch kommen auch heute noch viele Teams ohne sie aus. Sogar Firmen, die sich eigentlich fest der agilen Methode verschrieben haben, nutzen sie nicht zwangsläufig. \n\nTrotzdem kann man behaupten: Wer wirklich agil arbeiten will, wird zumindest mit Instrumenten und Konzepten arbeiten, die den User Stories sehr nahe kommen. Wie wir im nächsten Abschnitt zeigen werden, bauen beide auf demselben Ansatz auf und sind eng miteinander verflochten.\n\nAndersherum gilt auch: Nicht jedes Team, das auf User Stories setzt, hat die Philosophie voll verinnerlicht. Nur allzu leicht wird eine User Story zu einem einfachen „Requirement” \\- einer Auflistung gewünschter Funktionalitäten, bei der oftmals der Nutzen für Kund(innen) vergessen wird. \n\n## Welche Rolle spielen User Stories in Agile? \n\nAus dem Gesagten wird ersichtlich, warum User Stories in der agilen Entwicklung auf einen fruchtbaren Nährboden gestoßen sind. Beide legen den Fokus auf ständige Verbesserungen, Teamarbeit einschließlich einer engen Zusammenarbeit mit Kund(innen), und die Orientierung der Ergebnisse an klaren Bewertungskriterien. \n\nUser Stories fügen sich nahtlos in eine agile Organisation ein: \n\n* Idealerweise kann eine User Story innerhalb eines einzigen Sprints abgearbeitet werden.   \n* User Stories werden im Team festgelegt, besprochen und umgesetzt.  \n* Ein klar definiertes Bewertungssystem liefert die Daten, die benötigt werden, um ein Projekt abzuschließen.\n\nWillst du User Stories in deinem Team nutzen? Wenn du mit Kanban arbeitest, brauchst du für deine Projektarbeit nichts zu verändern. Du kannst weiterhin mit deinen To-do-Listen arbeiten, richtest die Ziele aber nunmehr auf die Perspektive von Kund(innen) aus. \n\n## User Stories in Scrum\n\nWie gezeigt, sind User Stories sehr eng mit der agilen Methode verbunden. Und Scrum ist eine der zentralen Konzepte zur Umsetzung der agilen Methode. So erscheint es als selbstverständlich, dass User Stories auch in Scrum Anwendung finden.\n\nInteressanterweise aber werden sie im [Scrum User Guide](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf) nicht erwähnt. Stattdessen thematisiert dieser lediglich den „Product Backlog”, also\n\n*„alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen, die das Produkt in Zukunft verändern sollen. Ein Product Backlog Item enthält eine Beschreibung, eine Reihenfolge, Schätzung und Bewertung als Attribute.” \\[Übersetzung aus dem Englischen\\]*\n\nAus dem gerade Erwähnten dürfen keine falschen Schlussfolgerungen gezogen werden. \n\nUser Stories sind nicht die einzige Möglichkeit, mit Scrum kundenorientiert zu arbeiten. Trotzdem haben sie in Scrum ganz gewiss ihren Platz\\! Vielmehr möchte sich der Scrum-Guide nur nicht eindeutig auf ihre Verwendung festlegen und Scrum-Mastern maximale Freiheit einräumen.\n\n## Wie schreibe ich eine gute User Story?\n\nDiese Frage stellt sich zu Beginn nahezu jedes neuen Sprints. Wenn User Stories intuitiv erfassbar und ihre Vorteile offensichtlich sind und wenn das Konzept an sich einfach zu erklären ist \\- warum fällt es dann schwer, es in die Praxis umzusetzen?\n\nWenn du dich mit dieser Frage beschäftigst, mache dir deswegen keine Vorwürfe. User Storys gibt es als methodische Idee bereits seit fast 30 Jahren. Innerhalb dieser Zeit hat es immer wieder Bemühungen gegeben, die Umsetzung zu vereinfachen \\- ein eindeutiges Indiz, dass sie nicht einfach ist. \n\nEine gute User Story hat bestimmte Qualitätskriterien. Diese werden wir uns im nächsten Abschnitt ansehen. Trotzdem glauben wir, dass es möglich ist, auf einer etwas allgemeineren Ebene zu erklären, was eine gute User Story ausmacht:\n\nDamit eine User Story wirklich Nutzen für Kund(innen) generiert, muss sie ihrer Erlebniswelt so nahe wie möglich kommen. Deshalb werden viele der besten User Storys de facto von den Anwender(innen) verfasst \\- sei es nach einem intensiven Gespräch oder weil der Kontakt so eng ist, dass du sehr genau abschätzen kannst, was diese sich wünschen. \n\nDas zweite wichtige Kriterium ist, diesen Nutzen so lebendig wie möglich darzustellen. Wir haben zu Anfang erwähnt, dass eine User Story keine Geschichte ist. Wenn wir sie zu Papier bringen, dann solltest du sie dir sehr plastisch vorstellen können: *So dreidimensional wie ein kleiner Film, der vor dem geistigen Auge abläuft, so kurz gefasst wir ein Haiku.* Dabei kannst du die Zufriedenheit bei Anwender(innen) förmlich spüren. \n\nAuf einer formalen Ebene können das 3C-Modell und die INVEST-Methode weitere Hinweise liefern. In den folgenden beiden Abschnitten gehen wir genauer auf sie ein.\n\n### Das 3C-Modell\n\nDas 3C-Modell entstand bereits früh in der User-Story-Geschichte. Es stammt noch aus einer Zeit, in der die Stories noch wortwörtlich „zu Papier” gebracht wurden. Für eine gute Story sollten in diesem Rahmenwerk folgende drei Punkte erfüllt sein:\n\n1. **C**ard: Die User Story sollte so knapp bemessen sein, dass sie auf eine Karteikarte passt, jedoch ausführlich genug, dass sie diese Karte komplett ausfüllt.   \n2. **C**onversation: Die User Story definiert einen Wunsch und Nutzen der Kund(innen). Die Bewertung und Umsetzung dieser Story erfolgt in enger Zusammenarbeit zwischen allen Teammitgliedern und Kund(innen). Intensive Gespräche sind dabei ein zentraler Bestandteil.  \n3. **C**onfirmation: Es muss eine objektivierbare Möglichkeit bestehen, festzustellen, wann das Ziel erreicht ist. \n\nDas 3C-Modell ist angenehm knapp und bringt zur Geltung, was eine gute Story von einer weniger überzeugenden unterscheidet. Gleichzeitig liefert es wenig praktische Hilfe dabei, eine solche User Story zu schreiben.\n\n### INVEST\n\nAuch bei dem Akronym INVEST handelt es sich um einen Katalog von Anforderungen an gutes User-Story-Schreiben. Es gibt Überschneidungen mit 3C, aber auch eigenständige Punkte.\n\nSehen wir uns die sechs Anforderungen von INVEST einzeln an:\n\n1. **I**ndependent: Jede User Story sollte einen eigenständigen Wunsch von Kund(innen) abbilden. Sie sollte nicht von der Umsetzung anderer Wünsche abhängen.   \n2. **N**egotiable: Die Bedürfnisse der Kund(innen) stehen immer im Vordergrund. Aber eine User Story lebt auch vom regen Austausch zwischen verschiedenen Abteilungen und Teams. Wichtiger als ein starres Festhalten an einmal gewählten Formulierungen ist ein ständiges Aushandeln und Neuverhandeln der Ziele sowie der Methoden zu ihrer Umsetzung.   \n3. **V**aluable: Eine gute User Story muss einen echten, spürbaren Nutzen für Kunden liefern.  \n4. **E**stimate: Manche User Storys werden sich schnell und problemlos lösen lassen. Andere sind komplex. Damit für die praktische Arbeit ausreichend Mitarbeiter(innen) mit dem erforderlichen Wissen zur Verfügung gestellt werden, bedarf es einer möglichst genauen Aufwandseinschätzung.  \n5. **S**mall: Eine User Story sollte in einem Sprint beendet werden können. Sobald du mit einem signifikant höheren Aufwand rechnest, solltest du die Story aufteilen oder von Anfang an als Epic planen.  \n6. **T**estable: Zur Bewertung einer User Story solltest du Abnahmekriterien festlegen können. Diese erlauben es dir, später zu bestimmen, ob du das zu Anfang gesteckte Ziel erreicht hast. Mit diesen Akzeptanzkriterien beschäftigen wir uns gleich.\n\nWie du aus dieser Übersicht erkennen kannst, beziehen sich die über das 3C-Modell hinausgehenden Punkte von INVEST vor allem auf die Arbeit in Scrum. Aus diesem Grund ergibt INVEST Sinn für alle Scrum-Master, die sich intensiver mit User Stories auseinandersetzen wollen.\n\n## Scrum User Story: Aufbau und Beispiel\n\nGehen wir nun zu dem Punkt über, der in nahezu allen Artikeln und Übersichten zum Thema fehlt: Einem praktischen Beispiel für eine User Story in Scrum und wie du sie so schreiben kannst, dass sie zu einem wünschenswerten Ergebnis führt. Wir werden in diesem Artikel nicht näher auf ein Epic-Beispiel (lange User Story) eingehen. Denn auch, wenn die Zyklen sich hier über mehrere Sprints erstrecken, bleibt das Grundprinzip identisch. \n\nNehmen wir an, du hast aus Gesprächen mit Kund(innen) ermittelt, dass diese nicht zufrieden mit der Updatefunktion deines Produkts sind. Immer wieder werden sie während der Arbeit von Update-Meldungen gestört und die Durchführung der Updates beeinträchtigt zudem die Rechenkapazität. Sie würden gerne komfortabel bestimmen können, wann Updates installiert werden sollen oder sich gegen bestimmte Updates entscheiden.  \n\nWie verläuft nun der Weg von diesem ersten Wunsch der Kund(innen) hin zum neuen Feature, beziehungsweise zum Befriedigen des Wunsches der Kund(innen)? \n\n### User-Story-Beispiel Schritt 1: 5 Whys\n\nDas Konzept der User Story fußt auf der Schöpfung von Nutzen. Deshalb sollte das genaue Definieren dieses Nutzens höchste Priorität genießen. Wenn du den Nutzen nicht richtig erfasst, wird es deinem Team auch nicht gelingen, die zentrale emotionale Komponente des Prozesses \\- die „Story” \\- zufriedenstellend umzusetzen. \n\nHilfe bietet hier die 5-Why-Technik. \n\nFange damit an, was du erreichen möchtest: ein Update-Prozess, der von Kund(innen) nicht mehr als Belästigung empfunden wird, sondern als Unterstützung und Optimierung. Anschließend stelle dir selbst die Aufgabe, fünf gute Gründe zu finden, warum diese Story einen Nutzen stiftet.\n\nFür diese User Story wäre zum Beispiel aus der Sicht von Kund(innen) denkbar:\n\n* Damit ich bei voller Rechenleistung weiterarbeiten kann.  \n* Damit ich zunächst sicherstellen kann, dass genug Speicherplatz zur Verfügung steht.   \n* Damit ich die Entscheidung über Updates dann treffe, wenn ich mich damit auch wirklich auseinandersetzen kann und möchte.   \n* Damit ich gezielt nur die Updates auswählen kann, die ich brauche.   \n* Damit ich weiß, welche neuen Updates installiert wurden und immer auf dem neuesten Stand bleibe.\n\nJe mehr Details du hier erarbeiten kannst, umso deutlicher wird es für das Team als Ganzes (und manchmal sogar für die Kund(innen) selbst), worin genau die „Story” besteht.\n\n### User-Story-Beispiel Schritt 2: Connextra-Template\n\nWir haben es bereits erwähnt: User Stories sind eher wie Haikus als Geschichten. Und genau wie Haikus hilft es, bei der Formulierung einer User Story einem mehr oder weniger strengen Format zu folgen.   \n\nRachel Davis von der Firma Connextra stellte fest, dass viele Mitarbeiter(innen) mit dem Schreiben einer guten User Story überfordert waren. Die inhärente Freiheit des Konzepts erwies sich als ein Problem. Wie so oft bot eine gezielte Limitierung der Optionen eine passende Lösung.\n\nDavis schlug den folgenden User-Story-Aufbau vor:\n\n*Als \\[Rolle\\] möchte ich \\[Story\\], damit ich \\[Grund\\]*\n\nDas bedeutet in unserem User-Story-Beispiel:\n\n*Als Kundin möchte ich in Ruhe mit der Software arbeiten können, ohne von Updates unterbrochen zu werden. Ich möchte aber auch immer darüber informiert sein, was für Updates genau neu installiert werden und mich gegebenenfalls gegen sie entscheiden. Der Grund ist, dass ich es vorziehe, immer die Kontrolle über die Software zu behalten und immer auf dem neuesten Stand zu sein.* \n\nDies ist leider nicht, wie das Template in der Praxis üblicherweise benutzt wird. Oftmals setzen viele Teams statt einer emotional gelebten „Story” einfach eine rein technische Funktionalität ein. \n\nDabei geht genau der wichtigste Teil verloren. Bei User Stories geht es um eine alternative Möglichkeit, mit dem Produkt zu arbeiten \\- nicht um eine neue Methode, die Arbeit aufzuteilen. Wenn du so vorgehst, nutzt du zwar formal einen passenden User-Story-Aufbau, arbeitest aber mit alten Methoden. \n\nDas Connextra-Template verführt dazu, zu Mustern zurückzukehren, die du hinter dir lassen solltest. Wer es aber in seiner ursprünglichen Form verwendet, kann sehr großen Nutzen daraus ziehen. \n\n### User-Story-Beispiel Schritt 3: Akzeptanzkriterien\n\nJede gute Geschichte hat einen Anfang und ein Ende. Ohne das letzte Kapitel und ein zufriedenstellendes Finale wird selbst ein spannender Anfang und ein packender Mittelteil mit einer Enttäuschung enden. \n\nAus diesem Grund solltest du unbedingt gleich zu Anfang Akzeptanzkriterien für deine User Story festlegen. Diese setzen einen Rahmen dafür, wann eine User Story als beendet („done”) betrachtet werden kann. Zusammen mit dem vierten Schritt, dem Abschätzen, verankern sie User Stories fest im agilen Framework. \n\nDie Agile Scrum Group meint [zum Thema Akzeptanzkriterien](https://agilescrumgroup.de/akzeptanzkriterien/): \n\n*„Akzeptanzkriterien geben einer User Story Details, sodass Sie wissen, wann eine User Story fertig ist. Akzeptanzkriterien entstehen aus Gesprächen zwischen dem Product Owner, den Stakeholdern und den Entwicklern, wenn Sie nach dem Scrum Framework arbeiten.”*\n\nEs empfiehlt sich bei dem Festlegen der Akzeptanzkriterien folgendes zu beachten:\n\n* 4-8 Akzeptanzkriterien pro User Story erscheinen den meisten Experten als eine sinnvolle Menge.  \n* Suche nach objektiven Kriterien, insofern dies innerhalb der subjektiven Grenzen einer User Story möglich ist. Umso präziser sich feststellen lässt, ob ein Kriterium erfüllt wurde, um so besser.  \n* Entscheidend bei User Storys ist die „Story”, die sich Kund(innen) wünschen, nicht, wie diese umgesetzt wird oder welche Features sie beinhaltet. Lege deshalb genau fest, „was” du erreichen möchtest \\- und überlasse das „wie” der Teamarbeit.\n\nWie sehen Akzeptanzkriterien in der Praxis aus? Es gibt hier verschiedene Ansätze. Das beste Beispiel ist das sogenannte Gherkin-Format.\n\n### Das Gherkin-Format\n\nEbenso wie das Connextra-Template für den User-Story-Aufbau packt das Gherkin-Format die Formulierung von Akzeptanzkriterien für diese User Stories in ein fixes Format. Das erleichtert die Arbeit ungemein. \n\nDas Format sieht folgendermaßen aus:\n\n*Gegeben \\\u003CVoraussetzung\\>*  \n*wenn \\\u003CEreignis\\>*  \n*dann \\\u003CErgebnis\\>*\n\nSo kann für viele potenzielle Fälle ein Szenario entworfen werden. Ein hervorragendes User-Story-Beispiel findet sich in einem ausführlichen [PDF-Leitfaden des Bundesinnenministeriums](https://www.digitale-verwaltung.de/SharedDocs/downloads/Webs/DV/DE/servicehandbuch.pdf?__blob=publicationFile&v=3): Hier möchten Anwender(innen) ein „Passbild hochladen\", damit ihre „Antragsdaten vollständig sind”: \n\n*„Szenario: Bilddatei hochladen*  \n*Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,*  \n*Wenn der Nutzende eine ausgewählte Datei hochlädt und es sich um eine Bilddatei handelt,*  \n*dann wird sie übernommen und dem Nutzenden als hochgeladen angezeigt und die Biometrie-Prüfung*  \n*wird angestoßen.*\n\n*Szenario: Falsches Format hochladen*  \n*Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,*  \n*Wenn der Nutzende eine ausgewählte Datei hochlädt und es keine Bilddatei ist,*  \n*dann wird sie nicht übernommen und es wird ein Fehler angezeigt.”*\n\n## Agile Schätzung\n\nDie Welt der Softwareentwicklung ist nicht linear. Aufgaben werden nicht bequem der Reihe nach abgearbeitet. In der Regel gilt es, mit einer limitierten Menge an Arbeitszeit die von dir und deinem Team definierten User Stories gleichzeitig oder zeitversetzt umzusetzen. Das stellt die Planung vor anspruchsvolle Aufgaben. \n\nDas Ziel der User-Story-Organisation besteht darin, zu verstehen, wie viel Aufwand jede einzelne Story erfordert. Je genauer du dies weißt, desto genauer wirst du in der Lage sein, die zu erledigenden Aufgaben auf die bestehenden Kapazitäten zu verteilen. Je gröber dein Verständnis, umso höher das Risiko, dass User Stories gar nicht oder nicht in der erforderlichen Qualität erledigt werden. \n\nDieses Risiko kann das Überleben des Unternehmens gefährden. Aus diesem Grund nimmt die agile Schätzung \\- also die Schätzung des Aufwands deiner User Stories \\- eine zentrale Rolle ein. \n\nDu könntest nun meinen, dass es dafür eine einfache Lösung gibt: Du weist schlicht jeder User Story eine geschätzte Bearbeitungsdauer zu und verteilst die Arbeit anschließend so, dass sie innerhalb der geplanten Sprints erledigt werden kann. \n\nIn der Praxis haben sich andere Ansätze als effektiver erwiesen. \n\n## Story Points: Aufwand vs. Arbeitszeit\n\nZeit ist relativ. Was für das Universum als Ganzes gilt, hat auch in der Softwareentwicklung Bestand. Arbeitszeit präziseeinzuschätzen hängt von einer Vielzahl von Faktoren ab und kann sich sogar für erfahrene Personalplaner als äußerst schwierig erweisen. Gerade bei schnellen und zugleich zeitintensiven Branchen können selbst kleine Abweichungen massive Folgewirkungen haben und den gesamten Zeitplan durcheinander bringen.\n\nAus unserer Sicht sind zwei Punkte verantwortlich dafür, dass Zeit in der Planung kein idealer Bewertungsmaßstab ist:\n\n* Die Komplexitäten verschiedener User Stories können sehr weit auseinanderklaffen. Das bedeutet nicht unbedingt, dass komplexe Aufgaben mehr Zeit benötigen. Möglicherweise erfordern sie lediglich, dass sich erfahrene, hochqualifizierte oder auf dieses Thema geschulte Teammitglieder um ihre Bearbeitung kümmern müssen.   \n* Der Aufwand einer Aufgabe hängt ebenfalls von sehr unterschiedlichen Faktoren ab. Manche User Stories müssen ausgiebig im Team diskutiert werden, andere erfordern viel Zeit, um realisiert zu werden, obwohl sie keineswegs „schwierig” sind. Andere können nur in ständiger Rücksprache mit Kund(innen) umgesetzt werden. All das beeinflusst die Arbeitszeit, teilweise auf eine Art und Weise, die nur schwer vorherzusehen ist.\n\nAus diesem Grund hat sich eine andere Einheit zur Einschätzung herauskristallisiert: Story Points. Dabei handelt es sich um ein Maß, das den Aufwand einer User Story auf eine nicht direkt mit der erforderlichen Zeit verbundene Weise zu bestimmen versucht: Je mehr Story Points eine User Story erfordert, umso höher der Aufwand. \n\n## Story Points in der Schätzung\n\nStory Points sind Aufwandspunkte. Sie können in erfahrenen Teams zu sehr genauen Schätzungen führen. Trotzdem stehen sie niemals für absolute Werte und sind im Gesamtkontext aller aktuell anstehenden User Storys zu sehen. \n\nDie beliebtesten Konzepte basieren nahezu alle grob auf der Fibonacci-Folge. In dieser Sequenz entsteht die jeweils nächste Zahl aus der Summe der beiden vorangegangenen. Die ersten 13 Einträge dieser Folge sind demzufolge:\n\n0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144\n\nIn der User-Story-Planung werden diese Zahlen ein wenig geglättet. So entsteht zum Beispiel die folgende Kette:\n\n0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100\n\nWir haben auch Konzepte gefunden, in der zwischen 0 und 1 noch ein 0,5 eingefügt und statt einer 50 eine 40 gewählt wurde. Das aber sind Feinheiten, die das Konzept als solches nicht wesentlich  tangieren. \n\nAnschließend weist das Team den User Stories einen dieser Zahlenwerte zu. Daraus entsteht eine Reihenfolge der Stories nach Aufwand. Die folgenden Methoden zur Zuweisung von Story Points sind üblich:\n\n### Planning Poker\n\nBeim Planning Poker weisen die Teammitglieder jeder User Story auf einer verdeckt gehaltenen Karte, je nach dem geschätzten Aufwand, Story Points zwischen 0 und 100 zu. Anschließend werden die Karten offen auf den Tisch gelegt und nach Zahl der Story Points auf Stapel verteilt. \n\nDer Stapel mit den meisten Karten ist der „Sieger” und die User Story erhält die damit verbundene Zahl an Punkten, beispielsweise 20\\. \n\nDas Planning Poker ist eine elegante Methode der Aufwandsschätzung, die letzten Endes aber natürlich einer simplen Abstimmung gleichkommt. \n\nDas Konzept der Planung durch T-Shirtgrößen, was sich ebenfalls oft in einschlägigen Artikeln findet, ist aus unserer Sicht keine eigenständige Methode, sondern eine modifizierte Variante des Pokers. Gleiches gilt für das „Bucket System” (ein Eimer, in den die Karten geschmissen werden) oder das „Dot Voting” (mit kleinen Klebepunkten). \n\n### Affinity Mapping\n\nDas Affinity Mapping ist eine der wenigen Alternativen zum Planning Poker. Es besteht aus zwei Phasen:\n\n1. Zunächst gruppieren alle Teammitglieder gemeinschaftlich die Aufgaben, die einen ähnlichen Komplexitätsgrad aufweisen. Die Einteilung erfolgt durch Diskussion innerhalb des Teams.  \n2. Anschließend werden den User Stories innerhalb der Gruppe, entweder durch weitere Gespräche oder Methoden wie Planning Poker, Story Points zugewiesen. So entsteht eine Reihenfolge, bei der die aufwandsintensiven Stories ganz oben, die vermutlich weniger anspruchsvollen weiter unten stehen. \n\n## Wer schreibt User Stories?\n\nIn der Vergangenheit wurde die Planung und Aufgabenzuweisung üblicherweise von einer zentralen Instanz oder einer verantwortlichen Person vorgenommen. Bis heute hat sich diese Arbeitsverteilung in vielen Unternehmen gehalten. Sogar Scrum, ein teamorientiertes Konzept innerhalb der teamorientierten Agile-Management-Philosophie, arbeitet bis heute mit einem Scrum-Master.\n\nDas Schreiben von User Stories unterscheidet sich hier deutlich. Zwar wird die erste Version der User Story oftmals noch von einem erfahrenen Teammitglied verfasst, beispielsweise nach einem ausführlichen Austausch mit Kund(innen). Hier schließt sich direkt die Phase der „Verhandlungen” an, also des Austauschs zwischen allen Beteiligten. \n\nSomit werden User Stories zwar noch sehr oft von Einzelnen vorbereitet, geschrieben werden sie aber von der Gruppe. \n\nGenau das macht sie auch zu einem so großartigen Tool. Denn wie jeder Autor weiß, ist eine Geschichte nur dann gut, wenn man sich mit ihr identifizieren kann. \n\n*Willst Du mehr dazu wissen, wie Deine persönliche User Story in Scrum zum Erfolg wird? Dann empfehlen wir Dir unseren Leitfaden zur [Verwendung von Scrum in GitLab](https://docs.gitlab.com/ee/tutorials/scrum_events/). Oder informiere Dich dazu, warum GitLab ganz allgemein die führende [DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/) ist.*",[722],"GitLab Germany Team","2025-05-20","So schreibst du eine User Story in Scrum",[25],"Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":728,"featured":13,"template":14},"how-to-write-a-user-story-in-scrum",{"promotions":730},[731,745,757],{"id":732,"categories":733,"header":735,"text":736,"button":737,"image":742},"ai-modernization",[734],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":738,"config":739},"Get your AI maturity score",{"href":740,"dataGaName":741,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":743},{"src":744},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":746,"categories":747,"header":749,"text":736,"button":750,"image":754},"devops-modernization",[696,748],"devsecops","Are you just managing tools or shipping innovation?",{"text":751,"config":752},"Get your DevOps maturity score",{"href":753,"dataGaName":741,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":755},{"src":756},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":758,"categories":759,"header":761,"text":736,"button":762,"image":766},"security-modernization",[760],"security","Are you trading speed for security?",{"text":763,"config":764},"Get your security maturity score",{"href":765,"dataGaName":741,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":767},{"src":768},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":770,"blurb":771,"button":772,"secondaryButton":777},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":773,"config":774},"Kostenlosen Test starten",{"href":775,"dataGaName":52,"dataGaLocation":776},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":54,"config":778},{"href":56,"dataGaName":57,"dataGaLocation":776},1772652043226]