[{"data":1,"prerenderedAt":707},["ShallowReactive",2],{"/de-de/blog/how-to-write-a-user-story-in-scrum/":3,"navigation-de-de":36,"banner-de-de":456,"footer-de-de":468,"GitLab Germany Team":678,"next-steps-de-de":692},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":26,"_id":29,"_type":30,"title":31,"_source":32,"_file":33,"_stem":34,"_extension":35},"/de-de/blog/how-to-write-a-user-story-in-scrum","blog",false,"",{"ogTitle":9,"schema":10,"ogImage":11,"ogDescription":12,"ogSiteName":13,"noIndex":6,"ogType":14,"ogUrl":15,"title":9,"canonicalUrls":15,"description":12},"User Story: Der ultimative Guide für Scrum inkl. Beispiele","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So schreibst du eine User Story in Scrum\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-05-20\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661979/Blog/Hero%20Images/scrum-project-management.jpg","Wir zeigen dir, wie du eine effektive User Story in Scrum schreibst. ✓ Definition ✓ Nutzen ✓ Aufbau ✓ Beispiele ✓ Tipps & Tricks ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com","article","https://about.gitlab.com/blog/how-to-write-a-user-story-in-scrum",{"heroImage":11,"body":17,"authors":18,"updatedDate":20,"date":20,"title":21,"tags":22,"description":24,"category":25},"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.*",[19],"GitLab Germany Team","2025-05-20","So schreibst du eine User Story in Scrum",[23],"agile","Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!","agile-planning",{"slug":27,"featured":6,"template":28},"how-to-write-a-user-story-in-scrum","BlogPost","content:de-de:blog:how-to-write-a-user-story-in-scrum.yml","yaml","How To Write A User Story In Scrum","content","de-de/blog/how-to-write-a-user-story-in-scrum.yml","de-de/blog/how-to-write-a-user-story-in-scrum","yml",{"_path":37,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"data":39,"_id":452,"_type":30,"title":453,"_source":32,"_file":454,"_stem":455,"_extension":35},"/shared/de-de/main-navigation","de-de",{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":393,"minimal":429,"duo":443},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/de-de/","gitlab logo","header",{"text":46,"config":47},"Kostenlose Testversion anfordern",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"Vertrieb kontaktieren",{"href":53,"dataGaName":54,"dataGaLocation":44},"/de-de/sales/","sales",{"text":56,"config":57},"Anmelden",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,105,204,209,314,374],{"text":62,"config":63,"cards":65,"footer":88},"Plattform",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":69,"config":70},"Erkunde unsere Plattform",{"href":71,"dataGaName":64,"dataGaLocation":44},"/de-de/platform/",{"title":73,"description":74,"link":75},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":76,"config":77},"Lerne GitLab Duo kennen",{"href":78,"dataGaName":79,"dataGaLocation":44},"/de-de/gitlab-duo/","gitlab duo ai",{"title":81,"description":82,"link":83},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":84,"config":85},"Mehr erfahren",{"href":86,"dataGaName":87,"dataGaLocation":44},"/de-de/why-gitlab/","why gitlab",{"title":89,"items":90},"Erste Schritte mit",[91,96,101],{"text":92,"config":93},"Platform Engineering",{"href":94,"dataGaName":95,"dataGaLocation":44},"/de-de/solutions/platform-engineering/","platform engineering",{"text":97,"config":98},"Entwicklererfahrung",{"href":99,"dataGaName":100,"dataGaLocation":44},"/de-de/developer-experience/","Developer experience",{"text":102,"config":103},"MLOps",{"href":104,"dataGaName":102,"dataGaLocation":44},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":106,"left":107,"config":108,"link":110,"lists":114,"footer":186},"Produkt",true,{"dataNavLevelOne":109},"solutions",{"text":111,"config":112},"Alle Lösungen anzeigen",{"href":113,"dataGaName":109,"dataGaLocation":44},"/de-de/solutions/",[115,141,164],{"title":116,"description":117,"link":118,"items":123},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":119},{"icon":120,"href":121,"dataGaName":122,"dataGaLocation":44},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[124,128,132,137],{"text":125,"config":126},"CI/CD",{"href":127,"dataGaLocation":44,"dataGaName":125},"/de-de/solutions/continuous-integration/",{"text":129,"config":130},"KI-unterstützte Entwicklung",{"href":78,"dataGaLocation":44,"dataGaName":131},"AI assisted development",{"text":133,"config":134},"Quellcodeverwaltung",{"href":135,"dataGaLocation":44,"dataGaName":136},"/de-de/solutions/source-code-management/","Source Code Management",{"text":138,"config":139},"Automatisierte Softwarebereitstellung",{"href":121,"dataGaLocation":44,"dataGaName":140},"Automated software delivery",{"title":142,"description":143,"link":144,"items":149},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":145},{"href":146,"dataGaName":147,"dataGaLocation":44,"icon":148},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[150,154,159],{"text":151,"config":152},"Sicherheit und Compliance",{"href":146,"dataGaLocation":44,"dataGaName":153},"Security & Compliance",{"text":155,"config":156},"Schutz der Software-Lieferkette",{"href":157,"dataGaLocation":44,"dataGaName":158},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":160,"config":161},"Compliance und Governance",{"href":162,"dataGaLocation":44,"dataGaName":163},"/de-de/solutions/continuous-software-compliance/","Compliance and governance",{"title":165,"link":166,"items":171},"Bewertung",{"config":167},{"icon":168,"href":169,"dataGaName":170,"dataGaLocation":44},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[172,176,181],{"text":173,"config":174},"Sichtbarkeit und Bewertung",{"href":169,"dataGaLocation":44,"dataGaName":175},"Visibility and Measurement",{"text":177,"config":178},"Wertstrommanagement",{"href":179,"dataGaLocation":44,"dataGaName":180},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":182,"config":183},"Analysen und Einblicke",{"href":184,"dataGaLocation":44,"dataGaName":185},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":187,"items":188},"GitLab für",[189,194,199],{"text":190,"config":191},"Enterprise",{"href":192,"dataGaLocation":44,"dataGaName":193},"/de-de/enterprise/","enterprise",{"text":195,"config":196},"Kleinunternehmen",{"href":197,"dataGaLocation":44,"dataGaName":198},"/de-de/small-business/","small business",{"text":200,"config":201},"den öffentlichen Sektor",{"href":202,"dataGaLocation":44,"dataGaName":203},"/de-de/solutions/public-sector/","public sector",{"text":205,"config":206},"Preise",{"href":207,"dataGaName":208,"dataGaLocation":44,"dataNavLevelOne":208},"/de-de/pricing/","pricing",{"text":210,"config":211,"link":213,"lists":217,"feature":301},"Ressourcen",{"dataNavLevelOne":212},"resources",{"text":214,"config":215},"Alle Ressourcen anzeigen",{"href":216,"dataGaName":212,"dataGaLocation":44},"/de-de/resources/",[218,251,273],{"title":219,"items":220},"Erste Schritte",[221,226,231,236,241,246],{"text":222,"config":223},"Installieren",{"href":224,"dataGaName":225,"dataGaLocation":44},"/de-de/install/","install",{"text":227,"config":228},"Kurzanleitungen",{"href":229,"dataGaName":230,"dataGaLocation":44},"/de-de/get-started/","quick setup checklists",{"text":232,"config":233},"Lernen",{"href":234,"dataGaLocation":44,"dataGaName":235},"https://university.gitlab.com/","learn",{"text":237,"config":238},"Produktdokumentation",{"href":239,"dataGaName":240,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":242,"config":243},"Best-Practice-Videos",{"href":244,"dataGaName":245,"dataGaLocation":44},"/de-de/getting-started-videos/","best practice videos",{"text":247,"config":248},"Integrationen",{"href":249,"dataGaName":250,"dataGaLocation":44},"/de-de/integrations/","integrations",{"title":252,"items":253},"Entdecken",[254,259,263,268],{"text":255,"config":256},"Kundenerfolge",{"href":257,"dataGaName":258,"dataGaLocation":44},"/de-de/customers/","customer success stories",{"text":260,"config":261},"Blog",{"href":262,"dataGaName":5,"dataGaLocation":44},"/de-de/blog/",{"text":264,"config":265},"Remote",{"href":266,"dataGaName":267,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":269,"config":270},"TeamOps",{"href":271,"dataGaName":272,"dataGaLocation":44},"/de-de/teamops/","teamops",{"title":274,"items":275},"Vernetzen",[276,281,286,291,296],{"text":277,"config":278},"GitLab-Services",{"href":279,"dataGaName":280,"dataGaLocation":44},"/de-de/services/","services",{"text":282,"config":283},"Community",{"href":284,"dataGaName":285,"dataGaLocation":44},"/community/","community",{"text":287,"config":288},"Forum",{"href":289,"dataGaName":290,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":292,"config":293},"Veranstaltungen",{"href":294,"dataGaName":295,"dataGaLocation":44},"/events/","events",{"text":297,"config":298},"Partner",{"href":299,"dataGaName":300,"dataGaLocation":44},"/de-de/partners/","partners",{"backgroundColor":302,"textColor":303,"text":304,"image":305,"link":309},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":306,"config":307},"the source promo card",{"src":308},"/images/navigation/the-source-promo-card.svg",{"text":310,"config":311},"Lies die News",{"href":312,"dataGaName":313,"dataGaLocation":44},"/de-de/the-source/","the source",{"text":315,"config":316,"lists":318},"Unternehmen",{"dataNavLevelOne":317},"company",[319],{"items":320},[321,326,332,334,339,344,349,354,359,364,369],{"text":322,"config":323},"Über",{"href":324,"dataGaName":325,"dataGaLocation":44},"/de-de/company/","about",{"text":327,"config":328,"footerGa":331},"Karriere",{"href":329,"dataGaName":330,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":330},{"text":292,"config":333},{"href":294,"dataGaName":295,"dataGaLocation":44},{"text":335,"config":336},"Geschäftsführung",{"href":337,"dataGaName":338,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":340,"config":341},"Team",{"href":342,"dataGaName":343,"dataGaLocation":44},"/company/team/","team",{"text":345,"config":346},"Handbuch",{"href":347,"dataGaName":348,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":350,"config":351},"Investor Relations",{"href":352,"dataGaName":353,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":355,"config":356},"Trust Center",{"href":357,"dataGaName":358,"dataGaLocation":44},"/de-de/security/","trust center",{"text":360,"config":361},"AI Transparency Center",{"href":362,"dataGaName":363,"dataGaLocation":44},"/de-de/ai-transparency-center/","ai transparency center",{"text":365,"config":366},"Newsletter",{"href":367,"dataGaName":368,"dataGaLocation":44},"/company/contact/","newsletter",{"text":370,"config":371},"Presse",{"href":372,"dataGaName":373,"dataGaLocation":44},"/press/","press",{"text":375,"config":376,"lists":377},"Kontakt",{"dataNavLevelOne":317},[378],{"items":379},[380,383,388],{"text":51,"config":381},{"href":53,"dataGaName":382,"dataGaLocation":44},"talk to sales",{"text":384,"config":385},"Support",{"href":386,"dataGaName":387,"dataGaLocation":44},"/support/","get help",{"text":389,"config":390},"Kundenportal",{"href":391,"dataGaName":392,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":394,"login":395,"suggestions":402},"Schließen",{"text":396,"link":397},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":398,"config":399},"gitlab.com",{"href":58,"dataGaName":400,"dataGaLocation":401},"search login","search",{"text":403,"default":404},"Vorschläge",[405,408,413,415,420,425],{"text":73,"config":406},{"href":78,"dataGaName":407,"dataGaLocation":401},"GitLab Duo (AI)",{"text":409,"config":410},"Code Suggestions (KI)",{"href":411,"dataGaName":412,"dataGaLocation":401},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":125,"config":414},{"href":127,"dataGaName":125,"dataGaLocation":401},{"text":416,"config":417},"GitLab auf AWS",{"href":418,"dataGaName":419,"dataGaLocation":401},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":421,"config":422},"GitLab auf Google Cloud",{"href":423,"dataGaName":424,"dataGaLocation":401},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":426,"config":427},"Warum GitLab?",{"href":86,"dataGaName":428,"dataGaLocation":401},"Why GitLab?",{"freeTrial":430,"mobileIcon":435,"desktopIcon":440},{"text":431,"config":432},"Kostenlos testen",{"href":433,"dataGaName":49,"dataGaLocation":434},"https://gitlab.com/-/trials/new/","nav",{"altText":436,"config":437},"GitLab-Symbol",{"src":438,"dataGaName":439,"dataGaLocation":434},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":436,"config":441},{"src":442,"dataGaName":439,"dataGaLocation":434},"/images/brand/gitlab-logo-type.svg",{"freeTrial":444,"mobileIcon":448,"desktopIcon":450},{"text":445,"config":446},"Erfahre mehr über GitLab Duo",{"href":78,"dataGaName":447,"dataGaLocation":434},"gitlab duo",{"altText":436,"config":449},{"src":438,"dataGaName":439,"dataGaLocation":434},{"altText":436,"config":451},{"src":442,"dataGaName":439,"dataGaLocation":434},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":457,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"title":458,"button":459,"config":463,"_id":465,"_type":30,"_source":32,"_file":466,"_stem":467,"_extension":35},"/shared/de-de/banner","Die GitLab Duo Agent Platform ist jetzt in der öffentlichen Beta-Phase!",{"text":84,"config":460},{"href":461,"dataGaName":462,"dataGaLocation":44},"/gitlab-duo/agent-platform/","duo banner",{"layout":464},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":469,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"data":470,"_id":674,"_type":30,"title":675,"_source":32,"_file":676,"_stem":677,"_extension":35},"/shared/de-de/main-footer",{"text":471,"source":472,"edit":478,"contribute":483,"config":488,"items":493,"minimal":666},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":473,"config":474},"Quelltext der Seite anzeigen",{"href":475,"dataGaName":476,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":479,"config":480},"Diese Seite bearbeiten",{"href":481,"dataGaName":482,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":484,"config":485},"Beteilige dich",{"href":486,"dataGaName":487,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":489,"facebook":490,"youtube":491,"linkedin":492},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[494,517,572,602,636],{"title":62,"links":495,"subMenu":500},[496],{"text":497,"config":498},"DevSecOps-Plattform",{"href":71,"dataGaName":499,"dataGaLocation":477},"devsecops platform",[501],{"title":205,"links":502},[503,507,512],{"text":504,"config":505},"Tarife anzeigen",{"href":207,"dataGaName":506,"dataGaLocation":477},"view plans",{"text":508,"config":509},"Vorteile von Premium",{"href":510,"dataGaName":511,"dataGaLocation":477},"/de-de/pricing/premium/","why premium",{"text":513,"config":514},"Vorteile von Ultimate",{"href":515,"dataGaName":516,"dataGaLocation":477},"/de-de/pricing/ultimate/","why ultimate",{"title":518,"links":519},"Lösungen",[520,525,528,530,535,540,544,547,550,555,557,559,562,567],{"text":521,"config":522},"Digitale Transformation",{"href":523,"dataGaName":524,"dataGaLocation":477},"/de-de/topics/digital-transformation/","digital transformation",{"text":151,"config":526},{"href":146,"dataGaName":527,"dataGaLocation":477},"security & compliance",{"text":138,"config":529},{"href":121,"dataGaName":122,"dataGaLocation":477},{"text":531,"config":532},"Agile Entwicklung",{"href":533,"dataGaName":534,"dataGaLocation":477},"/de-de/solutions/agile-delivery/","agile delivery",{"text":536,"config":537},"Cloud-Transformation",{"href":538,"dataGaName":539,"dataGaLocation":477},"/de-de/topics/cloud-native/","cloud transformation",{"text":541,"config":542},"SCM",{"href":135,"dataGaName":543,"dataGaLocation":477},"source code management",{"text":125,"config":545},{"href":127,"dataGaName":546,"dataGaLocation":477},"continuous integration & delivery",{"text":177,"config":548},{"href":179,"dataGaName":549,"dataGaLocation":477},"value stream management",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":477},"/de-de/solutions/gitops/","gitops",{"text":190,"config":556},{"href":192,"dataGaName":193,"dataGaLocation":477},{"text":195,"config":558},{"href":197,"dataGaName":198,"dataGaLocation":477},{"text":560,"config":561},"Öffentlicher Sektor",{"href":202,"dataGaName":203,"dataGaLocation":477},{"text":563,"config":564},"Bildungswesen",{"href":565,"dataGaName":566,"dataGaLocation":477},"/de-de/solutions/education/","education",{"text":568,"config":569},"Finanzdienstleistungen",{"href":570,"dataGaName":571,"dataGaLocation":477},"/de-de/solutions/finance/","financial services",{"title":210,"links":573},[574,576,578,580,583,585,588,590,592,594,596,598,600],{"text":222,"config":575},{"href":224,"dataGaName":225,"dataGaLocation":477},{"text":227,"config":577},{"href":229,"dataGaName":230,"dataGaLocation":477},{"text":232,"config":579},{"href":234,"dataGaName":235,"dataGaLocation":477},{"text":237,"config":581},{"href":239,"dataGaName":582,"dataGaLocation":477},"docs",{"text":260,"config":584},{"href":262,"dataGaName":5,"dataGaLocation":477},{"text":255,"config":586},{"href":587,"dataGaName":258,"dataGaLocation":477},"/customers/",{"text":264,"config":589},{"href":266,"dataGaName":267,"dataGaLocation":477},{"text":277,"config":591},{"href":279,"dataGaName":280,"dataGaLocation":477},{"text":269,"config":593},{"href":271,"dataGaName":272,"dataGaLocation":477},{"text":282,"config":595},{"href":284,"dataGaName":285,"dataGaLocation":477},{"text":287,"config":597},{"href":289,"dataGaName":290,"dataGaLocation":477},{"text":292,"config":599},{"href":294,"dataGaName":295,"dataGaLocation":477},{"text":297,"config":601},{"href":299,"dataGaName":300,"dataGaLocation":477},{"title":315,"links":603},[604,606,608,610,612,614,616,620,625,627,629,631],{"text":322,"config":605},{"href":324,"dataGaName":317,"dataGaLocation":477},{"text":327,"config":607},{"href":329,"dataGaName":330,"dataGaLocation":477},{"text":335,"config":609},{"href":337,"dataGaName":338,"dataGaLocation":477},{"text":340,"config":611},{"href":342,"dataGaName":343,"dataGaLocation":477},{"text":345,"config":613},{"href":347,"dataGaName":348,"dataGaLocation":477},{"text":350,"config":615},{"href":352,"dataGaName":353,"dataGaLocation":477},{"text":617,"config":618},"Sustainability",{"href":619,"dataGaName":617,"dataGaLocation":477},"/sustainability/",{"text":621,"config":622},"Vielfalt, Inklusion und Zugehörigkeit",{"href":623,"dataGaName":624,"dataGaLocation":477},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":355,"config":626},{"href":357,"dataGaName":358,"dataGaLocation":477},{"text":365,"config":628},{"href":367,"dataGaName":368,"dataGaLocation":477},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":477},{"text":632,"config":633},"Transparenzerklärung zu moderner Sklaverei",{"href":634,"dataGaName":635,"dataGaLocation":477},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":637,"links":638},"Nimm Kontakt auf",[639,642,644,646,651,656,661],{"text":640,"config":641},"Sprich mit einem Experten/einer Expertin",{"href":53,"dataGaName":54,"dataGaLocation":477},{"text":384,"config":643},{"href":386,"dataGaName":387,"dataGaLocation":477},{"text":389,"config":645},{"href":391,"dataGaName":392,"dataGaLocation":477},{"text":647,"config":648},"Status",{"href":649,"dataGaName":650,"dataGaLocation":477},"https://status.gitlab.com/","status",{"text":652,"config":653},"Nutzungsbedingungen",{"href":654,"dataGaName":655,"dataGaLocation":477},"/terms/","terms of use",{"text":657,"config":658},"Datenschutzerklärung",{"href":659,"dataGaName":660,"dataGaLocation":477},"/de-de/privacy/","privacy statement",{"text":662,"config":663},"Cookie-Einstellungen",{"dataGaName":664,"dataGaLocation":477,"id":665,"isOneTrustButton":107},"cookie preferences","ot-sdk-btn",{"items":667},[668,670,672],{"text":652,"config":669},{"href":654,"dataGaName":655,"dataGaLocation":477},{"text":657,"config":671},{"href":659,"dataGaName":660,"dataGaLocation":477},{"text":662,"config":673},{"dataGaName":664,"dataGaLocation":477,"id":665,"isOneTrustButton":107},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",[679],{"_path":680,"_dir":681,"_draft":6,"_partial":6,"_locale":7,"content":682,"config":686,"_id":688,"_type":30,"title":689,"_source":32,"_file":690,"_stem":691,"_extension":35},"/en-us/blog/authors/gitlab-germany-team","authors",{"name":19,"config":683},{"headshot":684,"ctfId":685},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{"template":687},"BlogAuthor","content:en-us:blog:authors:gitlab-germany-team.yml","Gitlab Germany Team","en-us/blog/authors/gitlab-germany-team.yml","en-us/blog/authors/gitlab-germany-team",{"_path":693,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"header":694,"eyebrow":695,"blurb":696,"button":697,"secondaryButton":701,"_id":703,"_type":30,"title":704,"_source":32,"_file":705,"_stem":706,"_extension":35},"/shared/de-de/next-steps","Stelle jetzt bessere Software schneller bereit","Mehr als 50 % der Fortune-100-Unternehmen vertrauen GitLab","Erlebe, was dein Team mit der intelligenten\n\n\nDevSecOps-Plattform erreichen kann.\n",{"text":46,"config":698},{"href":699,"dataGaName":49,"dataGaLocation":700},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":51,"config":702},{"href":53,"dataGaName":54,"dataGaLocation":700},"content:shared:de-de:next-steps.yml","Next Steps","shared/de-de/next-steps.yml","shared/de-de/next-steps",1754424473671]