[{"data":1,"prerenderedAt":764},["ShallowReactive",2],{"/de-de/blog/what-is-kanban":3,"navigation-de-de":35,"banner-de-de":439,"footer-de-de":449,"blog-post-authors-de-de-GitLab Germany Team":654,"blog-related-posts-de-de-what-is-kanban":669,"assessment-promotions-de-de":714,"next-steps-de-de":754},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":24,"isFeatured":12,"meta":25,"navigation":26,"path":27,"publishedDate":20,"seo":28,"stem":32,"tagSlugs":33,"__hash__":34},"blogPosts/de-de/blog/what-is-kanban.yml","What Is Kanban",[7],"gitlab-germany-team",null,"agile-planning",{"slug":11,"featured":12,"template":13},"what-is-kanban",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?","Kanban sorgt für einen besseren Flow, senkt Kosten und optimiert deinen DevOps-Prozess. Erfahre, wie es mit der Umsetzung klappt.",[18],"GitLab Germany Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663044/Blog/Hero%20Images/kanban.jpg","2024-09-12","# Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?\n\n## Inhalt - Was ist Kanban?\n\n- [Was ist Kanban](#was-ist-kanban%3F)\n- [Was ist ein Kanban-Board?](#was-ist-ein-kanban-board%3F)\n- [Wie funktioniert das Kanban-System?](#wie-funktioniert-das-kanban-system%3F)\n- [Beispiele für Kanban-Boards](#beispiele-für-kanban-boards)\n- [Die Kanban-Methode als Veränderungsmanagement und Verbesserungsmanagement](#die-kanban-methode-als-veränderungsmanagement-und-verbesserungsmanagement)\n- [Worum geht es bei der Kanban-Methode?](#worum-geht-es-bei-der-kanban-methode%3F)\n- [Grundsätze: Wie funktioniert das Kanban-System?](#grundsätze-wie-funktioniert-das-kanban-system%3F)\n- [Kanban: Agile oder Lean?](#kanban-agile-oder-lean%3F)\n- [Scrum vs. Kanban: Übersicht](#scrum-vs-kanban-übersicht)\n- [Scrum vs. Kanban: Unterschiede](#scrum-vs-kanban-unterschiede)\n- [Wann funktioniert Kanban nicht?](#wann-funktioniert-kanban-nicht%3F)\n- [Wie gliedere ich mein Kanban-Board?](#wie-gliedere-ich-mein-kanban-board%3F)\n- [GitLab-Issue-Boards und Kanban Projekt-Management](#gitlab-issue-boards-und-kanban-projekt-management)\n- [Wie nutze ich GitLab-Issue-Boards für mein Kanban?](#wie-nutze-ich-gitlab-issue-boards-für-mein-kanban%3F)\n\n## Was ist Kanban?\nDie frühen Ursprünge von Kanban gehen auf das 17. Jahrhundert zurück. In seiner heutigen Bedeutung allerdings kam der Begriff erst Mitte des 20. Jahrhunderts zu weltweiter Bekanntheit. Seitdem wächst die Kanban-Anhängerschaft kontinuierlich. Für David J. Anderson stand schon 2013 fest, dass es “das nächste große Ding auf dem Softwareprozess-Markt” sein wird.\n\nDas mag nach einer Übertreibung klingen, aber Anderson wusste, wovon er spricht. Schließlich ist er einer der Pioniere, die Kanban auf den Softwarebereich übertragen haben.\n\nAuch dein Unternehmen wird in der Regel von Kanban profitieren. Das Gute daran: das Kanban-Verfahren verlangt nicht, deinen aktuellen Managementstil oder alle deine Prozesse komplett auf den Kopf zu stellen. Vielmehr fügt es sich nahtlos in die unterschiedlichsten Unternehmensstrukturen ein.\n\n[GitLab](https://about.gitlab.com/de-de/) bietet mit seinen Issue-Boards die Möglichkeit, den Software-Entwicklungsprozess mit Kanban zu optimieren. Bevor wir allerdings näher darauf eingehen, sehen wir uns an, worum es bei Kanban ganz genau geht.\n\n## Was ist ein Kanban-Board?\nHeute assoziieren wir mit dem Wort “Kanban” vor allem die Darstellung der Arbeitsschritte in einem sogenannten “Board”.\n\nEin Kanban-Board ist eine visuelle Repräsentation der anfallenden Aufgaben eines Projekts in einer klar strukturierten zeitlichen Abfolge. Aufgaben werden als Kärtchen in diesem Board dargestellt. So kannst du anhand dieser Übersicht erkennen, in welchem Stadium sich ein Task befindet. Egal, ob der Task beispielsweise kurz vor der Vollendung steht oder sich noch in Bearbeitung befindet.\n\nAuch zeigt ein Board alle Aufgaben an, die noch nicht bearbeitet wurden, aber noch anstehen. So erfasst du auf einen einzigen Blick den Stand der zukünftigen Arbeitslast. Daraus ergeben sich konkrete Anforderungen an deine Planung.\n\n## Wie funktioniert das Kanban-System?\nKanban ist eine Methode der [agilen Planung](https://about.gitlab.com/de-de/solutions/agile-delivery/). Auf einem Kanban-Board wandern die Aufgabenkärtchen von links, dem Ort der To-do-Liste, nach rechts, in Richtung des fertigen Produkts. Sobald die auf einer Karte vorgeschriebene Aufgabe bearbeitet wurde, verschwindet sie vom Board und macht den Weg frei für neue Karten.\n\nIn seiner einfachsten Form hat ein Kanban-Board somit drei Spalten: “Zu erledigen”, “In Bearbeitung” und “Erledigt”.\n\n## Beispiele für Kanban-Boards\nGrundsätzlich gibt es zwei verschiedene Varianten eines Kanban-Boards: Physische und virtuelle.\nPhysische Kanban-Boards waren in der Frühphase des Konzepts der Standard. Sie bestehen im Wesentlichen aus einem Whiteboard oder einer Pinnwand, die, wie oben beschrieben, in Spalten aufgeteilt wird und an denen Karteikarten oder auch größere Papierblätter befestigt werden.\n\nSobald sich eine Änderung im Prozess ergibt, passen Mitarbeiter:innen die Karte auf dem Board an und machen die Veränderung damit für das gesamte Team sichtbar.\n\nIn modernen visuellen Boards findet die Darstellung innerhalb einer Softwareumgebung statt. GitLab zum Beispiel bietet im Rahmen seiner Issue-Boards eine Funktionalität an, Kanban in DevOps-Prozesse einzubinden.\n\nInteressanterweise finden physische Boards auch heute noch Anwendung und daher empfehlen viele Expert(inn)en und Kanban-Coaches Unternehmen, bei der Umsetzung von Kanban mit einem solchen materiellen Brett zu beginnen. So schreibt das Fachmagazin IT-Agile in einem groß angelegten Spezial:\n\n*“Physische Boards machen vieles einfacher und transparenter. Elektronische Tools führen oft zusätzliche Komplexität ein, die von den eigentlichen Problemen ablenkt.”*\n\n## Die Kanban-Methode als Veränderungsmanagement und Verbesserungsmanagement\nMit Kanban zu arbeiten bedeutet, ein Kanban-Board zu verwenden und es fortlaufend zu aktualisieren. Dennoch entwickelte Ohno die Grundzüge von Kanban interessanterweise ohne ein Board. Das bedeutet:\n\nDie Anwesenheit eines Boards deutet zwar in der Regel auf einen Kanban-Ansatz hin. Aber das Kanban-Verfahren ist, was die Theorie betrifft, auch ohne Board denkbar.\n\nOhno wollte Toyotas Organisation nicht radikal verändern, sondern sie vielmehr sanft und unter enger Mitarbeit aller Beteiligten erneuern. Dies spiegelt sich wider in einem Zitat von David J. Anderson [David J. Anderson](https://se-radio.net/2010/02/episode-156-kanban-with-david-anderson/):\n\n*“Kanban ist keine Ingenieursmethode oder Management-Methode. Es ist eine Technik, mit Veränderungen umzugehen. Es geht darum, Veränderungen zu provozieren und eine Kultur der ständigen Verbesserung zu erreichen.”*\n\nDiese Auffassung erklärt auch, warum Kanban mit einer Vielzahl verschiedener Philosophien kombiniert werden kann: Es diktiert nicht so sehr, wie ein Unternehmen geführt werden sollen. Es legt sich vielmehr über bereits bestehende Abläufe und macht sichtbar, wo Optimierungen möglich oder sogar erforderlich sind. \n\n## Worum geht es bei der Kanban-Methode?\nWer einmal in einer auf Kanban ausgerichteten Organisation mitgewirkt hat, wird den Flow-Charakter, der auf dem Board visualisiert wird, bemerkt haben: Teams benötigen hier kaum ein Einwirken von oben, organisieren sich innerhalb vorgegebener Einschränkungen selbst und kommen eigenständig zu Ergebnissen und Lösungen. \n\nDiese Optimierung der Flow-Effizienz war auch genau der Punkt, der Taiichi Ohno am Herzen lag, als er für Toyota nach dem Zweiten Weltkrieg sein System entwickelte, um der japanischen Automobilindustrie den Anschluss an die westlichen Hersteller zu ermöglichen.\n\nDamals wurden Prozesse oftmals zentral exakt vorgeplant, gerieten aber immer wieder aufgrund praktischer Probleme ins Stocken. Bei umfangreicheren Anpassungen mussten die Computer umprogrammiert werden, was bis zu zwei Wochen in Anspruch nehmen konnte.\n\nKanban war eine Methode, Prozesse am Laufen zu halten und “Work in Progress”, also unfertige Zwischenprodukte auf ein Minimum zu beschränken.\n\n## Grundsätze: Wie funktioniert das Kanban-System?\nKanban sorgt für Ordnung, ist aber ungemein flexibel. Es hat einen sehr einfachen Aufbau, kann aber auch in großen, komplexen Unternehmen verwendet werden.\n\nTrotzdem hat es nicht an Versuchen gemangelt, Kanban ein wenig genauer zu gliedern. So gibt es, je nach Autor(in), 6 „Kanban-Praktiken“, 4 „Kanban-Prinzipien“, 3 „Kanban-Agenden“ und 2 „Kanban-Regeln“.\n\nMan braucht gewiss nicht alle zu kennen, um Kanban erfolgreich anwenden zu können. Die drei wichtigsten grundlegenden Prinzipien aus den genannten Grundsätzen lauten:\n\n**- Visualisiere die Arbeit. Der Blick aus der Vogelperspektive lässt Strukturen erkennen. Er zeigt das, was Taiichi Ohno als “Verschwendung” bezeichnete, die im laufenden Betrieb, also bei der Arbeit, nicht erkennbar ist. Ohno bezog sich darauf mit seiner Anweisung, “das Verborgene sichtbar zu machen”. Erst die Visualisierung auf einem Kanban-Board sorgt für die Automatisierung der Prozesse, welche zu einem verbesserten Flow und erhöhter Effizienz führt.**\n\n**- Reduziere unfertige Zwischenprodukte auf ein Minimum. Bei Toyota in den 40ern bedeutete dies, erst dann mit der Arbeit an einem neuen Wagen zu beginnen, sobald eine bestimmte Anzahl von ihnen komplett abgeschlossen und bereit für den Verkauf waren. Zwischenprodukte halten den Flow auf und sorgen oftmals für hohe Kosten.**\n\n**- Bevor du alternative Konzepte ausprobierst oder Produkte änderst, fange mit deiner aktuellen Praxis an. Erst sobald du diese verbessert hast, wende dich neuen Ufern zu.**\n\n## Kanban: Agile oder Lean?\nHeute wird die Kanban-Methode oft durch die Linse der agilen Entwicklung betrachtet. Das ist verständlich, denn tatsächlich war es das agile Manifest aus dem Jahr 2001, das den Weg für den breiten Einsatz von Kanban in DevOps bereitete.\n\nDoch ist Kanban bereits weitaus früher entstanden, weit früher auch als Konzepte wie das Wasserfallmodell, welches heute bereits als überholt gilt. Und in den Prinzipien und Regeln die Taiichi Ohno für Toyota aufstellte, spiegeln sich auch viele Grundsätze des Lean-Managements wider.\n\nSo ist es sicherlich richtig, Kanban als Teil beider Ansätze zu sehen. Der Just-in-Time-Ansatz rückt Kanban etwas näher an die agile Methodologie, der Grundsatz der sorgsamen Ressourcen-Nutzung eher in Richtung der Konzepte der Lean-Managements.\n\nMan könnte auch sagen, dass Kanban einen Ausgleich zwischen den beiden Konzepten herstellt. Während Lean nämlich Perfektion und vollständige Informationen anstrebt, ist es bei Agile wichtiger, Dinge auch bei unvollständiger Datenlage zu tun und entstehende Schwierigkeiten durch Improvisation und Lösungen aus der Praxis heraus zu korrigieren.\n\nKanban erlaubt es, die Zwischenräume zwischen diesen Polen auszuloten und dabei zu individuellen Ansätzen zu gelangen.\n\n## Scrum vs. Kanban: Übersicht\nVielleicht fragst du dich nach dem, was du bis jetzt gelesen hast, ob eher Kanban oder Scrum für dein Unternehmen die richtige Wahl ist.\n\nDiese Frage ist aber letzten Endes in dieser Form nicht zielführend. Denn sowohl Scrum als auch die Kanban-Methode schließen sich nicht gegenseitig aus und werden in der Praxis oft miteinander kombiniert.\n\nBei Scrum handelt es sich um einen Projektmanagement-Ansatz, bei dem Wissen (in der Form von Daten aus der Planung und dem Prozess) genutzt wird, um iterativ und über möglichst viele testbare Produkte den Kundennutzen zu maximieren.\n\nVergleichen wir Scrum vs Kanban, fällt schnell auf, dass die beiden nicht deckungsgleich sind. Die vier Prinzipien von Scrum sind „Transparenz“, „Inspektion“, „Adaptation“ und “Vertrauen”. Dem stehen die von David J. Anderson vorgegebenen Kanban-Werte der „Transparenz“, „Balance“ (Vermeiden von Ungleichgewichten) und „Kollaboration“ gegenüber.\n\nDaraus wird direkt ersichtlich, dass Scrum mehr Wert auf Daten und Prozesse legt, während Kanban in erster Linie auf menschliche Zusammenarbeit setzt. Dennoch können die beiden Ansätze einander hervorragend ergänzen.\n\n## Scrum vs. Kanban: Unterschiede\nWas ist der Unterschied zwischen Scrum und Kanban? Ein Kernunterschied besteht darin, dass du bei Kanban Prozesse tendenziell nicht terminierst. Der Flow soll zwar optimiert werden, doch die Fließgeschwindigkeit ergibt sich aus der Arbeitspraxis. Fixe zweiwöchige Sprints und ein eindeutiges Enddatum laufen dieser Idee zuwider.\n\nAuch verlangt Scrum zwangsweise, dass Abläufe ein festes Raster haben. Sprints müssen nicht zwangsläufig einem Zwei-Wochen-Rhythmus folgen. Aber eine Vorgabe regelmäßiger Ziele ist sehr wohl erforderlich. Die Treffen dienen dabei sowohl dem Informationsaustausch im Team, als auch dazu, den Grad der Zielerreichung stets wieder aufs Neue zu determinieren.\n\nDennoch ist ein “Scrumban” möglich. Denn auch ein Scrum-Prozess lässt sich über ein Kanban-Board recht bequem abbilden. Werden die Spalten passend definiert, ist es sogar kaum von “konventionellen” Board zu unterscheiden.\n\nMit seiner Betonung empirischer Daten füttert Scrum das Kanban-Board mit wertvollem Feedback, welches hilft, den Flow weiter zu optimieren. Und dank seiner Reduzierung von Engpässen und Work in Progress sorgt Kanban für eine Organisation, in der Scrum optimal umgesetzt werden kann.\n\nScrumban erweist sich in der Praxis oftmals als schwierig. Aber das Gleiche gilt auch für Scrum, das sich durchaus nicht immer intuitiv in die meisten Organisationsstrukturen einfügt. Letzten Endes kommt alles auf die Umsetzung an.\n\n## Wann funktioniert Kanban nicht?\nWenn du darüber nachdenkst, was das Kanban-System ist, ist es leicht ersichtlich, dass es in jedem Unternehmen Anwendung finden kann. Aber nicht jedes Unternehmen ist bereit für Kanban.\n\nIm direkten Vergleich zu Scrum fällt die Realisierung aber sicherlich weitaus leichter aus. Hier sind drei typische Gründe, warum die Implementierung von Kanban eventuell dennoch nicht funktioniert:\n\n**- Das Kanban-Projektmanagement ist für selbstorganisierende Teams entwickelt worden.** Das bedeutet, dass die Mitarbeiter(innen) im Rahmen von Vorgaben operieren, die ihnen gestellt werden. Wenn diese Vorgaben nicht ausreichend genau ausfallen oder sogar unerwünschte Anreize vorgeben, kann sich Kanban nicht entfalten.\n\n**- Die Prozesse, die über die Kanban-Methode laufen, sollten immer wieder hinterfragt werden.** Das gelingt beispielsweise mit einem externen Kanban-Coach, der/die mit seinen/ihren Impulsen Umsetzungsschwierigkeiten minimiert. Fehlt eine solche Bezugsperson, kommt es unter Umständen zu Kompetenzfragen, Zuordnungsproblemen oder einem Stocken des Flusses.\n\n**- Softwareentwicklung ist sehr dynamisch und die Bedingungen ändern sich nahezu täglich.** In einem solchen Umfeld wird die Aktualisierung des Kanban-Boards zu einer Aufgabe, die eine Menge Ressourcen verlangt. Rob Williams hat dies folgendermaßen auf den Punkt gebracht: “Das größte Problem mit Kanban besteht darin, dass es für eine Welt entworfen wurde, in der Produkte nur ein einziges Mal den Prozess durchlaufen, wie beispielsweise bei einem Automobilhersteller. In der Software-Branche ist dies nahezu niemals der Fall.”\n\nGelegentlich sind die Erwartungen an die Kanban-Methode zu hoch. Wenn sich keine schnellen Erfolge in der Form von Kosteneinsparungen, höherer Innovation oder gesteigerten Umsätzen einstellen, liegt oft die Versuchung nahe, zu alten Gewohnheiten zurückzukehren.\n\n## Wie gliedere ich mein Kanban-Board?\nWie bereits erwähnt, besteht das klassische Kanban-Board aus nur drei Spalten: „To-do“, „In Bearbeitung“ und „Erledigt“.\n\nAllerdings erlauben es alle gängigen Kanban-Boards, darunter auch die Issue-Boards von GitLab, die Spalten nicht nur anders zu benennen, sondern auch noch zusätzliche hinzuzufügen.\n\nFrage dich dazu Folgendes:\n\n### Ist das Hauptkriterium der zeitliche Ablauf?\nDann bist du mit einem klassischen Kanban-Board bestens beraten.\n\nFür eine genauere Analyse des Status Quo kannst du diese Spalten nun genauer unterteilen. So ist es denkbar, zu bearbeitende Tasks danach zu gliedern, welche bereits begonnen wurden, aber aktuell nicht umgesetzt werden können (beispielsweise aufgrund von Lieferengpässen).\n\nDu kannst das Board ebenfalls um eine Spalte mit freiem Brainstorming ergänzen. Nur die besten Ansätze werden in den To-do-Teil übernommen. \n\n### Arbeitest du auf eine Reihe von Events hin?\nDann hast du zwei Optionen. Lege entweder für jedes Event ein eigenes Board an.\n\nOder, wenn die Events eng miteinander verbunden sind, lege diese in ein geteiltes Board, in dem jedem Event eine eigene Spalte zugeteilt ist, die wiederum in verschiedene Unterspalten aufgeteilt ist.\n\nSo behältst du auch in der Gesamtplanung stets die Übersicht.\n\n### Liegt dein Schwerpunkt in der Softwareentwicklung?\nIn der Softwareentwicklung durchlaufen Produkte eine Reihe zusätzlicher Stadien. Hier kann es von Vorteil sein, diese festen Abläufe in Kanban abzubilden. Die Beraterin Danielle Berg nennt beispielsweise die folgenden  Spalten: \n\n- (Code-) **Review**\n\n- **Test** (in unterschiedlichen Abstufungen):\n\n- **On-Hold** (Projekte, die begonnen wurden, aber an denen aktuell nicht weitergearbeitet werden kann.)\n\nDie Spalte “Test” kann sogar noch weiter untergliedert werden in:\n\n**- interne Prüfung,**\n\n**- Prüfung beim/bei der Kunden(in),**\n\n**- akzeptiert vom/von der Kunden(in).**\n\nIn anderen Branchen können entsprechend Spalten wie “Konzept/Entwicklung” oder auch “Beschaffung” (entweder in der Form von Wartezeiten wegen Lieferengpässen oder, weil ein Produkt speziell angefertigt werden muss) sinnvoll sein.\n\n## GitLab-Issue-Boards und Kanban Projekt-Management\nGitLab wurde zwar nicht als Kanban-Tool konzipiert. Aber aufgrund der engen Verwandtschaft zwischen DevOps und der Kanban-Methode bestand zwischen ihnen stets eine Verbindung. Gerade in der Softwareentwicklung kommen Kanban-Boards hervorragend zur Geltung.\n\nUm von diesen Vorteilen auch in GitLab profitieren zu können, stehen dir unsere Issue-Boards zur Verfügung. Issue-Tracker ähneln in ihrem Aufbau Kanban-Boards, sind aber weniger auf den gesamten Workflow eines Projekts ausgerichtet, sondern zielen mehr auf die Lösung ganz konkreter Probleme und Bugs ab.\n\nDie Überschneidungen aber sind offensichtlich. Daher wurden die GitLab-Issue-Boards um Features wie Roadmap Building erweitert, um eine volle Kanban-Funktionalität zu bieten.\n\n## Wie nutze ich GitLab-Issue-Boards für mein Kanban?\nUm Kanban in GitLab zu nutzen, lege einfach in dem Issue-Tracker ein Board im Kanban-Stil an.\n\nDazu wählst du so viele Listen aus, wie du Spalten in deinem Kanban-Board wünschst. Das bedeutet in der einfachsten Variante die drei Spalten “To Do”, “In Bearbeitung” und “Erledigt”. Alternativ ist ein ebenfalls empfehlenswerter Aufbau die Vierteilung in “Backlog”, “In Bearbeitung”, “Wartet auf” und “Erledigt”.\n\nEinzelne “Issues” (Aufgaben) entsprechen nun den Karten in einem Kanban-System. Sie können von den Anwender(inne)n oder Teams, die mit der Bearbeitung beauftragt sind, aus dem Backlog in die Bearbeitung gezogen und nach Beendigung in die “Erledigt”-Liste abgelegt werden.\n\nDie Integration von Kanban in die GitLab-Issue-Boards wird ständig um neue Funktionen erweitert. So steht dieses Feature spezialisierten Kanban-Tools im Wesentlichen um nichts mehr nach.\n\nEntwickelt von Entwickler(innen) für Entwickler(innen) liegt sein großer Vorteil darin,  Development, Anforderungen, Dokumentation und CI/CD an einem Ort zu bündeln.\n\nAusführliche Informationen dazu findest du in unserem [GitLab-Handbuch](https://handbook.gitlab.com/handbook/marketing/project-management-guidelines/boards/).",[23],"agile","yml",{},true,"/de-de/blog/what-is-kanban",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":29,"ogSiteName":30,"ogType":31,"canonicalUrls":29},"https://about.gitlab.com/blog/what-is-kanban","https://about.gitlab.com","article","de-de/blog/what-is-kanban",[23],"eoHsfsKD63IZCR42nZUK2h8__K8FbS-4sDphbvQCFcU",{"data":36},{"logo":37,"freeTrial":42,"sales":47,"login":52,"items":57,"search":366,"minimal":401,"duo":419,"pricingDeployment":429},{"config":38},{"href":39,"dataGaName":40,"dataGaLocation":41},"/de-de/","gitlab logo","header",{"text":43,"config":44},"Kostenlose Testversion anfordern",{"href":45,"dataGaName":46,"dataGaLocation":41},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":48,"config":49},"Vertrieb kontaktieren",{"href":50,"dataGaName":51,"dataGaLocation":41},"/de-de/sales/","sales",{"text":53,"config":54},"Anmelden",{"href":55,"dataGaName":56,"dataGaLocation":41},"https://gitlab.com/users/sign_in/","sign in",[58,85,181,186,287,347],{"text":59,"config":60,"cards":62},"Plattform",{"dataNavLevelOne":61},"platform",[63,69,77],{"title":59,"description":64,"link":65},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":66,"config":67},"Erkunde unsere Plattform",{"href":68,"dataGaName":61,"dataGaLocation":41},"/de-de/platform/",{"title":70,"description":71,"link":72},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":73,"config":74},"Lerne GitLab Duo kennen",{"href":75,"dataGaName":76,"dataGaLocation":41},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":78,"description":79,"link":80},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":81,"config":82},"Mehr erfahren",{"href":83,"dataGaName":84,"dataGaLocation":41},"/de-de/why-gitlab/","why gitlab",{"text":86,"left":26,"config":87,"link":89,"lists":93,"footer":163},"Produkt",{"dataNavLevelOne":88},"solutions",{"text":90,"config":91},"Alle Lösungen anzeigen",{"href":92,"dataGaName":88,"dataGaLocation":41},"/de-de/solutions/",[94,119,141],{"title":95,"description":96,"link":97,"items":102},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":98},{"icon":99,"href":100,"dataGaName":101,"dataGaLocation":41},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[103,107,110,115],{"text":104,"config":105},"CI/CD",{"href":106,"dataGaLocation":41,"dataGaName":104},"/de-de/solutions/continuous-integration/",{"text":70,"config":108},{"href":75,"dataGaLocation":41,"dataGaName":109},"gitlab duo agent platform - product menu",{"text":111,"config":112},"Quellcodeverwaltung",{"href":113,"dataGaLocation":41,"dataGaName":114},"/de-de/solutions/source-code-management/","Source Code Management",{"text":116,"config":117},"Automatisierte Softwarebereitstellung",{"href":100,"dataGaLocation":41,"dataGaName":118},"Automated software delivery",{"title":120,"description":121,"link":122,"items":127},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":123},{"href":124,"dataGaName":125,"dataGaLocation":41,"icon":126},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[128,132,137],{"text":129,"config":130},"Application Security Testing",{"href":124,"dataGaName":131,"dataGaLocation":41},"Application security testing",{"text":133,"config":134},"Schutz der Software-Lieferkette",{"href":135,"dataGaLocation":41,"dataGaName":136},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":138,"config":139},"Software Compliance",{"href":140,"dataGaName":138,"dataGaLocation":41},"/de-de/solutions/software-compliance/",{"title":142,"link":143,"items":148},"Bewertung",{"config":144},{"icon":145,"href":146,"dataGaName":147,"dataGaLocation":41},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[149,153,158],{"text":150,"config":151},"Sichtbarkeit und Bewertung",{"href":146,"dataGaLocation":41,"dataGaName":152},"Visibility and Measurement",{"text":154,"config":155},"Wertstrommanagement",{"href":156,"dataGaLocation":41,"dataGaName":157},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":159,"config":160},"Analysen und Einblicke",{"href":161,"dataGaLocation":41,"dataGaName":162},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":164,"items":165},"GitLab für",[166,171,176],{"text":167,"config":168},"Enterprise",{"href":169,"dataGaLocation":41,"dataGaName":170},"/de-de/enterprise/","enterprise",{"text":172,"config":173},"Kleinunternehmen",{"href":174,"dataGaLocation":41,"dataGaName":175},"/de-de/small-business/","small business",{"text":177,"config":178},"den öffentlichen Sektor",{"href":179,"dataGaLocation":41,"dataGaName":180},"/de-de/solutions/public-sector/","public sector",{"text":182,"config":183},"Preise",{"href":184,"dataGaName":185,"dataGaLocation":41,"dataNavLevelOne":185},"/de-de/pricing/","pricing",{"text":187,"config":188,"link":190,"lists":194,"feature":274},"Ressourcen",{"dataNavLevelOne":189},"resources",{"text":191,"config":192},"Alle Ressourcen anzeigen",{"href":193,"dataGaName":189,"dataGaLocation":41},"/de-de/resources/",[195,228,246],{"title":196,"items":197},"Erste Schritte",[198,203,208,213,218,223],{"text":199,"config":200},"Installieren",{"href":201,"dataGaName":202,"dataGaLocation":41},"/de-de/install/","install",{"text":204,"config":205},"Kurzanleitungen",{"href":206,"dataGaName":207,"dataGaLocation":41},"/de-de/get-started/","quick setup checklists",{"text":209,"config":210},"Lernen",{"href":211,"dataGaLocation":41,"dataGaName":212},"https://university.gitlab.com/","learn",{"text":214,"config":215},"Produktdokumentation",{"href":216,"dataGaName":217,"dataGaLocation":41},"https://docs.gitlab.com/","product documentation",{"text":219,"config":220},"Best-Practice-Videos",{"href":221,"dataGaName":222,"dataGaLocation":41},"/de-de/getting-started-videos/","best practice videos",{"text":224,"config":225},"Integrationen",{"href":226,"dataGaName":227,"dataGaLocation":41},"/de-de/integrations/","integrations",{"title":229,"items":230},"Entdecken",[231,236,241],{"text":232,"config":233},"Kundenerfolge",{"href":234,"dataGaName":235,"dataGaLocation":41},"/de-de/customers/","customer success stories",{"text":237,"config":238},"Blog",{"href":239,"dataGaName":240,"dataGaLocation":41},"/de-de/blog/","blog",{"text":242,"config":243},"Remote",{"href":244,"dataGaName":245,"dataGaLocation":41},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":247,"items":248},"Vernetzen",[249,254,259,264,269],{"text":250,"config":251},"GitLab-Services",{"href":252,"dataGaName":253,"dataGaLocation":41},"/de-de/services/","services",{"text":255,"config":256},"Community",{"href":257,"dataGaName":258,"dataGaLocation":41},"/community/","community",{"text":260,"config":261},"Forum",{"href":262,"dataGaName":263,"dataGaLocation":41},"https://forum.gitlab.com/","forum",{"text":265,"config":266},"Veranstaltungen",{"href":267,"dataGaName":268,"dataGaLocation":41},"/events/","events",{"text":270,"config":271},"Partner",{"href":272,"dataGaName":273,"dataGaLocation":41},"/de-de/partners/","partners",{"backgroundColor":275,"textColor":276,"text":277,"image":278,"link":282},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":279,"config":280},"the source promo card",{"src":281},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":283,"config":284},"Lies die News",{"href":285,"dataGaName":286,"dataGaLocation":41},"/de-de/the-source/","the source",{"text":288,"config":289,"lists":291},"Unternehmen",{"dataNavLevelOne":290},"company",[292],{"items":293},[294,299,305,307,312,317,322,327,332,337,342],{"text":295,"config":296},"Über",{"href":297,"dataGaName":298,"dataGaLocation":41},"/de-de/company/","about",{"text":300,"config":301,"footerGa":304},"Karriere",{"href":302,"dataGaName":303,"dataGaLocation":41},"/jobs/","jobs",{"dataGaName":303},{"text":265,"config":306},{"href":267,"dataGaName":268,"dataGaLocation":41},{"text":308,"config":309},"Geschäftsführung",{"href":310,"dataGaName":311,"dataGaLocation":41},"/company/team/e-group/","leadership",{"text":313,"config":314},"Team",{"href":315,"dataGaName":316,"dataGaLocation":41},"/company/team/","team",{"text":318,"config":319},"Handbuch",{"href":320,"dataGaName":321,"dataGaLocation":41},"https://handbook.gitlab.com/","handbook",{"text":323,"config":324},"Investor Relations",{"href":325,"dataGaName":326,"dataGaLocation":41},"https://ir.gitlab.com/","investor relations",{"text":328,"config":329},"Trust Center",{"href":330,"dataGaName":331,"dataGaLocation":41},"/de-de/security/","trust center",{"text":333,"config":334},"AI Transparency Center",{"href":335,"dataGaName":336,"dataGaLocation":41},"/de-de/ai-transparency-center/","ai transparency center",{"text":338,"config":339},"Newsletter",{"href":340,"dataGaName":341,"dataGaLocation":41},"/company/contact/#contact-forms","newsletter",{"text":343,"config":344},"Presse",{"href":345,"dataGaName":346,"dataGaLocation":41},"/press/","press",{"text":348,"config":349,"lists":350},"Kontakt",{"dataNavLevelOne":290},[351],{"items":352},[353,356,361],{"text":48,"config":354},{"href":50,"dataGaName":355,"dataGaLocation":41},"talk to sales",{"text":357,"config":358},"Support-Portal",{"href":359,"dataGaName":360,"dataGaLocation":41},"https://support.gitlab.com","support portal",{"text":362,"config":363},"Kundenportal",{"href":364,"dataGaName":365,"dataGaLocation":41},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":367,"login":368,"suggestions":375},"Schließen",{"text":369,"link":370},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":371,"config":372},"gitlab.com",{"href":55,"dataGaName":373,"dataGaLocation":374},"search login","search",{"text":376,"default":377},"Vorschläge",[378,380,385,387,392,397],{"text":70,"config":379},{"href":75,"dataGaName":70,"dataGaLocation":374},{"text":381,"config":382},"Code Suggestions (KI)",{"href":383,"dataGaName":384,"dataGaLocation":374},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":104,"config":386},{"href":106,"dataGaName":104,"dataGaLocation":374},{"text":388,"config":389},"GitLab auf AWS",{"href":390,"dataGaName":391,"dataGaLocation":374},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":393,"config":394},"GitLab auf Google Cloud",{"href":395,"dataGaName":396,"dataGaLocation":374},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":398,"config":399},"Warum GitLab?",{"href":83,"dataGaName":400,"dataGaLocation":374},"Why GitLab?",{"freeTrial":402,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":403,"config":404},"Kostenlos testen",{"href":405,"dataGaName":46,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"GitLab-Symbol",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":196,"config":416},{"href":417,"dataGaName":418,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":420,"mobileIcon":425,"desktopIcon":427},{"text":421,"config":422},"Erfahre mehr über GitLab Duo",{"href":423,"dataGaName":424,"dataGaLocation":406},"/de-de/gitlab-duo/","gitlab duo",{"altText":408,"config":426},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":428},{"src":414,"dataGaName":411,"dataGaLocation":406},{"freeTrial":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"Zurück zur Preisübersicht",{"href":184,"dataGaName":433,"dataGaLocation":406,"icon":434},"back to pricing","GoBack",{"altText":408,"config":436},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":438},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":440,"button":441,"config":446},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":442,"config":443},"GitLab Transcend jetzt ansehen",{"href":444,"dataGaName":445,"dataGaLocation":41},"/de-de/events/transcend/virtual/","transcend event",{"layout":447,"icon":448},"release","AiStar",{"data":450},{"text":451,"source":452,"edit":458,"contribute":463,"config":468,"items":473,"minimal":646},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":453,"config":454},"Quelltext der Seite anzeigen",{"href":455,"dataGaName":456,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":459,"config":460},"Diese Seite bearbeiten",{"href":461,"dataGaName":462,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":464,"config":465},"Beteilige dich",{"href":466,"dataGaName":467,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":469,"facebook":470,"youtube":471,"linkedin":472},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[474,497,552,579,613],{"title":59,"links":475,"subMenu":480},[476],{"text":477,"config":478},"DevSecOps-Plattform",{"href":68,"dataGaName":479,"dataGaLocation":457},"devsecops platform",[481],{"title":182,"links":482},[483,487,492],{"text":484,"config":485},"Tarife anzeigen",{"href":184,"dataGaName":486,"dataGaLocation":457},"view plans",{"text":488,"config":489},"Vorteile von Premium",{"href":490,"dataGaName":491,"dataGaLocation":457},"/de-de/pricing/premium/","why premium",{"text":493,"config":494},"Vorteile von Ultimate",{"href":495,"dataGaName":496,"dataGaLocation":457},"/de-de/pricing/ultimate/","why ultimate",{"title":498,"links":499},"Lösungen",[500,505,508,510,515,520,524,527,530,535,537,539,542,547],{"text":501,"config":502},"Digitale Transformation",{"href":503,"dataGaName":504,"dataGaLocation":457},"/de-de/topics/digital-transformation/","digital transformation",{"text":506,"config":507},"Sicherheit und Compliance",{"href":124,"dataGaName":131,"dataGaLocation":457},{"text":116,"config":509},{"href":100,"dataGaName":101,"dataGaLocation":457},{"text":511,"config":512},"Agile Entwicklung",{"href":513,"dataGaName":514,"dataGaLocation":457},"/de-de/solutions/agile-delivery/","agile delivery",{"text":516,"config":517},"Cloud-Transformation",{"href":518,"dataGaName":519,"dataGaLocation":457},"/de-de/topics/cloud-native/","cloud transformation",{"text":521,"config":522},"SCM",{"href":113,"dataGaName":523,"dataGaLocation":457},"source code management",{"text":104,"config":525},{"href":106,"dataGaName":526,"dataGaLocation":457},"continuous integration & delivery",{"text":154,"config":528},{"href":156,"dataGaName":529,"dataGaLocation":457},"value stream management",{"text":531,"config":532},"GitOps",{"href":533,"dataGaName":534,"dataGaLocation":457},"/de-de/solutions/gitops/","gitops",{"text":167,"config":536},{"href":169,"dataGaName":170,"dataGaLocation":457},{"text":172,"config":538},{"href":174,"dataGaName":175,"dataGaLocation":457},{"text":540,"config":541},"Öffentlicher Sektor",{"href":179,"dataGaName":180,"dataGaLocation":457},{"text":543,"config":544},"Bildungswesen",{"href":545,"dataGaName":546,"dataGaLocation":457},"/de-de/solutions/education/","education",{"text":548,"config":549},"Finanzdienstleistungen",{"href":550,"dataGaName":551,"dataGaLocation":457},"/de-de/solutions/finance/","financial services",{"title":187,"links":553},[554,556,558,560,563,565,567,569,571,573,575,577],{"text":199,"config":555},{"href":201,"dataGaName":202,"dataGaLocation":457},{"text":204,"config":557},{"href":206,"dataGaName":207,"dataGaLocation":457},{"text":209,"config":559},{"href":211,"dataGaName":212,"dataGaLocation":457},{"text":214,"config":561},{"href":216,"dataGaName":562,"dataGaLocation":457},"docs",{"text":237,"config":564},{"href":239,"dataGaName":240,"dataGaLocation":457},{"text":232,"config":566},{"href":234,"dataGaName":235,"dataGaLocation":457},{"text":242,"config":568},{"href":244,"dataGaName":245,"dataGaLocation":457},{"text":250,"config":570},{"href":252,"dataGaName":253,"dataGaLocation":457},{"text":255,"config":572},{"href":257,"dataGaName":258,"dataGaLocation":457},{"text":260,"config":574},{"href":262,"dataGaName":263,"dataGaLocation":457},{"text":265,"config":576},{"href":267,"dataGaName":268,"dataGaLocation":457},{"text":270,"config":578},{"href":272,"dataGaName":273,"dataGaLocation":457},{"title":288,"links":580},[581,583,585,587,589,591,593,597,602,604,606,608],{"text":295,"config":582},{"href":297,"dataGaName":290,"dataGaLocation":457},{"text":300,"config":584},{"href":302,"dataGaName":303,"dataGaLocation":457},{"text":308,"config":586},{"href":310,"dataGaName":311,"dataGaLocation":457},{"text":313,"config":588},{"href":315,"dataGaName":316,"dataGaLocation":457},{"text":318,"config":590},{"href":320,"dataGaName":321,"dataGaLocation":457},{"text":323,"config":592},{"href":325,"dataGaName":326,"dataGaLocation":457},{"text":594,"config":595},"Sustainability",{"href":596,"dataGaName":594,"dataGaLocation":457},"/sustainability/",{"text":598,"config":599},"Vielfalt, Inklusion und Zugehörigkeit",{"href":600,"dataGaName":601,"dataGaLocation":457},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":328,"config":603},{"href":330,"dataGaName":331,"dataGaLocation":457},{"text":338,"config":605},{"href":340,"dataGaName":341,"dataGaLocation":457},{"text":343,"config":607},{"href":345,"dataGaName":346,"dataGaLocation":457},{"text":609,"config":610},"Transparenzerklärung zu moderner Sklaverei",{"href":611,"dataGaName":612,"dataGaLocation":457},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":614,"links":615},"Nimm Kontakt auf",[616,619,624,626,631,636,641],{"text":617,"config":618},"Sprich mit einem Experten/einer Expertin",{"href":50,"dataGaName":51,"dataGaLocation":457},{"text":620,"config":621},"Support",{"href":622,"dataGaName":623,"dataGaLocation":457},"/support/","get help",{"text":362,"config":625},{"href":364,"dataGaName":365,"dataGaLocation":457},{"text":627,"config":628},"Status",{"href":629,"dataGaName":630,"dataGaLocation":457},"https://status.gitlab.com/","status",{"text":632,"config":633},"Nutzungsbedingungen",{"href":634,"dataGaName":635,"dataGaLocation":457},"/terms/","terms of use",{"text":637,"config":638},"Datenschutzerklärung",{"href":639,"dataGaName":640,"dataGaLocation":457},"/de-de/privacy/","privacy statement",{"text":642,"config":643},"Cookie-Einstellungen",{"dataGaName":644,"dataGaLocation":457,"id":645,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":457},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":457},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":457,"id":645,"isOneTrustButton":26},[655],{"id":656,"title":657,"body":8,"config":658,"content":660,"description":8,"extension":24,"meta":664,"navigation":26,"path":665,"seo":666,"stem":667,"__hash__":668},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":659},"BlogAuthor",{"name":18,"config":661},{"headshot":662,"ctfId":663},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[670,686,703],{"content":671,"config":684},{"title":672,"description":673,"heroImage":674,"date":675,"body":676,"category":9,"tags":677,"authors":681},"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.",[678,23,679,680],"AI/ML","features","product",[682,683],"Aathira Nair","Amanda Rueda",{"featured":26,"template":13,"slug":685},"ace-your-planning-without-the-context-switching",{"content":687,"config":701},{"heroImage":688,"body":689,"authors":690,"updatedDate":694,"date":695,"title":696,"tags":697,"description":700,"category":9},"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",[691,692,693],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21","Embedded Views: Die Zukunft des Work Tracking in GitLab",[23,698,699],"DevSecOps platform","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":12,"template":13,"slug":702},"embedded-views-the-future-of-work-tracking-in-gitlab",{"content":704,"config":712},{"heroImage":705,"body":706,"authors":707,"updatedDate":708,"date":708,"title":709,"tags":710,"description":711,"category":9},"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.*",[18],"2025-05-20","So schreibst du eine User Story in Scrum",[23],"Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":713,"featured":12,"template":13},"how-to-write-a-user-story-in-scrum",{"promotions":715},[716,730,742],{"id":717,"categories":718,"header":720,"text":721,"button":722,"image":727},"ai-modernization",[719],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":723,"config":724},"Get your AI maturity score",{"href":725,"dataGaName":726,"dataGaLocation":240},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":728},{"src":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":731,"categories":732,"header":734,"text":721,"button":735,"image":739},"devops-modernization",[680,733],"devsecops","Are you just managing tools or shipping innovation?",{"text":736,"config":737},"Get your DevOps maturity score",{"href":738,"dataGaName":726,"dataGaLocation":240},"/assessments/devops-modernization-assessment/",{"config":740},{"src":741},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":743,"categories":744,"header":746,"text":721,"button":747,"image":751},"security-modernization",[745],"security","Are you trading speed for security?",{"text":748,"config":749},"Get your security maturity score",{"href":750,"dataGaName":726,"dataGaLocation":240},"/assessments/security-modernization-assessment/",{"config":752},{"src":753},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":755,"blurb":756,"button":757,"secondaryButton":762},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":758,"config":759},"Kostenlosen Test starten",{"href":760,"dataGaName":46,"dataGaLocation":761},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":48,"config":763},{"href":50,"dataGaName":51,"dataGaLocation":761},1772652044962]