[{"data":1,"prerenderedAt":990},["ShallowReactive",2],{"/de-de/blog/categories/agile-planning/":3,"navigation-de-de":21,"banner-de-de":442,"footer-de-de":455,"agile-planning-category-page-de-de":665},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":9,"_source":17,"_file":18,"_stem":19,"_extension":20},"/de-de/blog/categories/agile-planning","categories",false,"",{"title":9,"description":10},"Agile Planning","Browse articles related to Agile Planning on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","agile-planning","content:de-de:blog:categories:agile-planning.yml","yaml","content","de-de/blog/categories/agile-planning.yml","de-de/blog/categories/agile-planning","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":438,"_type":16,"title":439,"_source":17,"_file":440,"_stem":441,"_extension":20},"/shared/de-de/main-navigation","de-de",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":379,"minimal":415,"duo":429},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/de-de/","gitlab logo","header",{"text":31,"config":32},"Kostenlose Testversion anfordern",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Vertrieb kontaktieren",{"href":38,"dataGaName":39,"dataGaLocation":29},"/de-de/sales/","sales",{"text":41,"config":42},"Anmelden",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,189,194,300,360],{"text":47,"config":48,"cards":50,"footer":73},"Plattform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":54,"config":55},"Erkunde unsere Plattform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/de-de/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":61,"config":62},"Lerne GitLab Duo kennen",{"href":63,"dataGaName":64,"dataGaLocation":29},"/de-de/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":69,"config":70},"Mehr erfahren",{"href":71,"dataGaName":72,"dataGaLocation":29},"/de-de/why-gitlab/","why gitlab",{"title":74,"items":75},"Erste Schritte mit",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/de-de/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Entwicklererfahrung",{"href":84,"dataGaName":85,"dataGaLocation":29},"/de-de/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":171},"Produkt",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":29},"/de-de/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":114,"config":115},"KI-unterstützte Entwicklung",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":29,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":29,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":29,"icon":133},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,140,145],{"text":136,"config":137},"Application Security Testing",{"href":138,"dataGaName":139,"dataGaLocation":29},"/solutions/application-security-testing/","Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":29,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":29},"/solutions/software-compliance/",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":29},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":29,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":29,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":29,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":29,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":29,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":29,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":29,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":287},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":29},"/de-de/resources/",[203,236,259],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":29},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":29},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":29,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":29},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":29},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249,254],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":29},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":29},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":255,"config":256},"TeamOps",{"href":257,"dataGaName":258,"dataGaLocation":29},"/de-de/teamops/","teamops",{"title":260,"items":261},"Vernetzen",[262,267,272,277,282],{"text":263,"config":264},"GitLab-Services",{"href":265,"dataGaName":266,"dataGaLocation":29},"/de-de/services/","services",{"text":268,"config":269},"Community",{"href":270,"dataGaName":271,"dataGaLocation":29},"/community/","community",{"text":273,"config":274},"Forum",{"href":275,"dataGaName":276,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":278,"config":279},"Veranstaltungen",{"href":280,"dataGaName":281,"dataGaLocation":29},"/events/","events",{"text":283,"config":284},"Partner",{"href":285,"dataGaName":286,"dataGaLocation":29},"/de-de/partners/","partners",{"backgroundColor":288,"textColor":289,"text":290,"image":291,"link":295},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":292,"config":293},"the source promo card",{"src":294},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":296,"config":297},"Lies die News",{"href":298,"dataGaName":299,"dataGaLocation":29},"/de-de/the-source/","the source",{"text":301,"config":302,"lists":304},"Unternehmen",{"dataNavLevelOne":303},"company",[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"Über",{"href":310,"dataGaName":311,"dataGaLocation":29},"/de-de/company/","about",{"text":313,"config":314,"footerGa":317},"Karriere",{"href":315,"dataGaName":316,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":316},{"text":278,"config":319},{"href":280,"dataGaName":281,"dataGaLocation":29},{"text":321,"config":322},"Geschäftsführung",{"href":323,"dataGaName":324,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":326,"config":327},"Team",{"href":328,"dataGaName":329,"dataGaLocation":29},"/company/team/","team",{"text":331,"config":332},"Handbuch",{"href":333,"dataGaName":334,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"Investor Relations",{"href":338,"dataGaName":339,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"Trust Center",{"href":343,"dataGaName":344,"dataGaLocation":29},"/de-de/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":29},"/de-de/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"Newsletter",{"href":353,"dataGaName":354,"dataGaLocation":29},"/company/contact/","newsletter",{"text":356,"config":357},"Presse",{"href":358,"dataGaName":359,"dataGaLocation":29},"/press/","press",{"text":361,"config":362,"lists":363},"Kontakt",{"dataNavLevelOne":303},[364],{"items":365},[366,369,374],{"text":36,"config":367},{"href":38,"dataGaName":368,"dataGaLocation":29},"talk to sales",{"text":370,"config":371},"Support",{"href":372,"dataGaName":373,"dataGaLocation":29},"/support/","get help",{"text":375,"config":376},"Kundenportal",{"href":377,"dataGaName":378,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"Schließen",{"text":382,"link":383},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":384,"config":385},"gitlab.com",{"href":43,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"Vorschläge",[391,394,399,401,406,411],{"text":58,"config":392},{"href":63,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"Code Suggestions (KI)",{"href":397,"dataGaName":398,"dataGaLocation":387},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":400},{"href":112,"dataGaName":110,"dataGaLocation":387},{"text":402,"config":403},"GitLab auf AWS",{"href":404,"dataGaName":405,"dataGaLocation":387},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":407,"config":408},"GitLab auf Google Cloud",{"href":409,"dataGaName":410,"dataGaLocation":387},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":412,"config":413},"Warum GitLab?",{"href":71,"dataGaName":414,"dataGaLocation":387},"Why GitLab?",{"freeTrial":416,"mobileIcon":421,"desktopIcon":426},{"text":417,"config":418},"Kostenlos testen",{"href":419,"dataGaName":34,"dataGaLocation":420},"https://gitlab.com/-/trials/new/","nav",{"altText":422,"config":423},"GitLab-Symbol",{"src":424,"dataGaName":425,"dataGaLocation":420},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":422,"config":427},{"src":428,"dataGaName":425,"dataGaLocation":420},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"Erfahre mehr über GitLab Duo",{"href":63,"dataGaName":433,"dataGaLocation":420},"gitlab duo",{"altText":422,"config":435},{"src":424,"dataGaName":425,"dataGaLocation":420},{"altText":422,"config":437},{"src":428,"dataGaName":425,"dataGaLocation":420},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":443,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":444,"button":445,"config":450,"_id":452,"_type":16,"_source":17,"_file":453,"_stem":454,"_extension":20},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":446,"config":447},"Beta testen",{"href":448,"dataGaName":449,"dataGaLocation":29},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":451},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":456,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":457,"_id":661,"_type":16,"title":662,"_source":17,"_file":663,"_stem":664,"_extension":20},"/shared/de-de/main-footer",{"text":458,"source":459,"edit":465,"contribute":470,"config":475,"items":480,"minimal":653},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":460,"config":461},"Quelltext der Seite anzeigen",{"href":462,"dataGaName":463,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":466,"config":467},"Diese Seite bearbeiten",{"href":468,"dataGaName":469,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":471,"config":472},"Beteilige dich",{"href":473,"dataGaName":474,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":476,"facebook":477,"youtube":478,"linkedin":479},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[481,504,559,589,623],{"title":47,"links":482,"subMenu":487},[483],{"text":484,"config":485},"DevSecOps-Plattform",{"href":56,"dataGaName":486,"dataGaLocation":464},"devsecops platform",[488],{"title":190,"links":489},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":192,"dataGaName":493,"dataGaLocation":464},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":464},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":464},"/de-de/pricing/ultimate/","why ultimate",{"title":505,"links":506},"Lösungen",[507,512,515,517,522,527,531,534,537,542,544,546,549,554],{"text":508,"config":509},"Digitale Transformation",{"href":510,"dataGaName":511,"dataGaLocation":464},"/de-de/topics/digital-transformation/","digital transformation",{"text":513,"config":514},"Sicherheit und Compliance",{"href":138,"dataGaName":139,"dataGaLocation":464},{"text":123,"config":516},{"href":106,"dataGaName":107,"dataGaLocation":464},{"text":518,"config":519},"Agile Entwicklung",{"href":520,"dataGaName":521,"dataGaLocation":464},"/de-de/solutions/agile-delivery/","agile delivery",{"text":523,"config":524},"Cloud-Transformation",{"href":525,"dataGaName":526,"dataGaLocation":464},"/de-de/topics/cloud-native/","cloud transformation",{"text":528,"config":529},"SCM",{"href":120,"dataGaName":530,"dataGaLocation":464},"source code management",{"text":110,"config":532},{"href":112,"dataGaName":533,"dataGaLocation":464},"continuous integration & delivery",{"text":162,"config":535},{"href":164,"dataGaName":536,"dataGaLocation":464},"value stream management",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":464},"/de-de/solutions/gitops/","gitops",{"text":175,"config":543},{"href":177,"dataGaName":178,"dataGaLocation":464},{"text":180,"config":545},{"href":182,"dataGaName":183,"dataGaLocation":464},{"text":547,"config":548},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"dataGaLocation":464},{"text":550,"config":551},"Bildungswesen",{"href":552,"dataGaName":553,"dataGaLocation":464},"/de-de/solutions/education/","education",{"text":555,"config":556},"Finanzdienstleistungen",{"href":557,"dataGaName":558,"dataGaLocation":464},"/de-de/solutions/finance/","financial services",{"title":195,"links":560},[561,563,565,567,570,572,575,577,579,581,583,585,587],{"text":207,"config":562},{"href":209,"dataGaName":210,"dataGaLocation":464},{"text":212,"config":564},{"href":214,"dataGaName":215,"dataGaLocation":464},{"text":217,"config":566},{"href":219,"dataGaName":220,"dataGaLocation":464},{"text":222,"config":568},{"href":224,"dataGaName":569,"dataGaLocation":464},"docs",{"text":245,"config":571},{"href":247,"dataGaName":248,"dataGaLocation":464},{"text":240,"config":573},{"href":574,"dataGaName":243,"dataGaLocation":464},"/customers/",{"text":250,"config":576},{"href":252,"dataGaName":253,"dataGaLocation":464},{"text":263,"config":578},{"href":265,"dataGaName":266,"dataGaLocation":464},{"text":255,"config":580},{"href":257,"dataGaName":258,"dataGaLocation":464},{"text":268,"config":582},{"href":270,"dataGaName":271,"dataGaLocation":464},{"text":273,"config":584},{"href":275,"dataGaName":276,"dataGaLocation":464},{"text":278,"config":586},{"href":280,"dataGaName":281,"dataGaLocation":464},{"text":283,"config":588},{"href":285,"dataGaName":286,"dataGaLocation":464},{"title":301,"links":590},[591,593,595,597,599,601,603,607,612,614,616,618],{"text":308,"config":592},{"href":310,"dataGaName":303,"dataGaLocation":464},{"text":313,"config":594},{"href":315,"dataGaName":316,"dataGaLocation":464},{"text":321,"config":596},{"href":323,"dataGaName":324,"dataGaLocation":464},{"text":326,"config":598},{"href":328,"dataGaName":329,"dataGaLocation":464},{"text":331,"config":600},{"href":333,"dataGaName":334,"dataGaLocation":464},{"text":336,"config":602},{"href":338,"dataGaName":339,"dataGaLocation":464},{"text":604,"config":605},"Sustainability",{"href":606,"dataGaName":604,"dataGaLocation":464},"/sustainability/",{"text":608,"config":609},"Vielfalt, Inklusion und Zugehörigkeit",{"href":610,"dataGaName":611,"dataGaLocation":464},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":613},{"href":343,"dataGaName":344,"dataGaLocation":464},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":464},{"text":356,"config":617},{"href":358,"dataGaName":359,"dataGaLocation":464},{"text":619,"config":620},"Transparenzerklärung zu moderner Sklaverei",{"href":621,"dataGaName":622,"dataGaLocation":464},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":624,"links":625},"Nimm Kontakt auf",[626,629,631,633,638,643,648],{"text":627,"config":628},"Sprich mit einem Experten/einer Expertin",{"href":38,"dataGaName":39,"dataGaLocation":464},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":464},{"text":375,"config":632},{"href":377,"dataGaName":378,"dataGaLocation":464},{"text":634,"config":635},"Status",{"href":636,"dataGaName":637,"dataGaLocation":464},"https://status.gitlab.com/","status",{"text":639,"config":640},"Nutzungsbedingungen",{"href":641,"dataGaName":642,"dataGaLocation":464},"/terms/","terms of use",{"text":644,"config":645},"Datenschutzerklärung",{"href":646,"dataGaName":647,"dataGaLocation":464},"/de-de/privacy/","privacy statement",{"text":649,"config":650},"Cookie-Einstellungen",{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,659],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":464},{"text":644,"config":658},{"href":646,"dataGaName":647,"dataGaLocation":464},{"text":649,"config":660},{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":92},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":666,"allPosts":693,"totalPages":988,"initialPosts":989},{"_path":667,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":673,"config":686,"_id":689,"_type":16,"title":690,"_source":17,"_file":691,"_stem":692,"_extension":20},"/de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab",{"config":669,"ogImage":670,"title":671,"description":672},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","Embedded Views: Die Zukunft des Work Tracking in GitLab","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows.",{"heroImage":670,"body":674,"authors":675,"updatedDate":679,"date":680,"title":671,"tags":681,"description":685,"category":14},"Kommt dir das bekannt vor? Du wechselst ständig zwischen Tabs in GitLab, nur\num den\n\nÜberblick zu behalten, was in deinem Projekt passiert? Vielleicht prüfst du\n\neine Issue, springst dann zu einem Merge Request und dann zu einem Epic, um\n\nzu sehen, wie alles zusammenhängt. Ehe du dich versiehst, ist dein Browser\n\nvoller Tabs und du hast den roten Faden verloren.\n\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\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\n## Warum Embedded Views wichtig sind\n\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\n## So funktioniert's: Echtzeitdaten genau dort, wo sie am meisten gebraucht werden\n\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\n### Immer aktuell\n\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\n### Kontextbezogenes Bewusstsein\n\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\n### Leistungsstarke Filterung\n\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\n### Anpassbare Anzeige\n\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\n### Verfügbarkeit\n\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\n## Embedded Views in Aktion erleben\n\n\nDie Syntax einer Embedded View-Quelle ist eine Obermenge von YAML. Sie besteht aus:\n\n\n* Dem `query`-Parameter: Ausdrücke, die mit einem logischen Operator wie `and` verbunden werden.\n\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\n\nZum Beispiel:\n\n\n> Zeige eine Tabelle der ersten 5 offenen Issues an, die dem authentifizierten Benutzer in `gitlab-org/gitlab` zugewiesen sind.\n\n>\n\n> Zeige die Spalten `title`, `state`, `health`, `description`, `epic`, `milestone`, `weight` und `updated`.\n\n\n````yaml\n\n```glql\n\n\ndisplay: table\n\n\ntitle: GLQL-Tabelle 🎉\n\n\ndescription: Diese Ansicht listet meine offenen Issues auf\n\n\nfields: title, state, health, epic, milestone, weight, updated\n\n\nlimit: 5\n\n\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n\n\n```\n\n````\n\n\nDiese Quelle sollte eine Tabelle wie die folgende rendern:\n\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\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\n````yaml\n\n```glql\n\n\nquery: assignee = currentUser()\n\n\nfields: title, createdAt, milestone, assignee\n\n\ntitle: Mir zugewiesene Issues\n\n\n```\n\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\n## Wie GitLab Embedded Views nutzt\n\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\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\n## Was kommt als Nächstes\n\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\n## Teile deine Erfahrungen\n\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",[676,677,678],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21",[682,683,684],"agile","DevSecOps platform","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":6,"template":687,"slug":688},"BlogPost","embedded-views-the-future-of-work-tracking-in-gitlab","content:de-de:blog:embedded-views-the-future-of-work-tracking-in-gitlab.yml","Embedded Views The Future Of Work Tracking In Gitlab","de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab.yml","de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab",[694,718,742,762,782,803,823,847,866,885,906,927,947,967],{"_path":695,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":696,"content":704,"config":712,"_id":714,"_type":16,"title":715,"_source":17,"_file":716,"_stem":717,"_extension":20},"/de-de/blog/how-to-write-a-user-story-in-scrum",{"ogTitle":697,"schema":698,"ogImage":699,"ogDescription":700,"ogSiteName":701,"noIndex":6,"ogType":702,"ogUrl":703,"title":697,"canonicalUrls":703,"description":700},"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":699,"body":705,"authors":706,"updatedDate":708,"date":708,"title":709,"tags":710,"description":711,"category":14},"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.*",[707],"GitLab Germany Team","2025-05-20","So schreibst du eine User Story in Scrum",[682],"Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":713,"featured":6,"template":687},"how-to-write-a-user-story-in-scrum","content:de-de:blog:how-to-write-a-user-story-in-scrum.yml","How To Write A User Story In Scrum","de-de/blog/how-to-write-a-user-story-in-scrum.yml","de-de/blog/how-to-write-a-user-story-in-scrum",{"_path":719,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":720,"content":726,"config":736,"_id":738,"_type":16,"title":739,"_source":17,"_file":740,"_stem":741,"_extension":20},"/de-de/blog/safe-without-silos-in-gitlab",{"title":721,"description":722,"ogTitle":721,"ogDescription":722,"noIndex":6,"ogImage":723,"ogUrl":724,"ogSiteName":701,"ogType":702,"canonicalUrls":724,"schema":725},"SAFe ohne Silos in GitLab","Erfahre, wie du das Scaled Agile Framework den nativen Funktionen der DevSecOps-Plattform zuordnen kannst und welche Vorteile sich daraus ergeben.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SAFe ohne Silos in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":721,"description":722,"authors":727,"heroImage":723,"date":729,"body":730,"category":14,"tags":731,"updatedDate":735},[728],"Amanda Rueda","2025-04-08","Was passiert eigentlich, wenn dein Unternehmen das Scaled Agile Framework (SAFe) einführt, um auf Unternehmensebene zu skalieren? Du hast mehrere Teams, die an komplexen Produkten arbeiten, und benötigst eine Möglichkeit, diese Arbeit zu koordinieren. Aber hier ist ein häufiges Problem: Deine Planung erfolgt in einem Tool, während deine eigentliche Entwicklungsarbeit ganz woanders stattfindet.\n\nDiese Trennung schafft überall Probleme: Entwickler(innen) springen ständig zwischen Systemen hin und her. Produktmanager(innen) haben Schwierigkeiten, sich ein genaues Bild vom Fortschritt zu machen. Und jeder verschwendet Zeit damit, Informationen manuell von einem Ort zum anderen zu kopieren. Es ist genau diese Art von fehlendem Zusammenhang, die SAFe beseitigen soll.\n\nAuch wenn deine Entwicklungsteams [GitLab](https://about.gitlab.com/de-de/) möglicherweise bereits für die Quellcodeverwaltung, CI/CD und Sicherheit verwenden, fragst du dich vielleicht, ob GitLab auch deine Planungsanforderungen innerhalb des SAFe-Frameworks unterstützen kann. Die gute Nachricht ist, dass die agilen Projektmanagementfunktionen von GitLab SAFe umfassend unterstützen. In diesem Artikel erfährst du, wie GitLab SAFe-Konzepte und -Zeremonien abbildet, und das alles innerhalb derselben DevSecOps-Plattform, die deine Softwareentwickler(innen) bereits kennen und lieben.\n\n## Was ist SAFe?\n\nSAFe oder das Scaled Agile Framework ist eine Möglichkeit, agile Prinzipien in große Unternehmen zu bringen, ohne an Geschwindigkeit, Ausrichtung oder Kundenorientierung einzubüßen. Es nimmt das iterative und flexible Teamwork-Modell kleiner Teams auf und wendet diese Prinzipien in großen Unternehmen mit mehreren Teams, Roadmaps und Stakeholdern an. Dies bringt die Organisation in Einklang, da jedes Planen und Ausführen im Einklang erfolgt. SAFe hilft Produktmanager(inne)n, die Strategie mit der Umsetzung zu verbinden, sodass du nicht nur schnell, sondern auch die richtigen Dinge lieferst, unterstützt durch klare Prioritäten und teamübergreifende Abstimmung.\n\nSAFe reduziert Silos, fördert die Zusammenarbeit und hilft Teams, sich auf Kundenergebnisse zu konzentrieren, nicht nur auf Aufgaben. Wenn es in GitLab integriert ist, passiert etwas scheinbar Magisches: Sichtbarkeit, Nachvollziehbarkeit und Lieferung befinden sich alle an einem Ort.\n\n## SAFe-Terminologie in GitLab\n\nZunächst müssen wir festlegen, wie SAFe-Konzepte GitLab zugeordnet werden:\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Top-Level-Epic |\n| Möglichkeit | Sub-Epic (Level 1) |\n| Funktion | Sub-Epic (Level 2) |\n| User Story | Issue |\n| Aufgabe | Aufgabe |\n| Team | Benutzerdefiniertes Feld/Label mit begrenztem Geltungsbereich |\n| Sprint | Iteration |\n| Programminkrement (PI) | Meilenstein |\n| Wertschöpfungskette | Top-Level-Gruppe |\n| Agile Release Train (ART) | Top-Level-Gruppe |\n\n\u003Cbr>\u003C/br>\n\nMit dieser Zuordnung als Leitfaden kannst du GitLab so einrichten, dass es deine SAFe-Implementierung widerspiegelt. Mit der Gruppenstruktur kannst du dich um deine Wertschöpfungsketten und ARTs herum organisieren, während die Workitem-Hierarchie (mit bis zu sieben Ebenen verschachtelter Epics!) dir die nötige Tiefe für komplexe Produktportfolios bietet. Unabhängig davon, ob du auf Portfolioebene (mit Top-Level-Gruppen), auf Programmebene (mit Untergruppen) oder auf Teamebene (mit Projekten) arbeitest, passt die Organisationsstruktur von GitLab perfekt zur SAFe-Hierarchie.\n\n## Unterstützung von SAFe-Zeremonien in GitLab\n\nNun zum vergnüglichen Teil – wie führst du deine SAFe-Zeremonien in GitLab durch? Gehen wir jede einzelne durch.\n\n### PI-Planen\n\nUm die teamübergreifende Abstimmung und das Abhängigkeitsmanagement zu erleichtern, die ein erfolgreiches PI-Planen ausmachen, bietet GitLab mehrere Möglichkeiten:\n\n* Verwende die [Roadmap](https://docs.gitlab.com/user/group/roadmap/)-Ansicht, um Funktionen team- und zeitübergreifend zu visualisieren.\n* Weise dem PI-[Meilenstein](https://docs.gitlab.com/user/project/milestones/) Funktionen zu.\n* Dokumentiere und visualisiere teamübergreifende [Abhängigkeiten]( https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues), sobald sie identifiziert wurden.\n\nGitLab bietet dir Flexibilität beim PI-Planen sowohl über die Epic-Boards (die so konfiguriert werden können, dass sie Teamzuweisungen anzeigen) als auch über die Roadmap-Ansicht (die Funktionen im Zeitverlauf wie ein Gantt-Diagramm anzeigt). Du kannst während deiner Planungs-Sessions zwischen diesen Ansichten wechseln, je nachdem, ob du dich auf die Zeitachse oder die Teamorganisation konzentrierst.\n\n![Roadmap-Ansicht und Epic-Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Roadmap-Ansicht mit Gantt-Diagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Refinement\n\nAls Produktmanager(in) bedeutet das Durchführen effektiver Refinement-Sessions, dass du einen klaren Überblick über deinen Funktionen-Backlog hast. Du kannst deine Refinement-Session direkt in GitLab durchführen. Du musst nicht mehr während der Besprechung ein Tool aktualisieren und anschließend ein anderes Tool aktualisieren. \n\nGitLab unterstützt Refinement-Sessions mit:\n\n* [Epic-Boards](https://docs.gitlab.com/user/group/epics/epic_boards/), die Funktionen nach Status gruppieren. \n* Der Möglichkeit, Story-Punkte direkt in der [Übersicht](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic) anzuzeigen.  \n* Umfassenden [Drawer-Ansichten](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer), mit denen du mit Workitems interagieren kannst, ohne den Kontext zu verlieren.  \n* Der Möglichkeit, [untergeordnete Issues](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) direkt aus Epics zu erstellen und zu verknüpfen.\n\n![SAFe – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Sprint-Planung\n\nWenn es darum geht, herauszufinden, was dein Team im nächsten Sprint bewältigen kann, bietet GitLab dir:\n\n* [Issue-Übersichten](https://docs.gitlab.com/user/project/issue_board/), die einen umfassenden Überblick über deinen Backlog bieten.  \n* Eine [Gesamtgewichtung](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) von User Storys, die direkt auf den Boards angezeigt werden.\n* Die Möglichkeit, Tickets einfach zwischen Iterationen zu verschieben. \n* Eine zusammenklappbare Ansicht, die das Verschieben von Storys zwischen Sprints vereinfacht.\n\nDas bedeutet, dass du alles an einem Ort aufbewahren und deine Planungsbesprechungen tatsächlich mit dem Planen verbringen kannst, anstatt zwischen den Tools zu wechseln.\n\n![Sprint-Planung mit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 In [diesem Tutorial zur Verwendung von GitLab für Scrum](https://docs.gitlab.com/tutorials/scrum_events/) erhältst du einen detaillierten Einblick in die Möglichkeiten von GitLab für Agile Planning und Sprint-Verfolgung.* \n\n### Tägliche Stand-up-Meetings\n\nDein Team kann sich während der täglichen Stand-up-Meetings um das Board versammeln und sehen, woran alle arbeiten, wo es Probleme gibt und was zur Überprüfung bereit ist – alles in einer einzigen Ansicht. Für die täglichen Stand-up-Meetings deines Entwicklungsteams bietet GitLab dir folgende Möglichkeiten:\n\n* Erstellen von [iterationsbezogenen](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) Boards, die die Arbeit des aktuellen Sprints anzeigen.  \n* Die Anzeige von Story-Punkten/Gewichtungen direkt auf Karten. \n* Die Verwendung der [Drawer-Ansicht](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer), um auf Details zuzugreifen, ohne den Kontext zu verlassen.  \n* Die Hervorhebung gefährdeter Aufgaben durch den [Integritätsstatus](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)\n\n![Board für tägliche Stand-up-Meetings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Sprint-Review\n\nMöchtest du wissen, wie sich dein Team im Laufe der Zeit entwickelt? GitLab bietet umfassende Metriken mit:\n\n* [Abarbeitungs- und Burnup-Diagrammen](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) für Iterationen  \n* Geschwindigkeitsverfolgung  \n* [Lead- und Zykluszeit](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)-Metriken  \n* Dashboards, die auf Teams ausgerichtet werden können\n\nDiese Metriken helfen dir zu verstehen, ob dein Team schneller wird, wo es stecken bleibt und worüber du vielleicht in deiner nächsten Retrospektive sprechen möchtest.\n\n![Abarbeitungs- und Burnup-Diagramme](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 Gründe, warum eine einheitliche Plattform einen Vorteil bietet\n\nEs gibt viele Planungstools, die SAFe-Zeremonien handhaben können. Aber es gibt sehr gute Gründe, die für GitLab sprechen:\n\n1. **Kein Kontextwechsel mehr**: Planung, Programmierung, Testen und Sicherheit finden alle an einem Ort statt.  \n2. **Alles ist miteinander verbunden**: Du kannst die Arbeit vom großen Epic bis hinunter zum Code und zur Bereitstellung verfolgen.  \n3. **Alle sind auf dem gleichen Stand**: Entwickler(innen), Produktverantwortliche und Sicherheitsteams arbeiten alle mit demselben Tool zusammen.  \n4. **Vollständige Transparenz**: Stakeholder haben einen zentralen Ort, an dem sie nach Updates suchen können.  \n5. **Das Gesamtbild**: Du siehst Planungs- und Entwicklungsmetriken zusammen, damit du weißt, was wirklich vor sich geht.\n\nWenn deine Entwicklungsteams GitLab bereits schätzen, warum sollten sie dann für das Planen zu einem anderen Tool wechseln oder komplexe, zusammengeschusterte Integrationen erstellen? Wenn du deine SAFe-Planung in GitLab integrierst, wird die Arbeit für alle Beteiligten erheblich vereinfacht.\n\n## Implementierungsgrundsätze\n\nIch habe mit Teams zusammengearbeitet, die von traditionellen SAFe-Tools zu GitLab wechselten. Dabei habe ich Folgendes gelernt: Konzentriere dich auf **das, was jede Zeremonie zu erreichen versucht**, und nicht auf die exakte Nachbildung deiner alten Tools.\n\nDie Teams, die GitLab optimal nutzen, sind diejenigen, die die nativen Funktionen nutzen, anstatt dagegen anzukämpfen. Ja, es erfordert einige Vorarbeit, um herauszufinden, wie du deine SAFe-Konzepte abbilden und deine Workflows einrichten kannst. Aber wenn das einmal erledigt ist, wirst du feststellen, dass deine Prozesse tatsächlich einfacher und nicht komplexer werden.\n\nDer Schlüssel liegt in der Definition von Konventionen, die jeder befolgt. Welche Labels stehen für was? Wie wirst du Teams verfolgen? Was gehört in ein Epic und was in ein Ticket? Mit ein wenig Vorarbeit bei diesen Entscheidungen erhältst du ein intuitives System, das den gesamten Koordinationsaufwand zwischen verschiedenen Tools eliminiert.\n\n## Erste Schritte\n\nBereit, es auszuprobieren? So beginnst du mit der Implementierung von SAFe in GitLab:\n\n1. **Richte deine Struktur ein**: Erstelle Gruppen und Untergruppen, die [deiner Organisation entsprechen](https://about.gitlab.com/de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).  \n2. **Definiere deine Aufgabenverteilung**: Entscheide, wie du [Epics](https://about.gitlab.com/de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), [Tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) und [Aufgaben](https://docs.gitlab.com/user/tasks/) verwenden möchtest.  \n3. **Erstelle deine Iterationen**: Richte deinen [Sprint-Zeitplan](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence) ein.  \n4. **Füge deine Meilensteine hinzu**: [Meilensteine](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) stellen deine Programmschritte in GitLab dar.  \n5. **Erstelle deine Boards**: Erstelle verschiedene Ansichten für verschiedene Zeremonien.  \n6. **Konventionen vereinbaren**: Dokumentiere, wie du Labels und benutzerdefinierte Felder verwendest.\n\nWenn du dir im Voraus die Zeit nimmst, diese Entscheidungen zu überdenken, ersparst du dir später viele Kopfschmerzen. Und denke daran, dass du es nicht am ersten Tag perfekt machen musst – du kannst jederzeit Anpassungen vornehmen, während du dazulernst.\n\n## Alles zusammenbringen\n\nGitLab bietet dir eine solide Grundlage für die Ausführung von SAFe, insbesondere wenn deine Entwicklungsteams bereits von GitLab begeistert sind. Wenn du Planung und Entwicklung in einem einzigen Tool vereinst, eliminierst du lästige Übergaben, erleichterst die Zusammenarbeit und beschleunigst den gesamten Prozess.\n\nDas Schöne an den Planungstools von GitLab ist, dass sie flexibel genug sind, um sich an deine spezifischen SAFe-Anforderungen anzupassen. Du bist nicht an starre Arbeitsabläufe gebunden, sondern kannst deinen Ansatz weiterentwickeln, wenn deine Teams erfahrener werden und sich deine Bedürfnisse ändern.\n\n> Bist du bereit zu erkennen, wie viel besser das Leben ohne diese Planungsinseln ist? [Starte noch heute deine kostenlose Testversion](https://about.gitlab.com/de-de/free-trial/) und erfahre aus erster Hand, wie GitLab deine SAFe-Implementierung verändern kann.\n\n* 💡 Wenn dir dieser Beitrag gefallen hat, lies auch den folgenden Beitrag dazu: [GitLab für die Agile-Softwareentwicklung](https://about.gitlab.com/de-de/blog/gitlab-for-agile-software-development/)*\n",[682,683,732,733,734],"features","product","tutorial","2025-05-12",{"slug":737,"featured":92,"template":687},"safe-without-silos-in-gitlab","content:de-de:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","de-de/blog/safe-without-silos-in-gitlab.yml","de-de/blog/safe-without-silos-in-gitlab",{"_path":743,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":744,"content":750,"config":756,"_id":758,"_type":16,"title":759,"_source":17,"_file":760,"_stem":761,"_extension":20},"/de-de/blog/what-are-okrs",{"title":745,"description":746,"ogTitle":745,"ogDescription":746,"noIndex":6,"ogImage":747,"ogUrl":748,"ogSiteName":701,"ogType":702,"canonicalUrls":748,"schema":749},"Wie OKRs deine Software-Entwicklung voranbringen","Die weltweit größten Unternehmen vertrauen auf OKR. Hier bekommst du den besten Einstieg im Netz.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663217/Blog/Hero%20Images/AdobeStock_790549874.jpg","https://about.gitlab.com/blog/what-are-okrs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie OKRs deine Software-Entwicklung voranbringen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":745,"description":746,"authors":751,"heroImage":747,"date":752,"body":753,"category":14,"tags":754,"updatedDate":752},[707],"2025-04-02","# Wie OKRs deine Softwareentwicklung voranbringen\n\nObjectives & Key Results – Ziele und Schlüsselergebnisse. Das klingt zunächst einmal recht einfach. Und nahezu alle, die mit OKRs arbeiten, können bestätigen, dass die Methode denkbar unkompliziert ist.\n\nDennoch wurden einige der wertvollsten Unternehmen der Gegenwart auf dieser rasch erlernbaren Methode aufgebaut. Von Google über Intel bis hin zu Apple – OKRs haben die Welt der Planung und Organisation im Sturm erobert.\n\nIn der Softwareentwicklung lassen sich OKRs organisch in agiles Management und in die unterschiedlichsten Strukturen einbinden. OKR ist ein Managementansatz, der schnell und ohne hohen finanziellen Aufwand umgesetzt werden kann. Das macht ihn geradezu ideal für kleine und mittelständische Unternehmen.\n\nIn diesem Artikel zeigen wir dir, wie du OKRs für das Formulieren und Erreichen deiner Entwicklungsziele einsetzen kannst und was es dabei zu beachten und zu vermeiden gilt.\n\n## Was sind OKRs?  \n\nOKR ist ein Ansatz, der das Erreichen qualitativer betrieblicher Ziele an empirisch messbare Ergebnisse bindet.  \n\nDer Begriff beinhaltet zwei Teile:\n\n**Objectives** – hierbei handelt es sich um die zu erreichenden Ziele.\n\n**Key Results** – dies sind die Kennziffern, mit denen du überprüfen kannst, ob das Ziel erreicht wurde.\n\nWenn du mit OKR arbeitest, setzt du dir somit klare, am Kundennutzen ausgerichtete Ziele, und prüfst während ihrer Umsetzung kontinuierlich und anhand eindeutig quantifizierbarer Werte, ob du Fortschritte machst.\n\n## OKR-Methode: Ein Beispiel  \n\nWie sieht dieser Prozess beispielsweise in der Entwicklungspraxis aus?\n\nNehmen wir an, aus Feedback-E-Mails sei hervorgegangen, dass deine international aktiven Kunden nicht zufrieden sind mit der Funktionalität deiner Buchhaltungssoftware. Du möchtest deswegen ein neues Feature entwickeln, das internationalen Geschäften automatisch die korrekten und erforderlichen Informationen, Vorlagen und Umsatzsteuereinstellungen bereitstellt. Nutzer(innen) brauchen nur noch das Land einzustellen und die Software kümmert sich um die korrekte Abwicklung.\n\nAls Ziel gibst du deinem Team vor, die Software so zu erweitern, dass sie euren bestehenden Kunden die Rechnungsstellung und Buchung grenzüberschreitender Transaktionen spürbar erleichtert.\n\nFolgende Key Results sollen den Erfolg des Projekts ermitteln:\n\nDie Anzahl der Beschwerde-E-Mails zu diesem Thema soll auf Null reduziert werden.\nDas Rating der Software auf Bewertungsportalen soll um mindestens 0,5/5 Punkte gesteigert werden.\n\nDie Aktion soll zu mindestens 500 Neukunden führen.\n\nDieses Beispiel macht klar, wie einfach OKRs umzusetzen sind. Und auch, wenn solche OKR-Beispiele trivial klingen mögen - in der betrieblichen Praxis ist es das keineswegs.\n\n## Fokus: Warum OKRs ein Gamechanger sind\n\nAuch, wenn OKRs keine revolutionäre neue Methode darstellen, so bieten sie doch eine neue Weise, über Management zu denken.\n\nDank OKRs können Ziele zum einen nicht mehr von Ergebnissen getrennt werden.\n\nDas Formulieren von Zielen bringt dein Unternehmen nur dann nach vorne, wenn du sie überprüfen kannst. Und die Arbeit an einem Projekt war nur dann erfolgreich, wenn du nachweisen kannst, dass die angestrebten Ziele erreicht wurden.\n\nZweitens legt OKRs großen Wert auf objektivierbare Ergebnisse. Gerade in Unternehmen, die noch mit traditionellen Top-Down-Hierarchien arbeiten, liegt es oftmals im Ermessen der oberen Managementebenen, die Ergebnisse aufgrund „heuristischer” Verfahren oder schlicht persönlicher Einschätzung zu beurteilen. Das führt zu Verzerrungen und Fehleinschätzungen.\n\nDie Key Results in OKRs hingegen sind unzweideutig. Entweder ein Schlüsselergebnis wurde erreicht oder nicht.\n\nOKRs bieten ein einfaches System mit einer komplexen Wirkung. Es reduziert den gesamten Planungsprozess auf nur zwei Komponenten. Gerade innerhalb einer zunehmend komplexen Wirtschaft ist das ein deutlicher Vorteil gegenüber anderen Ansätzen.\n\nDieses Prinzip wird oft auch unter dem Punkt „Fokus” zusammengefasst, also der scharfen Ausrichtung ihrer Planung auf klar umrissene Ziele und Ergebnisse. Fokus ist eine der fünf sogenannten “Superkräfte” der OKRs.\n\n## Warum OKRs Outcome statt Output betonen\n\nDer Unterschied zwischen Outcome und Output scheint rein semantischer Natur zu sein. In OKRs jedoch trennen die beiden Begriffe Welten.\n\nEinfach gesagt ist ein Output eine Leistung, die du für deinen/deine Kunden(in) erbringst. Das kann beispielsweise ein neues Software-Feature sein. Ein Outcome orientiert sich darüber hinaus noch dafür, welchen Nutzen dieses Feature dem/der Kunden(in) konkret bietet.\n\nOKRs sollten immer so formuliert werden, dass sie den Outcome in den Mittelpunkt stellen. Das bedeutet zugleich, dass sich Milestones – Meilensteine in der Produktentwicklung – in diesem Rahmen nicht eignen, da sie in der Regel Output-orientiert sind.\n\nOKRs sind keine Aufgabenliste, die du abarbeitest. Sie orientieren sich stets daran, dem/der Kunden(in) größtmöglichen Nutzen zu bieten.\n\n## Es gibt drei verschiedene Arten von Objectives\n\nEin weiterer wichtiger Aspekt, der die OKR-Methode deutlich interessanter macht, als sie auf den ersten Blick erscheinen mag, ist die Unterteilung der Ziele in drei Typen: Committed, Aspirational und Learning.\n\n**Committed Objectives** sind Ziele, für deren Umsetzung du dich fest verbürgst. Es gibt hier keinen Spielraum: Es gilt, ein Objective umzusetzen und entweder es wird zu 100 % umgesetzt oder gar nicht.\n\n**Aspirational Objectives**, auch gelegentlich als „Stretch objectives” bezeichnet, gehen einen Schritt weiter. Diese Ziele haben den Charakter von Idealen oder, um ein beliebtes Wort zu gebrauchen, „Visionen”. Sie stehen für Ansprüche, die du an dich und dein Unternehmen stellst, aber vielleicht zu diesem Zeitpunkt noch nicht erfüllen kannst.\n\n**Learning Objectives** kommen immer dann zum Tragen, wenn es vor allem darum geht, mit der Arbeit an bestimmten Zielen den eigenen Horizont zu erweitern oder mehr Daten zu sammeln, um die eigentlichen Ziele klarer erfassen zu können.\n\n## Die besondere Bedeutung von Stretch Goals\n\nMan kann OKRs auch ohne Stretch Goals einsetzen. Dennoch sind es gerade diese ambitionierten Ziele, die diese Managementmethode so beliebt gemacht haben. Der durchschlagende Erfolg, den OKRs in den frühen Jahren von Google und bei Intel verzeichneten und der beide Unternehmen gegenüber der Konkurrenz entscheidend nach vorne gebracht hat, beruht zu einem wesentlichen Teil auf ihnen.\n\nAuch aus diesem Grund ist „Stretching” einer der Kernaspekte der OKR-Methode und eine der fünf OKR-Superkräfte.\n\nStretch Objectives sind nicht erreichbar. Aber genau wie ein Muskel nur wachsen kann, wenn er immer wieder über seine aktuelle Belastbarkeit hinaus beansprucht wird, kann auch eine Organisation nur Fortschritte machen, wenn sie ihre Grenzen erforscht. Aspirational Goals sind der Baustein der OKR-Methode, der genau dies anstrebt.\n\nDas besondere: Stretch Objectives sind keine langfristigen Leitbilder, sondern sie sind durchaus praktisch angelegt. Sie können sowohl auf niedriger als auch auf hoher Hierarchieebene Anwendung finden und stehen neben „Committed Objectives”, die zu 100 % erfüllt werden sollen.\n\nDie Idee dahinter: Auch, wenn du vielleicht nur 70 % eines epischen Ziels erreichst – und im eigentlichen Sinne an deiner Aufgabe gescheitert bist, kann das, was am Ende dabei herausgekommen ist, dennoch bemerkenswert sein.  \n\n## Google Chrome: Stretching in der Praxis\n\nDie Energien, die beim Stretching freigesetzt werden, sind in der Praxis oftmals erstaunlich. Eines der meistzitierten Beispiele für OKRs  ist, wie Google den Markt für Webbrowser mit Chrome geradezu überrollte.\n\nDas erklärte Ziel (Objective) des Unternehmens lautete 2006, den besten Browser der Welt zu entwickeln. Als Key Result wählte man schlicht die globalen Nutzerzahlen: Man wollte nach Abschluss des ersten Jahres nach Einführung von Chrome die Zahl von 20 Millionen Usern erreichen.\n\nDieses Ziel verfehlte der mit der Leitung des Projekts beauftragte Sundar Pichai deutlich – es waren nur 10 Millionen. Statt den Kopf hängen zu lassen, betrachtete er das Ergebnis aus der Perspektive des Stretchings: 10 Millionen User aus dem Stand heraus war eine geradezu astronomisch hohe Zahl und belegte, dass man auf dem besten Weg war.\n\nNiemand wollte den Erfolg mehr als Pichai, der laut einem Business-Insider-Portrait zu Sundar Pichai sogar maßgeblich daran beteiligt war, die Google-Gründer von dem Chrome-Projekt zu überzeugen. Und so gab er für das nächste Jahr das Key Result von 50 Millionen vor. Es wurden 37 Millionen. Im letzten Jahr der Offensive schließlich lautete die Vorgabe 100 Millionen Benutzer. Diese überbot Pindar sogar um 11 Millionen. 2011 hatte Chrome den langjährigen Marktführer, Microsofts Internet Explorer, überholt und war zum meistgenutzten Browser geworden. Eine schöne Übersicht zu dieser Erfolgs-Story gibt es bei Digitalcoach.\n\nHieraus wird ersichtlich, dass Stretching, wenn es konsequent und auf das richtige Produkt angewandt wird, ein enormer Motivations-Booster sein kann.\n\nWie fügen sich diese Prinzipien zu einem kohärenten Framework zusammen? Durch Alignment, Commitment und Tracking.\n\n## Alignment: Alle machen mit\n\nDas OKR-Framework ist auf eine natürliche Art und Weise mit dem Agile-Framework verbunden. Ein wesentlicher Punkt ist, dass Objectives and Key Results Teil der Arbeitsorganisation auf jeder Ebene deines Unternehmens werden müssen.\n\nDas bedeutet, dass die oberen Ebenen OKRs nach unten delegieren, aber untere Ebenen auch OKRs nach oben weiterleiten. Es findet ein ständiger Austausch statt. Anstatt sich nur darauf zu konzentrieren, starr Ziele umzusetzen, wird den Teams viel Spielraum zur Entfaltung gewährt.\n\nSich aktiv an der OKR-Planung und den Rückmeldungsschleifen zu beteiligen, ist ein integraler Teil der Philosophie.\n\nMan bezeichnet diesen Prozess auch als “Alignment”, also die kontinuierliche Ausrichtung und Abstimmung zwischen verschiedenen Teams und Hierarchien. Daten fließen stets sowohl von unten nach oben und von oben nach unten und auf einer horizontalen Ebene in alle Richtungen.\n\nOKRs verschmelzen zudem Planung und Ausführung und überbrücken damit eine der traditionell größten Lücken in der Planerfüllung.\n\n## Commitment: Motivation\n\nEng verbunden mit dem Alignment ist das Commitment, also der Wunsch, dass sich alle Mitarbeiter(innen) einer Organisation voll und ganz mit einem Ziel identifizieren und sich dessen Erreichung verschreiben. Je mehr es für den/die Einzelnen(e) erkennbar wird, wie er/sie zum Erreichen beiträgt, desto höher wird seine/ihre Motivation sein, produktiv dazu beizutragen.\n\nEs war dieser Aspekt in Kombination mit einer flachen Hierarchie, der OKRs bei Intel und Google so effektiv machte. Von Anfang an war allen Beteiligten klar, dass man in einem Boot saß und dass jeder(e) seinen/ihren Beitrag leisten konnte.\n\nAlignment und Commitment sind zwei weitere Superkräfte des OKR. Sie werden ganz unmittelbar durch das Tracking unterstützt.\n\n## Tracking: Ergebnisse fassbar machen\n\nTracking bezeichnet den praktischen Prozess der Erfassung der Key Results.  Erst durch Tracking wird die OKR-Planung agil und aus einer Reihe von Vorgaben ein System zur Zielerreichung. Wegen dieser zentralen Rolle ist Tracking die letzte der fünf Superkräfte der OKRs.\n\nOKRs sind aufgrund der ständigen Kontrolle und des Fokus auf Objektivierbarkeit eng mit der agilen Methodologie verbunden. Ziele werden ständig auf ihre Erreichbarkeit hin getestet und gegebenenfalls neu formuliert.\n\nSolange die Key Results sinnvoll gesetzt sind, sollte das Tracking nicht kompliziert sein. Komplexer und umstrittener gestaltet sich hingegen die Frage, wie die Ergebnisse anschließend bewertet werden sollen.\n\nEigentlich geben OKRs vor, dass Ziele zu 100 % erreicht werden sollen. Für manche Unternehmen aber ist dieses Denken, so nützlich es sich in der Praxis oftmals auch erweist, zu Schwarzweiß. Sie bevorzugen es, innerhalb eines Systems zu arbeiten, bei dem Ergebnisse abgestuft bewertet werden, so dass auch ein Nichterreichen nicht sofort als ein „Scheitern” eingestuft werden muss.\n\nGrading ist die Antwort auf diesen Wunsch.\n\n## Was ist Grading in OKRs? \n\nBeim Grading werden die Key Results entweder prozentual oder mit farblichen oder symbolischen Abstufungen bewertet, die es ermöglichen, das weitere Vorgehen genauer zu bestimmen.\n\nWar der angesetzte Zeitraum zu kurz? Das Ziel zu hoch gesteckt? Oder konnte das Ziel zu diesem Zeitpunkt grundsätzlich nicht erreicht werden? Diese Fragen werden im Grading beantwortet, um anschließend neue OKRs zu setzen.\n\nAuch bei Stretch Objectives kann Grading zur Anwendung kommen. Waren die 10 Millionen Chrome-Nutzer nach Ende des ersten Geschäftsjahres ein Triumph trotz Zielverfehlung - oder eben doch ein Misserfolg? Grading kann helfen, hier zu zufriedenstellenden Einschätzungen zu gelangen.\n\n## OKRs: Eine Vorlage\n\nUm mit OKRs zu arbeiten, brauchst du keinen Kurs zu belegen. Die Methode ist so intuitiv, dass du im Grunde genommen sofort damit anfangen kannst.\n\nDas Festlegen von OKR-Zielen wird den Meisten dabei noch recht leicht von der Hand gehen.\n\nEs hilft, als OKR Vorlage folgende Formulierung zu wählen:\n\n**„Wir werden [Ziel], gemessen in [Schlüsselergebnisse]”**\n\nDas mutet noch etwas abstrakt an. Anhand eines OKR-Beispiels wird dir aber recht schnell klar werden, wie so ein Satz konkret aussehen kann. Erinner dich daran, wie wir vorher beschrieben haben, wie Google den Chrome-Browser zum meistbenutzten der Welt machte. Sundair Pindai gab damals schlicht das folgende Objective aus:\n\n„Wir werden Chrome zum besten Browser machen ...”\n\nUnd das dazugehörige Key Result:\n\n„... gemessen an 20 Millionen Nutzern.”\n\n### Sind alle OKR-Ziele Stretch Objectives?\n\nGanz gewiss muss nicht bei jedem Objective gestretcht werden. Man kann sogar mit Recht behaupten, dass zu viel Stretching im wahrsten Sinne des Wortes die Organisation auf die Zerreißprobe stellen kann.\n\nWohl aber empfiehlt es sich, die OKR-Ziele so zu setzen, dass sie nicht „alltäglich” sind. Sie sollen eine Herausforderung darstellen und Zweifel an ihrer Erreichbarkeit immer gegeben sein.\n\nDiese Spannung ist ein wichtiger Aspekt dabei, dass OKRs Innovation und Motivation in deinem Unternehmen erhöhen. Sie fördern ein gesundes, mitarbeitergetriebenes Wachstum.\n\n## OKRs tracken\n\nAus diesem Beispiel geht hervor, dass die Key Results die eigentliche Herausforderung darstellen. Um beim Chrome-Beispiel zu bleiben: Dass die Nutzerzahlen wirklich der Maßstab für Qualität sind („der beste Browser”), ist nicht direkt ersichtlich.\n\nIm Zweifelsfall ergibt es Sinn, sich für solche unmittelbar fassbaren und einfach zu trackenden Werte zu entscheiden. Wenn sich auf dem Weg zum Ziel bessere Key Results offenbaren, ist es einfacher, diese anzupassen, als das ursprüngliche Ziel aufzugeben.\n\nSicher spielte für Sundar Pinchai eine Rolle, dass die Google-Geschäftsleitung nach seiner Überzeugungsarbeit den Browser-Krieg zur Chefsache gemacht und den „Sieg” zu einer strategischen Priorität erklärt hatte.\n\nDas eigentlich Entscheidende aber ist, dass Key Results auf Erfahrungswerten aufbauen und von den Teammitgliedern gesetzt werden, die eine kompetente Aussage über ihre Erreichbarkeit (oder Nichterreichbarkeit) machen können. Nur, wer die Key Results auf Daten aufbaut, kann erwarten, dass die Ergebnisse den Key Results entsprechen.\n\n## Wer ist für die Umsetzung der OKRs verantwortlich?\n\nBei Objectives and Key Results sind alle Teams sowohl für sich als auch kollektiv verantwortlich für das Erreichen oder Verfehlen der Ziele. Eine strenge „Kontrollinstanz” würde dem intrinsischen Charakter widersprechen.\n\nDennoch empfiehlt es sich, eine oder sogar zwei Personen in deiner Organisation damit zu beauftragen, den OKR-Prozess am Laufen und auf Kurs zu halten und gegebenenfalls sanft gegenzusteuern oder mit den Teams an allgemeinen Verbesserungen zu arbeiten.\n\nDies ist die Aufgabe des/der OKR Masters, gelegentlich auch „OKR Champion\" oder „OKR Coach\" genannt.\n\nDie Agile Heroes definieren in ihrem Artikel zum Thema OKR Master den/die OKR Master als „die Person im Unternehmen, die die Mitarbeiter(innen) dabei unterstützt, OKR bestmöglich zu verstehen und umzusetzen.”\n\nOKR Master sind in der Regel vor allem an der Erarbeitung und Kommunikation der OKRs beteiligt. Sie stoßen den Prozess an, halten sich aber danach zumeist eher im Hintergrund. Im Idealfall scheiden sie kurz nach Beginn des Projekts aus dem aktiven OKR-Prozess aus.\n\nGelegentlich wird noch der/die OKR-Botschafter(in) unterschieden (OKR Ambassador), die üblicherweise mit dem/der Teammanager(in) zusammenfällt. Sein/ihre Aufgabe besteht in der Koordination und Begleitung der praktischen Arbeit, der Beantwortung von Fragen und der Erstellung der abschließenden Auswertung. \n\n## Wie OKRs eine Eigendynamik entwickeln\n\nObjectives and Key Results ist keine Methode, die deiner derzeitigen Organisation gewaltsam übergestülpt wird. Sie ist auch kein Gegenmodell zu KPIs. Während KPIs sich auf die Leistungsbewertung konzentrieren, setzen OKRs einen Schritt vorher, bei der Zielsetzung selbst, an.\n\nDas Besondere an OKRs besteht darin, dass die Vorteile sich selbst verstärken und sich so zunehmend auf das gesamte Unternehmen und alle Prozesse auswirken:\n\nWeil OKRs Teams zu mehr Eigenengagement zwingen, entwickeln diese wiederum die Kompetenzen, um aus Eigeninitiative heraus selbst Ziele vorzuschlagen und umzusetzen.\nWeil OKRs die Zusammenarbeit zwischen Teams erfordern, stärken sie den inneren Zusammenhalt der Organisation. Dies wiederum erleichtert die zukünftige Zusammenarbeit.\nEine höhere intrinsische Arbeitsmotivation erlaubt die Umsetzung komplexerer, anspruchsvollerer OKR-Ziele, die wiederum eine höhere Motivation und Zufriedenheit bieten.\nWenn Tracking konsequent nur als Maßstab zur Zielerreichung genutzt wird und nicht zur Leistungsbeurteilung, spornt es alle Mitarbeiter(innen) zu vollem Einsatz an.\nTracking kann auch offenbaren, wo Optimierungsbedarf besteht, was wiederum die Arbeit mit OKRs erleichtert.\nErfolgreich absolvierte Objectives oder auch annähernd erreichte Stretch Objectives können als Erfolg aller Mitarbeiter eines Projekts, nicht nur der unmittelbar Verantwortlichen, gefeiert werden.\n\n## OKRs: FAQs\n\n### Sind OKRs Teil des agilen Managements?\n\nObjectives and Key Results sind auf jeden Fall eng mit den Prinzipien agilen Managements verbunden.\n\nHierfür spricht unter anderem, dass OKRs stets objektiv messbar sein müssen und bei dieser Methode großer Wert auf Feedback-Schleifen, regelmäßige Meetings und Teamarbeit gelegt wird.\n\nAus diesem Grund finden OKRs in ähnlichen Branchen und Unternehmen Anwendung wie agiles Management – unter anderem auch im IT-Bereich sowie in der Softwareentwicklung.\n\n### Kann ich OKRs mit Gitlab nutzen?\n\nBei GitLab sind wir von den Konzepten und Erfolgen von OKRs überzeugt. Deswegen arbeiten wir daran, dass du mit OKRs auch in GitLab arbeiten kannst.\n\nDas Projekt befindet sich aktuell noch in einer experimentellen Phase, ist aber durchaus praktisch anwendbar.\n\nMehr Informationen dazu findest du in unserem ausführlichen Artikel zu GitLab und OKRs (Englisch), in dem wir alle Schritte zur Umsetzung genau erklären.\n\n### Sind OKR dasselbe wie Management by Objectives?\n\nZwischen OKR und MBO (Management by Objectives) besteht ein enger Zusammenhang. Historisch sind Objectives & Key Results, wie die ähnliche Begrifflichkeit bereits nahelegt, aus MBO hervorgegangen.\n\nSo kann man Objectives and Key Results als Erweiterung und Neuausrichtung des in den 1950ern entwickelten Management by Objectives betrachten. Während MBO den Prozess genau vorgibt, tendenziell in langen Zyklen denkt, Outputs vorgibt und streng von einer Top-Down-Hierarchie ausgeht, fordert und fördert der OKR-Prozess kürzere Zyklen, Outcome statt Output und die Nutzung sowohl von Top-Down- als auch Bottom-Up-Flüssen.\n\nKurz gesagt: OKR ist die Umsetzung von MBO in einem Agile-Management-Framework.\n\n### Ist für die Einführung von OKRs ein Training erforderlich?\n\nEs wird gelegentlich gefordert, dass die Einführung von OKRs in einem Unternehmen über einen Sponsor und unter Begleitung von Trainern stattfindet.\n\nWir meinen: Tatsächlich empfiehlt sich die Unterstützung des OKR-Prozesses durch eine erfahrene Coaching-Persönlichkeit. Dies sollte sich aber nicht auf die Ersteinführung beschränken.\n\nEin OKR-Coach – auch OKR Master genannt – kann genau diese Aspekte begleiten und dazu beitragen, dass die verschiedenen Hierarchieebenen aufeinander abgestimmt werden und die Kommunikation der OKRs im Unternehmen stets offen, transparent und frei funktioniert.\n\nEin separates Training kann unter Umständen hilfreich sein, aber auch den Eindruck erwecken, dass OKRs ein komplexes Regelwerk beinhalten – was definitiv nicht der Fall ist.\n\n### Wie verhalten sich Objectives and Key Results zu Scrum oder Kanban?\n\nOKRs bilden eine Brücke zwischen verschiedenen agilen Management-Methoden.\n\nKPIs sind grundlegende, quantifizierbare Werte, welche ein Unternehmen selbst vorgibt. OKRs verbinden dieses Denken mit der praktischen Zielsetzungsebene und der Ausführung.\n\nAgile Führung mit OKRs kann sehr unkompliziert in einem Kanban-Board dargestellt werden. Weil Scrum selbst deutlich spezialisierter ist als Kanban, fallen die Unterschiede hier größer aus.\n\nWie die Computerwoche bemerkt, wird Scrum „meist in der Produktentwicklung eingesetzt, OKR dagegen findet überwiegend im gesamten Unternehmen Anwendung, die Produktentwicklung eingeschlossen.” Vielleicht gerade deswegen ergänzen sich die beiden geradezu optimal:\n\n„Zur Umsetzung von Zielen bedarf es mit rasch verändernden Anforderungen und Rahmenbedingungen einer iterativen und agilen Vorgehensweise. Hier kommt Scrum (oder ggf. Kanban) ins Spiel und ergänzt damit OKR ideal. Scrum (bzw. Kanban) unterstützt die operative Ausführung der Aufgaben, hilft bei der iterativen Umsetzung von Projekten und Aufgaben und trägt damit zum Fortschritt der Key Results bei.”\n\n### Erfordern OKRs eine ausführliche Dokumentation?\n\nNein. Viele Unternehmen verlangen, dass im Rahmen von Objectives and Key Results ausführlich der gesamte Prozess beobachtet wird und am Ende eines jeden Zyklus die Ergebnisse in einem Report zusammengefasst und analysiert werden.\n\nDies steht aber eher im Widerspruch zu der agilen Philosophie hinter dem Konzept.\n\nRichtig ist vielmehr: OKRs legen großen Wert auf Empirismus und Daten – aber nur die Daten, die zu Anfang als Key Results definiert wurden. Alles, was darüber hinausgeht, macht den OKR-Prozess weniger effizient und sollte deswegen auf ein Minimum beschränkt werden.\n\n### Sollen die Objectives bei OKRs gar nicht erreicht werden?\n\nDies ist ein durchaus beliebtes Missverständnis. Tatsächlich meinen viele, OKRs gäben vor, dass die Ziele so formuliert und die Key Results so gesetzt würden, dass sie innerhalb eines Zyklus überhaupt nicht erreicht werden könnten.\n\nEs stimmt, dass Objectives and Key Results Stretching als Motivationsmittel und ganz generell Zielvorgaben empfehlen, die über das zu Erwartende hinausgehen. Die meisten OKR-Ziele aber sind „lediglich” committed und sollen sehr wohl erfüllt werden – und zwar zu 100 %.\n\nStretching ist keine Anleitung dazu, das Unmögliche zu fordern, sondern ein Instrument, alle Mitarbeiter(innen) zu Höchstleistungen zu inspirieren und sich anschließend auch dann an dem Geleisteten zu erfreuen, wenn das Ziel knapp verfehlt wurde.\n\nDies betont erneut, wie wichtig es ist, dass die Key Results auf praktischen Erfahrungen beruhen und kein theoretisches Konstrukt bleiben.\n",[755],"collaboration",{"slug":757,"featured":6,"template":687},"what-are-okrs","content:de-de:blog:what-are-okrs.yml","What Are Okrs","de-de/blog/what-are-okrs.yml","de-de/blog/what-are-okrs",{"_path":763,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":764,"content":770,"config":776,"_id":778,"_type":16,"title":779,"_source":17,"_file":780,"_stem":781,"_extension":20},"/de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"title":765,"description":766,"ogTitle":765,"ogDescription":766,"noIndex":6,"ogImage":767,"ogUrl":768,"ogSiteName":701,"ogType":702,"canonicalUrls":768,"schema":769},"So bringst du Agile-Sprints mit Produkt-Roadmaps in Einklang","Nutze Best Practices und GitLab-Funktionen für deine Produkt-Journey, mit denen du unter anderem zentralisierte Roadmaps erstellen, Review-Sessions durchführen und Sprint-Lebenszyklen nachverfolgen kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","https://about.gitlab.com/blog/how-to-harmonize-agile-sprints-with-product-roadmaps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So bringst du Agile-Sprints mit Produkt-Roadmaps in Einklang\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-02-04\",\n      }",{"title":765,"description":766,"authors":771,"heroImage":767,"date":772,"body":773,"category":14,"tags":774,"updatedDate":775},[728],"2025-02-04","Stelle dir folgendes Szenario vor: Die Produkt- und Entwicklungsteams arbeiten unabhängig voneinander. Das Produktteam hat eine 12-monatige Roadmap erstellt und diese den internen Stakeholdern präsentiert, sie aber nicht mit dem Entwicklungsteam besprochen. Das Entwicklungsteam beginnt damit, die für den bevorstehenden Sprint geplanten Funktionen zu entwickeln, ohne die allgemeine Produkt-Roadmap zu berücksichtigen. Das führt dazu, dass das Timing nicht optimiert werden kann, indem z. B. Projekte parallel durchgeführt werden, die Teamkapazitäten berücksichtigt werden oder wiederverwendbare APIs erstellt werden, die für mehrere Initiativen genützt werden können. Diese mangelnde Koordination führt zu Ineffizienz und einer verspäteten Bereitstellung von Werten.\n\nEs ist nicht einfach, kurzfristige Gewinne und die langfristige Vision in Einklang zu bringen, denn dafür sind eine klare Kommunikation, aufeinander abgestimmte Prioritäten und die richtigen Tools nötig. In diesem Leitfaden lernst du Strategien kennen, mit denen du deine Agile-Sprints sowie die strategischen Roadmaps in Einklang bringst, häufige Herausforderungen meisterst und umsetzbare Lösungen findest, die perfekt zu deinen Teams passen.\n\n## Die Bedeutung einer einzigen Quelle der Wahrheit\n\nEine konsistente einzige Quelle der Wahrheit für Roadmaps mit längerfristigen Zielen stellt sicher, dass du und deine Teams auf aktuelle Informationen über das Gesamtbild zugreifen könnt. In der Praxis bedeutet dies, eine einzige, regelmäßig aktualisierte Plattform zu haben, auf der alle Details zur Roadmap zu finden sind, anstatt verschiedene Versionen der Roadmap in unterschiedliche Formaten  – und typischerweise mit leicht unterschiedlichen Informationen – zu haben, die in der Regel dazu führen, dass nicht alle in genau die gleiche Richtung ziehen.\n\n### Erstelle eine zentrale Roadmap\n\nDurch eine zentrale Roadmap für dein Team kannst du:\n\n* die langfristige Strategie kommunizieren\n* Fehlkommunikation minimieren\n* die funktionsübergreifende Abstimmung erleichtern\n* dich schnell an Änderungen anpassen, ohne dass Kontext verloren geht\n* Informationen als Self-Service bereitstellen, wodurch die Abhängigkeit von einer einzelnen Kontaktperson, die alle Informationen hat, reduziert wird\n\n***GitLab-Tipp**: Verwende [Epics (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/epics/) und die [Roadmap-Ansicht (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/roadmap/), um sowohl die Produktplanung als auch eine transparente Überwachung der Lieferung zu ermöglichen. Mit der Roadmap-Ansicht kannst du den Fortschritt nachverfolgen, Engpässe erkennen und sicherstellen, dass übergeordnete Ziele und die Ausführung auf Sprint-Ebene aufeinander abgestimmt sind.* \n\n![Roadmap-Ansicht für eine Gruppe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## Kollaborative Review-Praktiken für Roadmaps\n\nRichte einen regelmäßigen Review- und Genehmigungsprozess für Roadmap-Updates ein, die Produkt, Entwicklung und UX als Teil des [Produkttrios](https://www.producttalk.org/product-trio/) umfassen. Kollaborative Reviews tragen dazu bei, dass alle weiterhin am selben Strang ziehen, und minimieren das Risiko. Bei GitLab treffe ich mich monatlich mit meinem Engineering Manager und UX Designer, um alle Änderungen zu überprüfen und zu genehmigen. Auf der Wiki-Seite der Roadmap führen wir laufende Genehmigungen durch, wodurch wir für den Zeitplan verantwortlich sind und dem restlichen Unternehmen Transparenz bieten.\n\n#### So extrahierst du Wert aus Review-Sessions\n\nUm das Beste aus der Review-Session herauszuholen, solltest du die folgenden Best Practices anstreben:\n\n* Plane monatliche oder vierteljährliche Routine-Reviews, je nachdem, wie häufig die Roadmap in deinem Unternehmen schwankt.\n* Überprüfe die Abstimmung zwischen Produktzielen, UX-Abarbeitungsdauer und technischer Machbarkeit, indem du potenzielle Risiken und Abhängigkeiten im Voraus besprichst.\n  * Stelle sicher, dass die Roadmap die aktuellen Unternehmensziele widerspiegelt.\n * Sorge dafür, dass die Designzeitpläne realistisch sind, und berücksichtige den Recherche- oder Validierungsbedarf.\n  * Überprüfe, ob die Roadmap Zeit für die technische Vorbereitung, wie z. B. technische Spitzen oder Untersuchungen lässt, und auf die allgemeineren Prioritäten des Engineerings abgestimmt ist.  \n* Optimiere die Auslastung deines Teams, indem du Kapazitätsbeschränkungen berücksichtigst und sicherstellst, dass die Arbeitsabfolge dem Kompetenzprofil deines Teams entspricht. Dazu gehört, Phasen mit Unterauslastung oder Kompetenzlücken zu vermeiden, während du gleichzeitig für Situationen wie Personalmangel während Urlaubszeiten effektiv vorplanst.\n* Passe den Umfang richtig an und lege angemessene Erwartungen an das fest, was erreicht werden kann. Wir alle wollen den Anforderungen gerecht werden, aber es gilt: Perfektion ist der Feind des Fortschrittes. Priorisiere daher, was wirklich wichtig ist, um den inkrementellen Wert effizient zu liefern. Suche nach Optimierungsmöglichkeiten, indem du Iterationen nutzt oder die Geschwindigkeit erhöhst, indem du z. B. die Arbeitsreihenfolge anpasst, um Abhängigkeiten zu vermeiden, oder wiederverwendbare Komponenten nutzt, um die Entwicklung zu optimieren.\n* Fördere einen offenen Dialog über Kompromisse und Prioritäten, um sicherzustellen, dass alle Perspektiven einbezogen werden. Dieser kollaborative Ansatz hilft dir, kreative Lösungen für Herausforderungen zu finden und dafür zu sorgen, dass beim Weg in die Zukunft alle am selben Strang ziehen.\n\n***GitLab-Tipp**: Verwende eine [GitLab-Wiki-Seite (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/project/wiki/), um die [Roadmap-Funktion (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/roadmap/) zu ergänzen. Im Wiki kannst du den erweiterten Kontext deiner Produkt-Roadmap einbinden, z. B. geschäftliche Gründe, Links zu Benutzerforschung, RICE-Scores und Details zu Abhängigkeiten oder Risiken. Verknüpfe diese direkt mit der Roadmap, um einfach darauf zuzugreifen, und nutze die demnächst verfügbare Funktion „Diskussions-Threads“, um asynchrone Kollaboration zu fördern und Feedback von deinem Team zu erhalten.*\n\n![PlanFlow-Produkt-Roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## Kontinuierliche Richtungsvalidierung und Fortschrittsmessung\n\nDas Ziel einer Produkt-Roadmap besteht nicht nur darin, auf Kurs zu bleiben, sondern auch darin, deinen Kund(inn)en einen echten Mehrwert zu bieten. Um Raum für kontinuierliches Benutzerfeedback und Verhaltensdaten zu schaffen, solltest du dir überlegen, regelmäßige Berührungspunkte in deinem Produkttrio außerhalb von Sprint-Zyklen zu integrieren. In diesen Sessions kannst du dann Einblicke besprechen, Trends analysieren und sicherstellen, dass die Produkt-Roadmap auch weiterhin die sich entwickelnden Bedürfnisse deiner Benutzer(innen) widerspiegelt. Indem du Roadmaps auf der Grundlage echter Benutzereinblicke erstellst, lieferst du nicht nur Ergebnisse, sondern passt dich auch an das an, was für deine Kund(inn)en wirklich wichtig ist.\n\nDer Wert, den du bietest, kann sich in Form von verbesserter Benutzerfreundlichkeit, weniger Technical Debt oder ganz neuen Funktionen zeigen. Wenn das Produkttrio an die Roadmap-Vision angepasst ist, ist es auch an die Ergebnisse angepasst, die du erzielen möchtest.\n\nUm zu messen, ob du auf dem richtigen Weg bist, diese Ergebnisse auch wirklich zu erbringen, musst du die gewünschten Ergebnisse genau eingrenzen. Eine Abweichung von diesem Geltungsbereich (Scope Creep) kann, ähnlich wie verspätete Ausweitung der User Story, die Fähigkeit, einen Wert zu liefern, verzögern. Darüber hinaus ist es wichtig, Arbeit zu erkennen, die zwar geliefert wurde, aber nicht der Roadmap entspricht, und das Warum dahinter zu identifizieren.\n\n### Sprint-Planung\n\nDie Einhaltung der Produkt-Roadmap beginnt mit einer durchdachten Sprint-Planung. Wir haben für dich einige Best Practices zusammengestellt, mit denen dein Team planmäßig arbeiten und sich darauf konzentrieren kann, Werte zu liefern:\n\n* Definiere die gewünschten Ergebnisse genau und grenze sie eng ein, um eine hohe Zuversicht hinsichtlich der Lieferung sicherzustellen.\n* Identifiziere mögliche spätere Ergänzungen oder Anpassungen, die die Lieferung verzögern könnten, und plane Puffer ein, um den Fokus beizubehalten.\n* Passe die Arbeitsabläufe an dein Team an, um Kapazitäten und Kompetenzprofile zu optimieren und Abhängigkeiten zu reduzieren.\n* Um den Fokus beizubehalten und die Zuversicht in eine pünktliche Lieferung zu steigern, verplane nicht die gesamte Teamkapazität. Lasse Raum (10–20 %) für Unvorhergesehenes oder neue Entdeckungen, die während des Sprints aufkommen können.\n\n### Während des Sprints\n\nEs erfordert Fokus, Kommunikation und konstante Evaluierung, um auch während des Sprints an deiner Roadmap ausgerichtet zu bleiben. Auch wenn es das Ziel ist, Werte zu liefern, ist es ebenso wichtig, sicherzustellen, dass die laufenden Arbeiten deinen umrissenen und geplanten Zielen entsprechen.\n\n* Überprüfe kontinuierlich die laufenden Arbeiten im Hinblick auf die Ziele der Roadmap, um sicherzugehen, dass jeder Sprint zum größeren Ganzen beiträgt.\n* Ermutige das Team, regelmäßig zu überprüfen, ob es auch wirklich noch auf die geplanten Ziele und Ergebnisse hinarbeitet.* Kommuniziere während des gesamten Sprints offen. Nutze tägliche Standups oder asynchrone Updates, um Risiken, ungeplante Arbeiten oder Abhängigkeiten so früh wie möglich offenzulegen und die Prozesse wenn nötig anzupassen.\n* Bleibe deiner Linie treu, wenn es darum geht, den Sprint zu schützen. Auch wenn es natürlich ist, aufkommende Probleme sofort lösen zu wollen, sollten ungeplante Arbeiten sorgfältig evaluiert werden, um zu verhindern, dass zuvor vereinbarte Prioritäten zurückgestellt werden.\n* Verwalte eine Abweichung vom Geltungsbereich (auch als „Scope Creep“ bekannt) proaktiv. Wenn mitten im Sprint neue Arbeiten auftauchen, evaluiere, ob diese dem eng gesetzten Fokus des aktuellen Roadmap-Ergebnisses entsprechen. Während zusätzliche Ideen oder Funktionen vom Konzept her dem übergeordneten Ergebnis entsprechen können, passen sie vielleicht nicht in den aktuellen Plan, so schnell wie möglich Werte zu liefern. Dokumentiere diese Vorschläge und evaluiere, ob sie im Rahmen zukünftiger Iterationen oder als Nice-to-Have-Funktion in Zukunft einbezogen werden sollen, anstatt sie in den aktuellen Sprint zu integrieren und dadurch vereinbarte Prioritäten zu verzögern.\n\n### Sprint-Retrospektiven\n\nNimm dir in deinen Sprint-Retrospektiven mit deinem Team Zeit, darüber zu sprechen, wie gut ihr gemeinsam auf die gewünschten Ergebnisse hinarbeitet. Stelle diese Fragen:\n\n* Tauchten während des Sprints ungeplante Arbeiten auf, die dich daran gehindert haben, Werte zu erbringen? Identifiziere, warum dies passiert ist und welche Anpassungen vorgenommen werden können.  \n* Hast du Arbeiten geliefert, die von der Roadmap abweichen? Besprich, was dazu geführt hat und was du für die zukünftige Planung lernen kannst.\n\nVon der Sprint-Planung bis hin zu Retrospektiven: Es liegt in der Verantwortung des Teams, sich darauf zu konzentrieren, den Benutzer(inne)n und Stakeholdern greifbare Ergebnisse zu liefern. Indem du jeden Schritt des Wegs ausrichtest, stellst du sicher, dass deine Roadmap auch weiterhin ein klarer Rahmen ist, um effizient und konsistent Werte zu liefern.\n\n***GitLab-Tipp:** Verwende [Burndown-Charts (nur in englischer Sprache](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), um Fortschritte zu visualisieren und Abweichungen frühzeitig zu erkennen, damit sich dein Team darauf konzentrieren kann, Ergebnisse zu erzielen.*\n\n![Burndown-Chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## Liefere Roadmap-Ergebnisse mit Zuversicht\n\nUm Agile-Sprints mit strategischen Roadmaps in Einklang zu bringen, sind Intentionalität, der Rückhalt des Teams und die richtigen Tools erforderlich. Indem du eine Roadmap als einzige Quelle der Wahrheit erstellst, kollaborative Reviews förderst und den Fortschritt hin in Richtung Ergebnisse misst, bringst du Ausführung und Vision auf einen Nenner. Dank den robusten Planungsfunktionen von GitLab machen Teams aus Herausforderungen spannende Chancen für Innovation und Wachstum.\n\nBist du bereit, deine Sprints an deiner strategischen Roadmap auszurichten? [Starte jetzt eine kostenlose Testversion von GitLab](https://about.gitlab.com/de-de/free-trial/) und entdecke die Tools, mit denen du mit Zuversicht Ergebnisse erzielen kannst.\n\n## Mehr erfahren\n\n- [Content-Hub für die Agile-Planung](https://about.gitlab.com/de-de/blog/categories/agile-planning/)\n- [Die neue Planer-Rolle von GitLab für Agile-Planungsteams](https://about.gitlab.com/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)\n- [Lerne das GitLab-Wiki für effektives Wissensmanagement kennen (nur auf Englisch verfügbar)](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)",[682,734,684,683],"2025-02-26",{"slug":777,"featured":92,"template":687},"how-to-harmonize-agile-sprints-with-product-roadmaps","content:de-de:blog:how-to-harmonize-agile-sprints-with-product-roadmaps.yml","How To Harmonize Agile Sprints With Product Roadmaps","de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps.yml","de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"_path":783,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":784,"content":790,"config":797,"_id":799,"_type":16,"title":800,"_source":17,"_file":801,"_stem":802,"_extension":20},"/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"ogTitle":785,"schema":786,"ogImage":787,"ogDescription":788,"ogSiteName":701,"noIndex":6,"ogType":702,"ogUrl":789,"title":785,"canonicalUrls":789,"description":788},"Neue Rolle \"Planer(in)\" für GitLab Agile-Teams eingeführt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jetzt neu in GitLab: die neue Rolle „Planer(in)“ für Teams im Bereich der Agile-Planung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","Erfahre, wie die neue Rolle „Planer(in)“ in GitLab Agile-Teams dabei hilft, Workflows mit maßgeschneidertem Zugriff über SaaS-, Dedicated- und Self-Managed-Lösungen zu planen.","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"heroImage":787,"body":791,"authors":792,"updatedDate":793,"date":794,"title":795,"tags":796,"description":788,"category":14},"GitLab hat eine neue Rolle auf der DevSecOps-Plattform eingeführt – Planer(in). Die Rolle als Planer(in) wurde im Rahmen der Strategie von GitLab, eine flexible, rollenbasierte Zugriffskontrolle zu bieten, entwickelt, was sich auch in der Veröffentlichung [benutzerdefinierter Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) zeigt. Als Planer(in) können Entwicklungsteams und für die Planung zuständige Benutzer(innen) Zugang zu den Tools erhalten, die sie brauchen, um Agile-Workflows zu verwalten, ohne dabei zu viele Berechtigungen zu bekommen, die ein unnötiges Risiko darstellen. Indem der Zugriff auf die spezifischen Bedürfnisse der Benutzer(innen) zugeschnitten wird, stellt die Rolle als Planer(in) sicher, dass Teams produktiv bleiben und gleichzeitig die Sicherheit und Compliance wahren – ganz im Sinne des [Prinzips der geringsten Privilegien](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\n## Warum wir die Rolle „Planer(in)“ entwickelt haben\n\nUnser Weg zu dieser neuen Rolle begann mit dem Feedback unserer Kund(inn)en und internen Teams. Wir haben immer wieder gehört, dass GitLab zwar umfassende Tools für die Planung und die Verwaltung von agilen Entwicklungszyklen hat, aber es eine spezifischere, rollenbasierte Zugriffskontrolle bräuchte. Produktmanager(innen), Projektleitung und andere Planungsrollen brauchen oft Zugriff auf Planungsfunktionen, jedoch nicht die kompletten Entwicklungsberechtigungen. Im Gegenteil: Es ist nicht gewünscht, dass sie breiten Zugriff haben, da dies ein Sicherheitsrisiko darstellt und das Fehlerpotenzial vergrößert, indem beispielsweise unabsichtliche Änderungen am Code oder an sensiblen Konfigurationen vorgenommen werden. Diese Wünsche haben wir uns zu Herzen genommen.\n\nDurch Befragungen von Benutzer(inne)n, Wettbewerbsanalyse und umfassende Forschungen haben wir den Wunsch nach einer Rolle validiert, die vollständigen Zugriff auf Planungstools bietet, aber gleichzeitig die Sicherheit wahrt, indem kein Zugriff auf Funktionen für Entwickler(innen) möglich ist.\n\n## Was hat die Rolle „Planer(in)“ zu bieten?\n\nPlaner(in) ist eine Rolle, die sich zwischen den bestehenden Rollen [„Gast“ und „Reporter(in)“](https://docs.gitlab.com/ee/user/permissions.html#roles) einordnet, aber speziell für jene entwickelt wurde, die Zugriff auf Planungs-Workflows brauchen.\n\nDas erwartet dich:\n\n* Zugriff auf wichtige Planungstools wie Epics, Roadmaps, Issue-Übersichten und [OKRs](https://docs.gitlab.com/ee/user/okrs.html) (*Für einige Funktionen ist eine GitLab-Premium- oder -Ultimate-Lizenz erforderlich*)\n* Verbesserte Sicherheit, indem der unnötige Zugriff auf sensible Entwicklungsfunktionen eingeschränkt wird\n* Die Rolle als Planer(in) kann zusammen mit dem Add-on GitLab Enterprise Agile Planning verwendet werden, wodurch Teams maßgeschneiderten Zugriff auf Planungstools erhalten, während gleichzeitig Sicherheit und Kontrolle gewahrt werden. (*Die Rolle als Planer(in) ist aber in allen Lizenzstufen verfügbar*).\n\nDie Rolle „Planer(in)“ ist in allen GitLab-Lösungen verfügbar, darunter SaaS, GitLab Dedicated und GitLab Self-Managed. So können alle Kund(inn)en von diesem maßgeschneiderten Zugriff profitieren.\nMit dieser Rolle können Teams Berechtigungen flexibel an Jobfunktionen zuweisen, was ein ausgewogenes Maß an Barrierefreiheit und Sicherheit ermöglicht.\n\n## So unterstützt die Rolle als Planer(in) Agile-Praktiken\n\nIn der [Agile-Softwareentwicklung](https://about.gitlab.com/de-de/blog/categories/agile-planning/) ist es entscheidend für die Effizienz von Workflows, dass jedes Teammitglied die richtigen Tools und Berechtigungen für seine Rolle zur Verfügung hat. Die Rolle als Planer(in) unterstützt dies, indem sie es den Mitgliedern des Planungsteams ermöglicht, an allen Planungsphasen des Software-Entwicklungsprozesses mitzuwirken, ohne dass die Gefahr besteht, unabsichtlich in Bereiche wie Entwicklung oder Bereitstellung zu gelangen.\n\nVon der Erstellung und Verwaltung von Epics bis hin zum Festlegen von Roadmaps: Mit der Rolle als Planer(in) haben Agile-Teams nun die Tools zur Verfügung, die sie brauchen, um abgestimmt und produktiv zu bleiben.\n\n## Kundenorientiertes Design\n\nWir haben diese Rolle nicht isoliert entwickelt. Wir haben unsere Community bei jedem Schritt in den Prozess eingebunden. Durch Umfragen, Interviews und Tests haben wir die Berechtigungen äußerst fein abgestimmt und so sichergestellt, dass sie den praktischen Anforderungen von Produkt- und Projektmanager(inne)n entsprechen.\n\nDiese Rolle greift auch die langjährige Mission von GitLab auf, eine Plattform für Agile-Teams auf Unternehmensebene zu sein – sie bietet Unternehmen nämlich die Flexibilität und Kontrolle, um Agile-Methoden in großem Umfang umzusetzen.\n\n## Feedback und Engagement der Community\n\nWir freuen uns über deine Beiträge und bitten dich, deine Erfahrungen mit der neuen Rolle „Planer(in)“ zu teilen. Dein Feedback ist unerlässlich, um dein GitLab-Erlebnis weiter zu verfeinern und zu verbessern. In unserem [Feedback-Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/503817) kannst du uns deine Gedanken und Vorschläge mitteilen.\n\n## Beginne jetzt mit der Planung – mit GitLab!\n\nDie Rolle als Planer(in) ist nur eine von vielen Möglichkeiten, wie GitLab es Softwareentwicklungsteams ermöglicht, effizient zu planen, zusammenzuarbeiten und zu liefern. Egal, ob du deine Produktmanagement-Workflows optimieren, die Zusammenarbeit deines Teams verbessern oder deine Agile-Praktiken abstimmen möchtest – GitLab hat das passende Tool, das dir zum Erfolg verhilft.\n\n> Möchtest du das volle Potenzial von GitLab erleben? [Melde dich für eine kostenlose Testversion von GitLab Ultimate an](https://about.gitlab.com/de-de/free-trial/) und plane dein nächstes Projekt mit der Rolle „Planer(in)“, die auf die individuellen Bedürfnisse deines Teams zugeschnitten ist.\n\n## Weiterlesen\n- [Beyond Devs: GitLab Enterprise Agile Planning add-on for all roles (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [How to use GitLab for Agile software development (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/gitlab-for-agile-software-development/)\n- [First look: The new Agile planning experience in GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)",[728],"2024-12-03","2024-11-25","Jetzt neu in GitLab: die neue Rolle „Planer(in)“ für Teams im Bereich der Agile-Planung",[682,683,732,733],{"slug":798,"featured":92,"template":687},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:de-de:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":804,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":805,"content":811,"config":817,"_id":819,"_type":16,"title":820,"_source":17,"_file":821,"_stem":822,"_extension":20},"/de-de/blog/agile-epics-in-gitlab",{"title":806,"description":807,"ogTitle":806,"ogDescription":807,"noIndex":6,"ogImage":808,"ogUrl":809,"ogSiteName":701,"ogType":702,"canonicalUrls":809,"schema":810},"Agile Epics in GitLab: Mit Sicherheit zum Erfolg","Agile Epics sind eine Methode, auch bei komplexen Entwicklungsprojekten den Überblick zu behalten. Wir zeigen dir, wie es funktioniert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/agile-epics-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile Epics in GitLab: Mit Sicherheit zum Erfolg\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":806,"description":807,"authors":812,"heroImage":808,"date":813,"body":814,"category":14,"tags":815},[707],"2024-10-17","Agiles Projektmanagement führt schnell und effizient zu kundenorientierten Produkten. Aber es verlangt eine sehr genaue Planung. Epics helfen dabei.\n\nIn ihrer einfachsten Form sind Epics eine Methode, komplexe Ziele in kleine, leichter zu bewältigende Pakete aufzuteilen. Richtig angewandt können sie dazu beitragen, bessere agile Strategien für dein Unternehmen zu entwickeln.\n\nEpics bieten sich insbesondere für die Softwareentwicklung, beispielsweise in GitLab an. Doch beschränkt sich ihr Einsatz nicht darauf. Ein Epic ist ein flexibles Instrument, das in nahezu jeder Branche Anwendung finden kann.\n\nGerne zeigen wir dir, wie du Epics gewinnbringend einsetzen kannst.\n\n## Was ist ein Epic?\n\nGanz gleich, ob du neue Software entwickelst oder dir einen besseren Überblick über deine monatlichen Kennzahlen verschaffen möchtest: dein Anforderungsprofil wird in der Regel aus einer Liste von gewünschten Funktionen, Leistungen oder Informationen bestehen.\n\nDie meisten dieser Funktionen - auch „User Stories“ genannt – stellen das Team vor eine genau umrissene Aufgabe. Einige User Stories sind aber umfassender … Ihre Umsetzung erfordert eine Vielzahl von Aufgaben, die alle eng miteinander verknüpft und üblicherweise abteilungsübergreifend sind.\n\nDiese [größeren User Stories](https://www.business-wissen.de/artikel/user-storys-schreiben-beispiele-anleitung-tipps/ \"größeren User Stories\") bezeichnet man in der agilen Entwicklung als Epics. Epics spielen in der Planung eine zentrale Rolle, unabhängig davon, ob du mit Scrum oder Kanban oder einem anderen agilen Tool arbeitest.\n\n## Epics in GitLab\n\nAuch in GitLab dienen Epics dazu, umfassende User Stories oder geplante Features, die sich über verschiedene Projekte und Diskussionen erstrecken, thematisch zusammenzufassen und zu organisieren.\n\nEpics als umfassende User Stories sind kein exklusives GitLab-Feature. Ihre Integration ist hier aber besonders organisch, da GitLab als führende DevSecOps-Plattform eng mit derselben Agile-Philosophie verbunden ist, auf der auch Epics basieren.\n\nEinerseits erlauben GitLab Epics es dir, sehr präzise die unterschiedlichen Arbeitsphasen der Teams nachzuvollziehen und auf einer fast schon mikroskopischen Ebene detaillierte Planungen vorzunehmen. Andererseits bieten sie einen hervorragenden Rahmen, Projekte von einer übergeordneten Ebene aus zu betrachten und Synergien zu nutzen.\n\nIn dem folgenden Video findest du eine kurze Einleitung dazu, welchen praktischen Nutzen die Arbeit mit Epics in einem Tool wie GitLab bietet:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/kdE-yb6Puuo?si=e8BxOIowpT-eDb7U\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Was ist ein Epic?\n\nDer IT-Coach und -Berater Anthony Murphy [hat darauf hingewiesen](https://www.antmurphy.me/newsletter/from-epics-amp-stories-to-hypotheses-and-problem-statements-shifting-to-outcomes \"hat darauf hingewiesen\"), dass sich die Diskussion um Epics oftmals in Definitionen und Begriffserklärungen erschöpft. Wenn du den Begriff in eine Suchmaschine eingibst, wirst du in der Regel eine Vielzahl von Artikeln finden, die den Sachverhalt eher verkomplizieren.\n\nDabei lässt sich die Frage, was ein Epic ist, eigentlich ganz einfach beantworten: Sie unterstützen dich dabei, deine Visionen, die gerade in der Softwareentwicklung recht komplex sein können, so zu gliedern, dass sie sich Schritt für Schritt bewältigen lassen – und dabei schneller als traditionelle Methoden, wie z. B. dem Wasserfallmodell, zu marktfähigen Produkten führen.\n\nDas eigentliche Ziel besteht für Murphy darin, „unsere gewünschten Ergebnisse zu definieren, Experimente anzudenken oder auch schlicht und einfach unsere Nutzer(innen) besser zu verstehen.“\n\n## Denke Top-Down\n\nEntscheidend für eine gelungene Verwendung von Epics ist, Top-Down zu denken. Epics sind selbst eigenständige Ziele, die allerdings in kleinere Abschnitte aufgeteilt werden können und müssen.\n\nEs geht also weniger darum, penibel alle Epic Stories umzusetzen. Was zählt ist vielmehr, dass das Hauptziel erreicht wird – beispielsweise die Veröffentlichung eines neuen Features. So erlauben Epics eine bessere Einschätzung, welche User Stories wirklich relevant sind und welche unter Umständen ausgelassen werden können.\n\nDiese Top-Down-Sicht erlaubt es uns auch, die oftmals verwirrende Flut an Definitionen verständlich zu machen, die Epics umgibt. Dabei fallen häufig Begriffe wie „Themes“, „Initiatives“ oder „Milestones“. Nur wie lassen sich diese Begriffe voneinander abgrenzen?\n\n## Begrifflichkeiten: Themes, Initiatives, Epics, User Stories, Story Tasks\n\nDer Erfolg eines Unternehmens gerade in der Softwareentwicklung besteht darin, ein Gleichgewicht zwischen langfristigen Richtungsentscheidungen und einem schnellen, agilen Reagieren auf kurzfristige Entwicklungen zu erreichen.\n\nDer Zeithorizont entscheidet in der Regel, welcher Begriff in einem gegebenen Kontext der passendste ist:\n- Auf höchster Managementebene werden die grundlegenden Visionen mit sogenannten *Themes* vorgegeben, deren Zeithorizont sich auf mehrere Jahre erstrecken kann.\n- Themes werden durch die Umsetzung komplexer mittelfristiger Ziele – den *Initiatives* - erreicht.\n- *Epics* befinden sich auf der Ebene darunter und beschreiben in der Regel Projekte mit einer Laufzeit von circa sechs Monaten bis zu einem Jahr.\n- *User Stories* wiederum werden, beispielsweise in Scrum, durch iterative Zyklen von zweiwöchentlichen Sprints abgebildet.\n- Zur praktischen Umsetzung einer User Story werden konkrete Aufgaben – Tasks – an die Teams delegiert.\n\nZwischen diesen Ebenen findet eine ständige Kommunikation statt, so dass die Planung zwar von oben nach unten verläuft, aber dabei stets Rückmeldungen von unten in die zukünftige Aufgabenverteilung mit einbezogen werden.\n\n## Was ist ein Child Epic in GitLab? \n\nIm Zusammenhang mit GitLab Epics fällt auch oftmals der Begriff „Child Epic“. In GitLab bezeichnet er eine Unterkategorie, die unter der Ebene einer User Story ansetzt.\n\nHintergrund ist, dass auch manche User Stories mehrere Sprints umfassen und gelegentlich in verschiedene, kleinere Story Tasks aufgeteilt werden können. Um ein höheres Maß an Transparenz zu erreichen, können Child Epics Aufgaben kennzeichnen, die idealerweise in einem einzigen oder vielleicht zwei Sprints bewältigt werden können.\n\nSo helfen Child Epics dabei, einer noch genauere zeitliche Planung zu erreichen.\n\n## Alternative Sichtweisen auf Epics\n\nZwar empfiehlt es sich in der Regel, Epics Top-Down zu strukturieren. Alternativ kannst du Epics aber auch nutzen, um bestehende Aufgaben zu bündeln und so deine inneren betrieblichen Abläufe kohärenter zu gestalten oder neue Verbindungen zwischen scheinbar isolierten Abteilungen herzustellen.\n\nStell dir vor,Kundenkontakte werden von verschiedenen Abteilungen getrennt gepflegt. Dann kannst du ein Epic schaffen, mit dem du diese Aktivitäten zusammenführst. Besucher der Homepage können dann beispielsweise Leistungen und Produkte bewerten, Kommentare abgeben und direktes Feedback per E-Mail versenden. Diese Rückmeldungen werden an alle Teams weitergeleitet, gemeinsam diskutiert und eventuelle Optimierungen im Verbund entwickelt und umgesetzt.\n\nZudem können Epics auch im Rahmen von Themes entstehen, also aus einer visionären Planung heraus. Hierbei findet die Top-Down-Organisation eine Ebene höher statt und die Epics folgen ihr.\n\n## Epics: Beispiele aus der Scrum-Praxis\n\nEpics finden überall dort Anwendung, wo Teams kollaborativ und mit einem klaren Endziel an einem umfangreichen Projekt arbeiten.\n\nSehen wir uns einige Beispiele für agile Epics aus der Scrum-Praxis an:\n\n- Ein Unternehmen aus dem Bankbereich bittet dich, die bestehende Website um einen Mitgliederbereich zu ergänzen, auf dem Kund(inn)en deine Ressourcen visuell darstellen und verschiedene finanzielle Szenarien durchspielen können.\n- Die Geschäftsleitung deiner Firma hat die Vorgabe gemacht, die Umsätze in diesem Jahr um 10 % zu steigern. Dazu benötigst du präzisere Daten für deine strategische Planung. Aus diesem Grund arbeitest du gemeinsam mit den anderen Abteilungen an einem System zur Datenerfassung.\n- Du betreibst einen Onlineshop für Yoga-Produkte. Eine mobileApp soll Kund(inn)en aktuelle Produktneuheiten und Angebote direkt auf ihr Smartphone liefern und sie mit Informationen und Tipps zu deiner Yoga-Praxis längerfristig binden.\n\nEs lässt sich bei diesen Epics-Beispielen recht eindeutig erkennen, dass es sich hier nicht um einfache User Stories handelt, sondern um umfangreiche Projekte, die auf ein fassbares Endprodukt ausgerichtet sind.\n\nIn dem folgenden Video findest du eine noch detailliertere Betrachtungsweise, die zeigt, wie du in GitLab konkret Projekte mit Epics planen und aktualisieren kannst:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/9W4oxjdAwUs?si=mV_ru2ExQ0SNRdC_\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Wie tragen Epics zur Agile-Methodologie bei?\n\nDie Aufteilung deiner Ziele in Themes, Initiatives, Epics und User Stories ist für die Umsetzung einer agilen Entwicklung unerlässlich.\n\nDas Prinzip agiler Entwicklung besteht darin, durch das kontinuierliche praktische Testen der Software in enger Zusammenarbeit mit Kund(inn)en schneller Produkte zu entwickeln, die den gewünschten Anforderungen in höherem Maße entsprechen.\n\nEpics tragen dazu in mehrfacher Hinsicht bei:\n- Auf höchster Ebene fördern agile Epics, um ein zentrales Beispiel zu nennen, *langfristiges strategisches Denken*.\n- Epics lassen sich ganz natürlich in *direkt umsetzbare Tasks* auffächern.\n- Indem du das Ziel in kleinere Schritte aufteilst, erreichst du weitaus schneller testbare *Zwischenstufen des Produkts*, sogenannte Minimum Viable Products, MVPs.\n- Indem du das Ziel gliederst und eine Hierarchie aufstellst, sorgst du für *Transparenz*. Umso transparenter der Prozess, umso leichter lassen sich die Ergebnisse erfassen und auswerten.\n- Epics unterstützen die Zusammenarbeit zwischen verschiedenen Abteilungen in deinem Unternehmen sowie zwischen dir und den Kund(inn)en.\n- Epics tragen dazu bei, *Prioritäten* zu setzen und die Arbeitslast darauf zu beschränken, was du wirklich umsetzen kannst.\n- Den richtigen Teams ausreichende Ressourcen zukommen zu lassen ist für die Zielerreichung von höchster Bedeutung. Auch hier erlaubt der modulare Charakter von Epics eine *präzise Ressourcenallokation*.\n- Epics sollten stets ein eindeutiges Enddatum haben. Sie sollen zu fassbaren Ergebnissen führen und innerhalb eines klar definierten Zeitraums beendet sein. Anders gesagt: Wenn deine User Story nicht eindeutig abgeschlossen werden kann, handelt es sich dabei nicht um ein Epic. Diese *Produktfokussierung* ist für Unternehmen sowohl intern als auch extern ein entscheidender Vorteil.\n\n## Epics und MVPs\n\nMVPs sind eine der Schlüsselkomponenten der agilen Methodologie: Mit ihnen lassen sich Ergebnisse von Sprints in Scrum den Kundinnen und Kunden mit einem funktionsfähigen Produkt anschaulich demonstrieren.\nMit Scrum Epics zu arbeiten bedeutet, kontinuierlich auf MVPs hinzuarbeiten. Denn jede User Story entspricht hier in der Regel einem Feature des zu entwickelnden Produkts.\n\nVor allem maximieren Scrum Epics eine der wichtigsten Vorteile von MVPs, der Optimierung der [Flow-Effizienz](https://fourweekmba.com/de/Str%C3%B6mungseffizienz/ \"Flow-Effizienz\") (auch: Durchflusseffizienz, Strömungseffizienz), also der Zeit, in der produktiv und ohne Wartepausen an der Entwicklung gearbeitet werden kann.\n\nDas Epic koordiniert dabei als übergeordnetes Ziel die Aktivitäten verschiedener Teams und sorgt so dafür, dass Tasks nicht linear abgearbeitet werden (eine der zentralen Schwächen des Wasserfallmodells), sondern parallel (eine der zentralen Stärken der agilen Philosophie).\n\n## Den Erfolg von Epics messen\n\nDie Philosophie von agile beruht auf der Überzeugung, dass es besser ist, ein Produkt wiederholt praxisnah zu testen, als es auf dem Papier durchzuplanen. Epics sind ein zentraler Baustein einer agilen Entwicklungsstrategie und so kann ihre Umsetzung nur gelingen, wenn sie ständig daran gemessen werden, ob der aktuelle Stand dich deinem Ziel näher bringt.\n\n Zu diesem Zweck lassen sich Epics in einem „Epic Burndown Report“ abbilden. Diese Berichte, auch als „[Epic Burndown Chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html \"Epic Burndown Chart\")“ bezeichnet, vergleichen die ursprünglichen Einschätzungen zum Erreichen der gewünschten Ziele zu Anfang eines Sprints mit der geleisteten Arbeit und den dabei konkret erreichten Ergebnissen am Ende des Sprints. So kommst du ständig zu aktualisierten Prognosen zum (noch) erforderlichen Aufwand und Ressourceneinsatz.\n\n Burndown-Reports sind dynamisch und werden ständig um neue Arbeitsschritte ergänzt. Mit ihnen lässt sich der Erfolg von Epics hervorragend kontinuierlich erfassen und die zukünftigen Aktionen können besser abgeleitet werden.\n\n## Epics: Best Practises\n\nEs gibt eine Vielzahl von Empfehlungen, wie du Epics in der Softwareentwicklung optimal nutzen kannst. Wir haben die wichtigsten Empfehlungen für dich zusammengestellt:\n\n- Beginne so früh wie möglich mit der Planung eines Epics, so dass alle benötigten Informationen zur Verfügung stehen.\n- Beziehe alle betroffenen Abteilungen sowie Kund(inn)en mit ein.\n- Setze einen klar definierten Zeitraum an.\n- Beschränke die Zahl der User Stories, die zum Erreichen des Epics benötigt werden. Umso geringer diese Zahl, um so übersichtlicher bleibt die Planung und umso schneller gelangst du zum MVP. Statt also einem perfekten Produkt nachzujagen, setze um, was zu diesem Zeitpunkt machbar ist – und schaffe dann für die nächste Version ein neues Epic.\n- Bleibe flexibel und sei bereit, das Epic grundlegend anzupassen, wenn Praxis-Feedback dies nahelegt.\n\n## GitLab Epics und DevSecOps\n\nEpics und DevOps gehören selbstverständlich zusammen. Doch es empfiehlt sich, darüber hinaus auch noch den Sicherheitsaspekt zu berücksichtigen.\n\nDenn Sicherheitslücken stellen für jede Software und jedes neue Feature ein entscheidendes Risiko dar. Sie zu schließen gelingt weitaus besser, wenn du bei jedem Schritt auf dem Weg zum fertigen Produkt die Sicherheit des Systems mit berücksichtigt und an die Anforderungen anpasst.\n\nGitLab ist die führende DevSecOps-Plattform und unterstützt den Einsatz von Epics sowohl zum Planen als auch im Hinblick auf das Thema Security. In diesem Artikel erfährst du mehr darüber, wie GitLab dich als [KI-gestützte DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/ \"KI-gestützte DevSecOps-Plattform\") unterstützen kann.\n",[682,816],"DevOps",{"slug":818,"featured":6,"template":687},"agile-epics-in-gitlab","content:de-de:blog:agile-epics-in-gitlab.yml","Agile Epics In Gitlab","de-de/blog/agile-epics-in-gitlab.yml","de-de/blog/agile-epics-in-gitlab",{"_path":824,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":825,"content":831,"config":841,"_id":843,"_type":16,"title":844,"_source":17,"_file":845,"_stem":846,"_extension":20},"/de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"ogTitle":826,"schema":827,"ogImage":828,"ogDescription":829,"ogSiteName":701,"noIndex":6,"ogType":702,"ogUrl":830,"title":826,"canonicalUrls":830,"description":829},"Jira zu GitLab Migration 2025: Kosten sparen & mehr Features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nahtlose Migration von Jira zu GitLab mit Jira2Lab im großen Maßstab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","Atlassian erhöht Preise um bis zu 30 %. Erfahre, wie du mit GitLab mehr bekommst und dabei Geld sparst. Komplette Migrationsanleitung mit Jira2Lab.","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"heroImage":828,"body":832,"authors":833,"updatedDate":835,"date":836,"title":837,"tags":838,"description":840,"category":14},"[Atlassian Server wurde Ende Februar eingestellt](https://about.gitlab.com/de-de/move-to-gitlab-from-atlassian/), sodass viele Kund(inn)en sich nach Alternativen wie Atlassian Cloud oder Atlassian Data Center umsehen. Viele Unternehmen, die bislang Atlassian Server genutzt haben, setzen jedoch vermehrt auf Lösungen im Bereich Agile Planning, die flexiblere, kosteneffizientere und robustere DevSecOps-Integrationen bieten. Außerdem müssen sie Herausforderungen hinsichtlich Datenvolumen, Anpassbarkeit, Benutzerabbildung, Leistung und Datenintegrität bei der Migration bewältigen. Hier kommt [Jira2Lab von GitLab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab) ins Spiel – diese nahtlose Lösung ermöglicht eine Migration von Jira zu GitLab im großen Maßstab und bietet gleichzeitig eine vollständige CI/CD-Integration.\n\n## Das Problem bei großen Jira-Migrationen\n\nDie Migration von Jira zu GitLab kann eine enorme Herausforderung sein, vor allem für Unternehmen mit komplexen Workflows und tausenden Tickets, die migriert werden müssen. Das sind die häufigsten Herausforderungen bei solchen Migrationen:\n\n- **Massive Datenmigration:** Wenn die Anzahl der Tickets, Anhänge, Kommentare und Projekte steigt, steigt auch die Schwierigkeit, diese ohne Leistungsprobleme oder Datenverluste zu migrieren.\n\n- **Benutzerdefinierte Felder und Workflows:** Jira-Instanzen enthalten oft benutzerdefinierte Workflows, Felder und Tickettypen, die keine direkte Entsprechung in GitLab haben. Diese Diskrepanzen sorgen bei der Migration für Schwierigkeiten, da bei bestehenden Tools oft eine manuelle Intervention nötig ist, um diese Elemente richtig zu übertragen.\n\n- **Mangel an einer vollständigen DevSecOps-Integration:** Viele Migrationstools schaffen zwar, Projektmanagementdaten zu migrieren, integrieren jedoch nicht die vollständigen DevSecOps-Funktionen von GitLab. Dadurch müssen Teams ihre [CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/) und Managementsysteme der Versionskontrolle nach der Migration manuell konfigurieren.\n\n## Die Lösung: Jira2Lab\n\nJira2Lab wurde von Grund auf neu für die spezifischen Herausforderungen entwickelt, die eine Migration von Jira zu GitLab im großen Maßstab mit sich bringt. Es geht nicht nur darum, Daten zu verschieben, sondern Teams ohne Ausfallzeiten oder Datenverluste den nahtlosen Umstieg auf die leistungsstarke DevSecOps-Umgebung von GitLab zu ermöglichen.\n\n### Schlüsselfunktionen von Jira2Lab\n\n1. Effizienter Umgang mit Daten im großen Maßstab\u003Cbr>\nJira2Lab wurde dafür optimiert, tausende Tickets, Anhänge, Kommentare und benutzerdefinierte Projekte in mehreren Projekten ohne Leistungseinbußen zu bewältigen. Es lässt sich mühelos skalieren, um sogar Migrationen der größten Unternehmen zu meistern.\n\n2. Benutzerdefinierte Workflow- und Felder-Zuordnung\u003Cbr>\nEine der herausragenden Funktion von Jira2Lab ist die automatische Zuordnung von benutzerdefinierten Workflows und Feldern von Jira zu GitLab. Das Tool bietet eine flexible Mapping-Konfiguration, dank der keine manuelle Intervention beim Migrationsprozess nötig ist und die sicherstellt, dass alles reibungslos von Jira nach GitLab migriert wird.\n\n3. CI/CD-Pipeline-Integration\u003Cbr>\nJira2Lab migriert nicht nur Tickets und Projekte, sondern integriert sogar die komplette CI/CD-Pipeline von GitLab in den Migrationsprozess. Dadurch wird sichergestellt, dass die Entwicklungsteams sofort nach der Migration die DevSecOps-Funktionen von GitLab wie automatisierte Tests und Bereitstellungs-Pipelines nutzen können.\n\n4. Testmigrationen\u003Cbr>\nUnser Tool unterstützt Testmigrationen, damit Teams ihre Konfigurationen und Workflows vor der Skalierung testen können. Dadurch wird sichergestellt, dass Probleme frühzeitig erkannt werden, sodass es bei der richtigen Migration zu keinen Unterbrechungen und Ausfällen kommt.\n\n5. Echtzeit-Überwachung\u003Cbr>\nDas Tool bietet Echtzeit-Überwachung und -Protokolle während der Migration sowie vollständige Transparenz, um sicherzustellen, dass jeder Schritt korrekt und fehlerfrei ausgeführt wird.\n\n6. Anpassbar und flexibel\u003Cbr>\nAuch wenn deine Jira-Instanz einzigartige Konfigurationen oder Workflows hat, ist Jira2Lab flexibel genug, um die Migration an deine spezifischen Anforderungen anzupassen. So wird sichergestellt, dass bei der Übertragung nichts verloren geht.\n\n### Jira und GitLab im Vergleich\n\nDie Migration von Jira zu GitLab hilft, Workflows zu konsolidieren und erweiterte Funktionen zu nutzen, die in GitLab nativ sind. Hier ist ein kurzer Vergleich der Kernfunktionen der beiden Plattformen:\n\n| **Funktion** | **Jira** | **GitLab** |\n|----------|------|--------|\n| Ticketverfolgung | Ja (stark anpassbar) | Ja (in DevSecOps integriert) |\n| Agile Boards | Ja (Kanban, Scrum) | Ja (Issue-Übersichten, Meilensteine) |\n| CI/CD | Nein (externe Tools erforderlich) | Ja (integrierte CI/CD) |\n| Versionskontrolle | Nein (GitHub/Bitbucket erforderlich) | Ja (nativer Git-Support) |\n| DevSecOps-Tools | Begrenzte Integrationen | Kompletter DevSecOps-Lebenszyklus |\n| **KI-Funktionen** | **Atlassian Intelligence (Premium/Enterprise)** | **GitLab Duo (alle Stufen verfügbar)** |\n| **KI-Kosten** | **Zusätzlich ab Premium-Plan** | **In GitLab Ultimate enthalten** |\n| **Sicherheitsscans** | **Über Marketplace-Apps** | **Nativ integriert (SAST, DAST, etc.)** |\n\n\nMit Jira2Lab stellen wir sicher, dass alle wichtigen Aspekte – von der Ticketverfolgung bis hin zu CI/CD-Pipelines – reibungslos migriert werden. Dabei wird der integrierte Ansatz von GitLab hinsichtlich Entwicklung und Betrieb vollständig genutzt.\n\n### Die wahren Kosten einer Jira-Implementierung\n\nWährend Jira auf den ersten Blick kostengünstig erscheinen mag, zeigt sich bei genauerer Betrachtung ein anderes Bild:\n\n**Versteckte Kosten bei Jira:**\n- Separate Lizenzen für Confluence (Dokumentation), Bitbucket (Code) und Bamboo (CI/CD)\n- Marketplace-Apps für grundlegende Funktionen (durchschnittlich 5-10 Apps pro Installation)\n- Atlassian Intelligence nur in teuren Premium/Enterprise-Plänen\n- Assets und Virtual Service Agent mit verbrauchsbasierter Abrechnung\n\n**GitLabs All-in-One-Vorteil:**\nMit GitLab erhalten Teams eine vollständige DevSecOps-Plattform ohne zusätzliche Lizenzkosten. Wiki, Code-Repository, CI/CD, Sicherheitsscans und KI-Funktionen sind bereits enthalten, was bei vergleichbarem Atlassian-Stack leicht das 2-3-fache kosten kann.\n\n### Warum jetzt der richtige Zeitpunkt für eine Migration ist\n\nAtlassian hat in den letzten 18 Monaten eine aggressive Preisstrategie verfolgt, die viele Unternehmen zum Umdenken bewegt:\n- **Oktober 2024**: Cloud-Preise stiegen um 5-20%, wobei größere Teams besonders betroffen waren\n- **Februar 2025**: Data Center-Preise erhöhten sich nochmals um 5-30%, mit besonders drastischen Anstiegen bei Jira Software\n- **Funktionsverlagerung**: Wichtige ITSM-Funktionen wie Incident-, Problem- und Change-Management wurden von Standard auf Premium/Enterprise verschoben\n\nDiese kontinuierlichen Preiserhöhungen machen GitLab zu einer wirtschaftlich attraktiven Alternative, die gleichzeitig einen vollständigen DevSecOps-Ansatz ohne zusätzliche Tool-Kosten bietet.\n\n## Die Migrationsmethodik \n\nJira2Lab folgt einer strukturierten, fünfphasigen Migrationsmethodik, die eine nahtlose Migration mit minimalen Unterbrechungen gewährleistet:\n\n### 1. Entdeckung und Planung\n\nWir beginnen damit, das Jira-Setup des Kunden bzw. der Kundin genau zu verstehen und alle erforderlichen benutzerdefinierten Workflows, Felder und Projekte zu identifizieren, die migriert werden müssen. In dieser Phase wird auch eine Lückenanalyse durchgeführt, um die Funktionen von Jira und GitLab zu vergleichen und den Migrationsprozess abzubilden.\n\n### 2. Einrichtung\nIn dieser Phase konfigurieren wir das Migrationstool und richten die erforderlichen Umgebungen für Jira und GitLab ein. Dabei überprüfen wir alle Berechtigungen und richten vor Beginn der Migration eine Sicherung der Jira-Daten ein.\n\n### 3. Testmigrationen\nVor der Migration des gesamten Datensatzes führen wir Testmigrationen für ausgewählte Projekte durch, um den Migrationsprozess, die Workflows und die Datenintegrität zu testen. So können wir Probleme früh im Prozess erkennen und lösen.\n\n### 4. Skalierte Migrationen\nNach der Validierung der Testmigration skalieren wir die Migration über alle Projekte hinweg, um minimale Ausfallzeiten und reibungslose Übergänge für die Entwicklungsteams zu gewährleisten.\n\n### 5. Abschluss und Unterstützung nach der Migration\nSobald die Migration abgeschlossen ist, bieten wir fortlaufenden Support, um sicherzustellen, dass alle Teams in GitLab voll einsatzfähig sind. In dieser Phase werden auch die Benutzer(innen) geschult und die Jira-Instanz bei Bedarf außer Betrieb genommen.\n\n## Fallstudie: Skalierung mit Jira2Lab\n\nIn einer kürzlich durchgeführten Migration stand ein großes Unternehmen vor der Herausforderung, über 20 000 Tickets in 50 Projekten von Jira zu GitLab zu migrieren. Das Projekt wies hochgradig benutzerdefinierte Workflows und Tausende von Kommentaren und Anhängen auf, die übertragen werden mussten.\n\nMit Jira2Lab konnten wir:\n\n- Alle Daten, einschließlich benutzerdefinierter Felder, ohne Datenverlust migrieren.\n- CI/CD-Pipelines in GitLab einrichten, damit Teams nach der Migration sofort weiterarbeiten konnten.\n- Eine Testmigration von zwei Projekten durchführen, die es uns ermöglichte, kleinere Workflow-Diskrepanzen zu identifizieren und zu beheben, bevor wir die Migration auf das gesamte Unternehmen skalierten.\n\nDas Ergebnis war ein nahtloser Übergang zu GitLab, bei dem der gesamte Prozess innerhalb der geplanten Zeit abgeschlossen wurde und es zu keinen signifikanten Ausfallzeiten kam.\n\n## Lege jetzt mit Jira2Lab los\n\nJira2Lab hebt sich auf dem Markt dadurch ab, dass es genau auf die Einschränkungen eingeht, die andere Migrationstools nicht bewältigen können. Es wurde speziell für große Migrationen entwickelt und kann den kompletten DevSecOps-Lebenszyklus von GitLab integrieren  – anders als die meisten anderen Tools, die nur Projektmanagementdaten migrieren können. Da das Tool benutzerdefinierte Workflows abbilden und CI/CD-Pipelines integrieren kann, ist es die perfekte Lösung für Unternehmen, die ihre Entwicklungs-Workflows verbessern und gleichzeitig zu GitLab migrieren möchten.\n\n> Bist du bereit, deine Entwicklungsprozesse mit GitLab zu skalieren? Sieh dir unseren [Katalog für professionelle Services](https://about.gitlab.com/services/catalog/) an, um zu erfahren, wie wir deinem Team bei einer effizienten und effektiven Migration helfen können. Kontaktiere uns über das Formular am Ende dieser Seite, um eine personalisierte Demo von Jira2Lab von GitLab zu erhalten.\n",[834],"Maximilien Belinga","2025-06-24","2024-10-10","Von Jira zu GitLab wechseln: Der komplette Migrationsleitfaden 2025",[682,110,839,732,733],"DevSecOps","Atlassians Preiserhöhungen treiben viele Teams zu Alternativen. Entdecke, warum GitLab die bessere Wahl für moderne DevSecOps-Teams ist - mit mehr Features, integrierten Sicherheitstools und transparenter Preisgestaltung. Inklusive Schritt-für-Schritt-Migration mit Jira2Lab.",{"slug":842,"featured":92,"template":687},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:de-de:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":848,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":849,"content":855,"config":860,"_id":862,"_type":16,"title":863,"_source":17,"_file":864,"_stem":865,"_extension":20},"/de-de/blog/what-is-kanban",{"title":850,"description":851,"ogTitle":850,"ogDescription":851,"noIndex":6,"ogImage":852,"ogUrl":853,"ogSiteName":701,"ogType":702,"canonicalUrls":853,"schema":854},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663044/Blog/Hero%20Images/kanban.jpg","https://about.gitlab.com/blog/what-is-kanban","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-09-12\",\n      }",{"title":850,"description":851,"authors":856,"heroImage":852,"date":857,"body":858,"category":14,"tags":859},[707],"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/).",[682],{"slug":861,"featured":6,"template":687},"what-is-kanban","content:de-de:blog:what-is-kanban.yml","What Is Kanban","de-de/blog/what-is-kanban.yml","de-de/blog/what-is-kanban",{"_path":867,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":868,"content":873,"config":879,"_id":881,"_type":16,"title":882,"_source":17,"_file":883,"_stem":884,"_extension":20},"/de-de/blog/scrum-project-management-how-it-works",{"title":869,"description":870,"ogTitle":869,"ogDescription":870,"noIndex":6,"ogImage":699,"ogUrl":871,"ogSiteName":701,"ogType":702,"canonicalUrls":871,"schema":872},"Scrum-Projektmanagement: So geht’s","In der Welt des Projektmanagements ist Scrum zu einem Schlüsselbegriff geworden, der für Flexibilität, Effizienz und kontinuierliche Verbesserung steht.","https://about.gitlab.com/blog/scrum-project-management-how-it-works","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Scrum-Projektmanagement: So geht’s\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-08-21\",\n      }",{"title":869,"description":870,"authors":874,"heroImage":699,"date":875,"body":876,"category":14,"tags":877,"updatedDate":878},[707],"2024-08-21","Scrum ist jedoch mehr als nur eine Methode – es ist ein Framework, das den Teams ermöglicht, komplexe Projekte agil und erfolgreich zu bearbeiten.\n\n## Was ist Scrum-Projektmanagement?\n\nScrum ist wie der Rennwagen unter den Projektmanagementmethoden: schnell, flexibel und fokussiert. Es ist eine agile Methode, die darauf abzielt, komplexe Projekte in kurzen Iterationen, sogenannten Sprints, zu bewältigen. Diese Sprints ermöglichen es Teams, sich auf klare Ziele zu konzentrieren und gleichzeitig agil auf Veränderungen zu reagieren. Ursprünglich für die Softwareentwicklung ins Leben gerufen, hat sich Scrum mittlerweile in verschiedenen Branchen etabliert und wird für verschiedene Projekte, die nach einer agilen und iterativen Herangehensweise suchen, genutzt.\n\nDen Kern von Scrum bilden Prinzipien wie Transparenz, Inspektion und Anpassung. Das bedeutet, dass alle relevanten Informationen über den Projektfortschritt offengelegt werden, das Team seine Arbeit regelmäßig selbst überprüft und dann Anpassungen vornimmt, um stetig besser zu werden. Deshalb liegt ein wichtiger Fokus von Scrum auf der Zusammenarbeit. Statt endloser Planungsphasen und linearer Projektabwicklung setzt Scrum auf kurze Entwicklungszyklen. Diese dauern typischerweise ein bis vier Wochen und haben ein klares Ziel. Am Ende eines jeden Sprints wird ein greifbares Ergebnis präsentiert – so haben Teams einen konstanten Motivationsschub. \n\n## Das Scrum-Framework – Aufbau und Features\n\nUm das Scrum-Projektmanagement erfolgreich durchführen zu können, besteht das Scrum-Framework aus drei Hauptkomponenten: Rollen, Artefakten und Zeremonien.\n\n### Welche Rollen gibt es in Scrum?\n\nIn Scrum sind drei zentrale Rollen maßgeblich für den Erfolg bei der Umsetzung von Projekten:\n\n#### Product Owner\n\nProduct Owner spielen eine entscheidende Rolle im Scrum-Team und sind verantwortlich für die Maximierung des Produktwerts. Das bedeutet, dass die Person in dieser Position die Anforderungen des Projekts basierend auf den Bedürfnissen der Stakeholder und des Marktes definiert und priorisiert. Als Hauptansprechpartner(innen) für die Stakeholder arbeiten Product Owner eng mit ihnen zusammen, um sicherzustellen, dass das Produkt ihren Erwartungen entspricht und maximalen Nutzen bietet. Diese Rolle erfordert eine klare Vision, strategische Entscheidungsfindung und die Fähigkeit, Anforderungen effektiv zu kommunizieren und zu priorisieren.\n\n#### Entwicklungsteam\n\nDas Entwicklungsteam besteht aus den Expert(innen), die die eigentliche Entwicklungsarbeit leisten und das Produkt vorantreiben. Es ist selbstorganisiert und hat so die Freiheit, kreative Wege zu finden, um die Aufgaben aus dem Sprint-Backlog zu erledigen. Eigenverantwortung ist hier das A und O. Das Team verpflichtet sich, während jedes Sprints erstklassige Arbeit abzuliefern. Eine enge Zusammenarbeit und offene Kommunikation innerhalb des Teams sind entscheidend, um ein gemeinsames Verständnis der Anforderungen zu entwickeln und effektiv voranzukommen. Das Entwicklungsteam ist der Motor des Projekts und trägt die Hauptlast bei der Umsetzung der Produktanforderungen.\n\n#### Scrum Master\n\nScrum Master sind dafür da, das Scrum-Team zu unterstützen und sicherzustellen, dass es richtig Gas geben kann. Sie räumen Hindernisse aus dem Weg, die den Teamfortschritt behindern könnten, und schaffen eine Umgebung, in der Zusammenarbeit und ständige Verbesserung großgeschrieben werden. Außerdem helfen sie dem Team, die Prinzipien und Praktiken von Scrum zu durchdringen und umzusetzen. Das kann Schulungen, Workshops und regelmäßige Coaching-Sessions beinhalten, um sicherzustellen, dass das Team sein volles Potenzial entfalten kann.\n\nDiese drei Rollen ziehen im Scrum-Team an einem Strang, damit alle effektiv zusammenarbeiten und hochwertige Produkte in Rekordzeit auf den Markt gebracht werden. Die klare Verantwortungsaufteilung und die enge Zusammenarbeit sind Schlüssel dafür, dass das Team auf Hochtouren läuft und die Projektziele erreicht werden.\n\n### Was sind Scrum-Artefakte?\n\nScrum definiert eine Reihe von Artefakten, die dazu dienen, den Fortschritt des Projekts zu verfolgen und sicherzustellen, dass das Team in die richtige Richtung steuert.\n\n#### Product-Backlog\n\nHier sind sämtliche Anforderungen an das Projekt festgehalten, sei es in Form von User Stories, Features oder Aufgaben. Product Owner übernehmen die Verantwortung für die Pflege und Priorisierung dieses Backlogs, um zu gewährleisten, dass Teams stets an den wichtigsten Aspekten des Produkts arbeiten.\n\n#### Sprint-Backlog\n\nDer Sprint-Backlog ist die To-do-Liste für einen bestimmten Scrum-Sprint. Es werden die Aufgaben aufgeführt, die während dieses Zeitraums erledigt werden sollen. Das Entwicklungsteam wählt die Aufgaben aus dem Product-Backlog aus und verpflichtet sich, sie innerhalb des Sprints abzuschließen.\n\n#### Inkrement\n\nDas Inkrement ist das Ergebnis eines abgeschlossenen Sprints und stellt einen möglicherweise auslieferbaren Teil des Produkts dar. Es sollte eine funktionsfähige und getestete Version des Produkts sein, die den Product Ownern vorgestellt werden kann, um sicherzustellen, dass das Team die gestellten Anforderungen erfüllt hat.\n\n### Was sind Scrum Zeremonien?\n\nUm den Projektfortschritt zu synchronisieren und Hindernisse frühzeitig aus dem Weg zu räumen, organisiert ein Scrum-Team regelmäßig bestimmte Zeremonien, die die Effizienz und Transparenz des Entwicklungsprozesses maximieren:\n\n#### Sprint Planning\n\nBeim Sprint Planning legt das Team die Ziele fest und definiert den Umfang der Arbeit. Hier entscheidet das Team gemeinsam, welche Aufgaben vom Product-Backlog in den Sprint-Backlog aufgenommen werden. Die Product Owner klären die Anforderungen, und das Team schätzt den Aufwand ab, um zu bewerten, ob der Sprint realistische Ziele hat. Dabei verwenden die Teammitglieder Scrum Story Points als Maßeinheit, um den relativen Aufwand oder die Komplexität jeder Aufgabe zu bewerten. Durch diese Schätzungen können sie besser bewerten, wie viel Arbeit sie im Sprint durchführen können.\n\n#### Daily Scrum\n\nDas tägliche Stand-up-Meeting, auch als Daily Scrum bekannt, ist eine kurze Besprechung, um den Fortschritt zu besprechen und Hindernisse zu identifizieren. Jedes Teammitglied teilt mit, was seit dem letzten Meeting erreicht wurde, welche Herausforderungen es gibt und welche Aufgaben als Nächstes angegangen werden. Dies fördert die Kommunikation im Team und hilft, Hindernisse frühzeitig zu beseitigen.\n\n#### Sprint-Review\n\nAm Ende jedes Sprints findet die Sprint-Review statt, bei der das Team das abgeschlossene Inkrement präsentiert und Feedback von den Stakeholdern erhält. Hier demonstriert das Team die erledigte Arbeit und diskutiert Möglichkeiten zur Verbesserung. Die Stakeholder haben die Gelegenheit, Fragen zu stellen und Änderungsvorschläge zu machen, damit das Produkt bei der Fertigstellung den Anforderungen entspricht.\n\n#### Sprint Retrospective\n\nDie Sprint Retrospective ist eine Reflexionsveranstaltung, die nach der Sprint-Review stattfindet. Das Team reflektiert über den abgeschlossenen Scrum Sprint und identifiziert Verbesserungsmöglichkeiten für den nächsten. Dabei werden Erfolge, Probleme und Lernpunkte diskutiert, um Erkenntnisse zu gewinnen und den Entwicklungsprozess kontinuierlich zu verbessern.\n\nDiese Zeremonien sind entscheidend dafür, dass das Scrum-Team transparent arbeitet, sich regelmäßig über den Fortschritt austauscht und kontinuierlich an seiner Leistungsfähigkeit arbeitet. Durch die klare Struktur und den regelmäßigen Austausch werden Hindernisse frühzeitig erkannt und beseitigt, was zu einem effizienteren und produktiveren Entwicklungsprozess führt.\n\n## Warum Scrum nutzen?\n\nScrum bietet für [DevOps](https://about.gitlab.com/de-de/topics/devops/ \"DevOps\")-Teams viele Vorzüge, darunter Flexibilität, klare Kommunikation und regelmäßige Wertlieferung. Doch es ist wichtig zu beachten, dass die Einführung von Scrum auch einige Herausforderungen mit sich bringen kann, wie die Anpassung an neue Rollen und Prozesse. Deshalb ist es entscheidend, dass das Team gründlich geplant und geschult wird, da eine effektive Nutzung der Scrum-Methode dies voraussetzt.\n\n### Vorteile von Scrum\n\n- __Flexibilität und Anpassungsfähigkeit:__ Mit Scrum können DevOps-Teams blitzschnell auf neue Anforderungen reagieren und sich an veränderte Bedingungen anpassen. Kurze Iterationen und regelmäßige Check-ins machen das Team besonders agil.\n- __Klare Kommunikation:__ Durch regelmäßige Meetings wie dem Daily Scrum und Sprint-Reviews herrscht in einem Scrum-Team eine offene Kommunikationskultur. Das hilft, Hindernisse frühzeitig zu erkennen und die Teamarbeit zu verbessern.\n- __Kontinuierliche Lieferung von Mehrwert:__ Scrum stellt sicher, dass DevOps-Teams kontinuierlich wertvolle Funktionen liefern. Das bedeutet, dass Kund(inn)en regelmäßig mit neuen Features versorgt werden und der Wert des Produkts kontinuierlich steigt.\n- __Effiziente Ressourcennutzung:__ Dank der klaren Priorisierung im Product-Backlog können DevOps-Teams ihre Ressourcen effizient nutzen und sich auf die wichtigsten Aufgaben konzentrieren.\n- __Stärkung der Teamdynamik:__ Scrum fördert Selbstorganisation und Eigenverantwortung im Team. Das steigert die Motivation und das Engagement der Teammitglieder und verbessert die Zusammenarbeit deutlich.\n\n### Potenzielle Nachteile von Scrum\n\n- __Komplexität der Einführung:__ Die Einführung von Scrum erfordert oft einen kulturellen Wandel und kann anfangs recht komplex sein. Es braucht Zeit und Ressourcen, bis sich das Team an die neuen Prozesse und Rollen gewöhnt hat.\n- __Anforderungen an die Teamgröße:__ Scrum funktioniert am verlässlichsten mit Teams von bestimmter Größe. Zu kleine Teams könnten überlastet sein, während zu große Teams möglicherweise weniger effektiv arbeiten könnten.\n- __Risiko von Missverständnissen:__ Bei einer falschen Implementierung von Scrum oder unklaren Rollen kann es zu Missverständnissen und Frustration im Team kommen.\n- __Hoher Kommunikationsaufwand:__ Regelmäßige Meetings und offene Kommunikation können viel Zeit in Anspruch nehmen, wenn sie ineffizient gestaltet werden.\n- __Vorhersagbarkeit:__ Aufgrund der agilen Natur von Scrum kann es schwierig sein, genaue Vorhersagen über die Fertigstellung von Aufgaben oder Features zu treffen. Das kann zu Unsicherheiten bei der Planung und Budgetierung führen.\n\n## Scrum vs. Kanban vs. Agilität: Ein Vergleich der agilen Ansätze\n\nScrum, Agile und Kanban sind drei verschiedene Ansätze für das Projektmanagement, die sich jeweils durch einzigartige Merkmale auszeichnen.\n\n### Scrum\n\nScrum zeichnet sich durch seine strukturierten Zeitrahmen, bekannt als Sprints, aus. Innerhalb dieser Sprints arbeitet das Team an einer klar definierten Anzahl von Aufgaben, um am Ende des Sprints ein funktionsfähiges Produktinkrement zu liefern. Scrum arbeitet dabei mit Rollen wie Product Ownern, welche die Anforderungen priorisieren, dem Entwicklungsteam, das die Arbeit ausführt, und den Scrum Mastern, die das Team unterstützen. Die klare Rollenverteilung und die festen Zeitrahmen helfen, den Entwicklungsprozess zu organisieren und zu steuern.\n\n### Kanban\n\nKanban hingegen konzentriert sich auf die Visualisierung des Arbeitsflusses und die kontinuierliche Lieferung von Arbeit. Es gibt keine festen Zeitrahmen wie in Scrum. Stattdessen zeigt das Kanban-Board den aktuellen Status jedes Arbeitselements an, und das Team zieht kontinuierlich neue Aufgaben in den Arbeitsprozess, sobald Kapazitäten frei werden. Kanban bietet Flexibilität und ermöglicht es Teams, sich schnell an sich ändernde Anforderungen anzupassen und den Arbeitsfluss kontinuierlich zu verbessern.\n\n### Agilität\n\nAgilität hingegen betont Flexibilität, Selbstorganisation und kontinuierliche Verbesserung als übergeordneten Ansatz. Anders als bei Scrum gibt es hier keine festen Methoden oder Rahmenwerke, sondern ein Mindset, das auf Werten und Prinzipien basiert. Agile Methoden wie Scrum sind Teil dieses Ansatzes, neben anderen wie Extreme Programming (XP) oder Lean, die verschiedene Techniken umfassen.\n\n## Scrum Management mit GitLab\nGitLab bietet eine umfassende [Plattform für das DevOps-Lifecycle-Management](https://about.gitlab.com/de-de/platform/ \"Plattform für das DevOps-Lifecycle-Management\"). Neben Funktionen für die Versionskontrolle, [Continuous Integration](https://about.gitlab.com/de-de/solutions/continuous-integration/ \"Continuous Integration\") und Deployment stellt GitLab auch Projektmanagement-Tools bereit. Eines dieser Tools ist das Scrum-Management, das eine agile Projektmanagementmethode unterstützt. GitLab integriert Scrum-Management nahtlos in seine Plattform, was es Teams ermöglicht, Projekte effizient zu planen, zu verfolgen und zu verwalten.\n\nDurch die Verwendung von GitLab für das Scrum Management können Teams Backlogs verwalten, Sprints planen, Aufgaben zuweisen und den Fortschritt von Projekten in Echtzeit verfolgen. Außerdem ermöglicht die Integration von GitLab mit anderen DevOps-Tools eine nahtlose Zusammenarbeit zwischen Entwicklung, Qualitätssicherung und Betrieb.\n\n## Scrum Management – FAQs\n\n### Ist Scrum eine agile Methode?\n\nScrum ist eine agile Methode. Sie wird als agil betrachtet, weil sie die Grundsätze des Agilen Manifests unterstützt, das eine Reihe von Werten und Prinzipien für die agile Softwareentwicklung definiert. Scrum fördert die iterative Entwicklung, enge Zusammenarbeit im Team, Flexibilität bei der Anpassung an Änderungen und die kontinuierliche Verbesserung des Prozesses.\n\n### Wie lange dauert ein typischer Sprint und wie werden Sprints geplant?\n\nDie Dauer eines typischen Sprints in Scrum liegt normalerweise zwischen ein bis vier Wochen. Diese Zeitspanne wird vom Scrum-Team bestimmt und kann je nach den Projektanforderungen und den Präferenzen des Teams variieren. Manche Teams ziehen kürzere Sprints von einer Woche vor, während andere längere Sprints von vier Wochen wählen.\n\nDie Planung eines Sprints erfolgt während eines speziellen Meetings, das als Sprint Planning Meeting bekannt ist. Dabei setzt sich das Scrum-Team zusammen, um die Ziele für den kommenden Sprint festzulegen und die Aufgaben aus dem Produkt-Backlog auszuwählen, die während des Sprints erledigt werden sollen.\n\n### Wie geht ein Scrum-Team mit Änderungen während eines laufenden Sprints um?\n\nEin Scrum-Team geht mit Änderungen während eines laufenden Sprints flexibel um:\n\n__1. Identifizierung:__ Eine Änderungsanfrage wird erkannt, priorisiert und ins Product-Backlog aufgenommen.\n\n__2. Anpassung des Sprint-Backlogs:__ Falls nötig, wird das Sprint-Backlog angepasst, um Platz für die Änderung zu schaffen.\n\n__3. Teamkonsens:__ Das Team entscheidet gemeinsam, ob und wie die Änderung umgesetzt wird, unter Berücksichtigung der Sprint-Ziele und potenzieller Risiken.\n\n__4. Transparente Kommunikation:__ Alle Stakeholder werden über die Änderungen informiert, einschließlich einer möglichen Anpassung des Sprint-Ziels.\n",[682],"2024-12-19",{"slug":880,"featured":6,"template":687},"scrum-project-management-how-it-works","content:de-de:blog:scrum-project-management-how-it-works.yml","Scrum Project Management How It Works","de-de/blog/scrum-project-management-how-it-works.yml","de-de/blog/scrum-project-management-how-it-works",{"_path":886,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":887,"content":893,"config":900,"_id":902,"_type":16,"title":903,"_source":17,"_file":904,"_stem":905,"_extension":20},"/de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"ogTitle":888,"schema":889,"ogImage":890,"ogDescription":891,"ogSiteName":701,"noIndex":6,"ogType":702,"ogUrl":892,"title":888,"canonicalUrls":892,"description":891},"Skalierbare Unternehmenshierarchien: Bewährte Methoden","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bewährte Methoden zum Einrichten von Unternehmenshierarchien, die skalierbar sind\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","Erfahre, wie du eine Organisationshierarchie in GitLab modellierst. Erstelle Strukturen mit klaren Kommunikationslinien, strategischer Ausrichtung und mehr und halte gleichzeitig die Prinzipien der Agile-Methodik ein.","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"heroImage":890,"body":894,"authors":895,"updatedDate":896,"date":897,"title":898,"tags":899,"description":891,"category":14},"Um die Vorteile deines GitLab-Abonnements optimal zu nutzen, muss dein Unternehmen effektiv eingerichtet werden. Hier findest du eine einfache Anleitung, um deine Gruppen-, Untergruppen und Projektstruktur zu konfigurieren und so dein GitLab-Erlebnis zu optimieren.\n\n## Struktur verstehen: Gruppen, Untergruppen und Projekte\n\nMit Gruppen und Projekten kannst du deine Organisationshierarchie nachbilden, eine erweiterte Berechtigungsverwaltung ermöglichen und eine Planung eines „Teams von Teams“ entwickeln. Verwende Gruppen und Untergruppen für die strategische Planung und ein Konfigurationsmanagement, das sich in Untergruppen und Projekte, die weiter unten in der Hierarchie stehen, untergliedert.\n\nDarüber hinaus kannst du auch deine Wertschöpfungsketten nachbilden, das Projektmanagement optimieren sowie die Zusammenarbeit in deinem Unternehmen verbessern.\n\n- **Projektebene (Teamebene)**\n    - Projekte sind innerhalb von Gruppen oder Untergruppen verschachtelt und sind der Ort, an dem deine eigentliche Arbeit erfolgt. Hier befinden sich Repositories und die projektspezifischen Einstellungen werden hier verwaltet. Auf dieser Ebene erhältst du Einblick in die täglichen Aktivitäten und die detaillierte Projektverfolgung.\n    - Eine effektive Projektkonfiguration sorgt für klare, organisierte Daten, die wiederum unerlässlich für genaue Berichte und Analysen sind.\n\n- **Untergruppenebene (Team aus Teams)**\n    - Untergruppen bieten eine granulare Berechtigungsverwaltung und können an die Anforderungen bestimmter Teams und Projekte angepasst werden. So stellen sie einen konsistenten Workflow im gesamten Unternehmen sicher. \n    - Untergruppen fungieren als Cluster verwandter Projekte, ähnlich wie ein „Team von Teams“ in Agile. \n    - Diese Ebene ist ideal für die Verwaltung mehrerer Teams, die an einem gemeinsamen Produkt oder einen gemeinsamen Dienst arbeiten. Sie erleichtert die projektübergreifende Sichtbarkeit und Integration, was die Synchronisation zwischen Teams unterstützt, um Abhängigkeiten oder gemeinsame Ziele abzustimmen.\n\n- **Gruppenebene (Team aus Team aus Teams)**\n    - Stell dir Gruppen als organisatorische Säulen in GitLab vor, mit denen breite Berechtigungen und Zugriffsrechte verwaltet werden.\n    - Auf höchster Ebene umfassen Gruppen mehrere Untergruppen und sind die strategische Ebene im Projektmanagement, ähnlich wie „Team aus Team aus Teams“ in Agile.\n    - In dieser Stufe werden übergeordnete Ziele und Strategien festgelegt, Einstellungen definiert und Ressourcen über Projekte und Untergruppen übergreifend zugewiesen, um sicherzustellen, dass diese den übergeordneten Geschäftszielen entsprechen.\n\nIndem du dein Unternehmen mit GitLab strukturierst, bildest du deine gewählte Agile Methodik ab. Dies kann dir dabei helfen, die Agile-Prinzipien selbstverständlicher in deinen Projekten umzusetzen. Diese Struktur fördert klare Kommunikationslinien, effektives Ressourcenmanagement und eine strategische Ausrichtung, während gleichzeitig die Flexibilität und Reaktionsschnelligkeit, die für Agile Methoden ausschlaggebend sind, beibehalten werden.\n\n> Informiere dich über Neuigkeiten und Erkenntnisse zur [Agile Planung mit GitLab](https://about.gitlab.com/blog/categories/agile-planning/).\n\n## Nutzung des GitLab-Vererbungsmodells\n\nEine der leistungsstarken Funktionen von GitLab ist das [Vererbungsmodell](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab), mit dem Einstellungen, Berechtigungen und Konfigurationen auf höheren Ebenen automatisch auf niedrigere Ebenen in der Hierarchie angewendet werden können. Umgekehrt stehen Daten auf niedrigeren Ebenen sofort auf höheren Ebenen in der Struktur zur Verfügung. Mit dem Vererbungsmodell erhältst du aus übergeordneten Gruppen Sichtbarkeit über das gesamte Portfolio und stellst weiter unten in der Hierarchie eigene Orte bereit, in denen die einzelnen Teams ihre Arbeit verwalten können.\n\nBeispiele:\n- **Erstelle Meilensteine und Labels in deinen höheren Gruppen**, um diese auf alle Untergruppen und Projekte zu verteilen. So förderst du Konsistenz und die Einhaltung von Unternehmensstandards.\n- **Tickets und Epics** in untergeordneten Projekten und Untergruppen werden in der Wertstromhierarchie nach oben befördert, damit das Programm-Management und die Führungsebene leichter darauf zugreifen können. \n- **Verwalte Benutzerberechtigungen auf Gruppenebene oder in der Hauptuntergruppe**, um die Berechtigungen und die Zugriffskontrolle zu optimieren. Dadurch kann die Verwaltung der Zugangskontrolle vereinfacht und sichergestellt werden, dass die richtigen Personen über mehrere Projekte hinweg den richtigen Zugriff haben, ohne dass die Konfiguration mehrfach vorgenommen werden muss.\n\nDiese Tipps optimieren nicht nur den Verwaltungsaufwand, sondern verbessern auch Sicherheit und Compliance, indem sichergestellt wird, dass Änderungen auf einer höheren Ebene immer auch auf untergordnete Hierarchieebenen übertragen werden.\n\n![Organisatorisches Hierarchiediagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## Bewährte Methoden für die Einrichtung von GitLab\n\nWenn du deine GitLab-Organisationshierarchie einrichtest, solltest du je nach den Bedürfnissen deines Unternehmens die folgenden Optionen beachten. Self-Managed-Kund(inn)en können die Root-Gruppen-Ebene „Unternehmensname“ weglassen, da diese zusätzliche Organisationsebene für Self-Managed-Bereitstellungen nicht nötig ist. Durch diese Flexibilität kannst du sicherstellen, dass dein GitLap-Setup an deine spezifische Unternehmensstruktur und Präferenzen bei der Bereitstellung angepasst ist.\n\n### Option 1: Berechtigungen und Zugriffsrechte werden auf der Ebene der Organisationsuntergruppe vergeben\n\nDiese Option ist ideale für komplexe Berechtigungsstrukturen oder große Unternehmen, bei denen zahlreiche Benutzer(innen) effizient gemeinsam an Projekten arbeiten müssen.\n\n#### Beispielstruktur\n\n- Organisationsgruppe \n    - Verarbeitet umfassende Berechtigungen normalerweise durch die Integration mit den Bereitstellungssystemen des Unternehmens.\n    - Benutzer(innen) werden zu Untergruppen hinzugefügt, die als Grundlage für die gemeinsame Nutzung der gesamten Gruppe mit einer anderen [Gruppe](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) oder einem [Projekt](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html) dienen, um den Aufwand für die direkte Benutzerverwaltung zu minimieren.\n    - Wenn du Benutzergruppen erstellst, kannst du [Gruppenerwähnungen](https://docs.gitlab.com/ee/user/discussions/index.html#mentions) in GitLab verwenden, um große Benutzergruppen gleichzeitig zu erwähnen.\n\n- Entwicklungsgruppe\n    - Bietet Transparenz auf Führungsebene und Programm-Management-Ebene über alle Entwicklungsprojekte auf Ebene der Hauptentwicklungsgruppe.\n    - Funktionen werden auf Untergruppenebene für den Zugriff über mehrere Repos hinweg erstellt.\n    - Es werden Projekte erstellt, die Entwicklungs-Repos enthalten. Dies ist die Ebene für die Teamsichtbarkeit.\n\n![Organigramm für Untergruppenebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### Option 2: Berechtigungen und Zugriffsrechte werden auf jeder Ebene vergeben\nDiese Option ist am besten für kleinere Unternehmen mit weniger komplexen Zugriffsanforderungen geeignet. Benutzer(innen) werden einzeln zu den Bereichsgruppen, Untergruppen oder Projekten hinzugefügt, wenn ein Zugriff erforderlich ist. Dies ermöglicht direkte Kontrolle über das Projektmanagement und die betriebliche Sichtbarkeit.\n\n#### Highlights\n- Benutzer(innen) können je nach Granularität der Zugriffsanforderungen einer übergeordneten Gruppe oder einer untergeordneten Untergruppe/einem Projekt hinzugefügt werden. Jedes Mitglied müsste einzeln hinzugefügt werden, anstatt mit einer Aufgabe eine ganze Gruppe zu teilen.\n- Transparenz auf Führungsebene und Programm-Management-Ebene über alle Entwicklungsprojekte in der Hauptentwicklungsgruppe.\n- Funktionen werden auf Untergruppenebene für den Zugriff über mehrere Repos hinweg erstellt.\n- Es werden Projekte erstellt, die Entwicklungs-Repos enthalten. Dies ist die Ebene für die Teamsichtbarkeit.\n\n![Berechtigungen auf jeder Ebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n### Zusätzliche Konfigurationsüberlegungen\n\n- Meilensteine und Iterationen \n    - Erstelle Meilensteine auf Gruppenebene für eine breite Sichtbarkeit oder wenn Meilensteine gruppenübergreifend geteilt werden müssen.  \n    - Erstelle Meilensteine auf Projektebene, wenn der Meilenstein für ein einzelnes Projekt spezifisch ist. \n    - Für Teams, die über verschiedene Gruppen hinweg arbeiten, ist es von Vorteil, Iterationen auf der Ebene der übergeordneten Gruppe festzulegen, um eine einheitliche Nachverfolgung zu ermöglichen.\n\n- Datenverwaltung \n    - Nutze die Roadmaps, Übersichten und Listen von GitLab, um Daten abzurufen, die dein Unternehmens-Setup widerspiegeln. Damit kannst du den Fortschritt visualisieren und effektiv über verschiedene Ebenen deiner Struktur hinweg planen. \n    - GitLab stellt Daten in übergeordneten Gruppen zur Verfügung, auch wenn die Daten auf niedrigeren Ebenen erstellt werden. \n    - Erstelle deine Ansichten auf höheren Ebenen, wenn du Daten gruppen- und projektübergreifend anzeigen möchtest, und auf niedrigeren Ebenen, wenn du die Daten nur für eine bestimmte Gruppe oder ein bestimmtes Projekt nutzen möchtest.\n\n- Erstellung von Vorlagen \n    - Erstelle Vorlagen auf höheren Ebenen, um sicherzustellen, dass sie für alle untergeordneten Untergruppen und Projekte kaskadiert werden, wobei allgemeine Richtlinien mit projektspezifischen Anforderungen kombiniert werden.\n    - Vorlagen werden in ihrem eigenen Repository innerhalb der entsprechenden Gruppe erstellt ([zugehörige Dokumentation](https://docs.gitlab.com/ee/user/project/description_templates.html)).\n\n- Labels \n    - Erstelle Labels auf höheren Ebenen, um sicherzustellen, dass sie für alle untergeordneten Untergruppen und Projekte kaskadiert werden, wobei Unternehmenslabels mit projektspezifischen Labels gemischt werden.\n    - Verwende Labels mit begrenztem Geltungsbereich, um Organisationsstrukturen wie Teams und den Workflow-Status zu definieren.\n\n![Issue-Übersicht mit Labels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## Nutze die Funktionen von GitLab für optimale Performance\n\nWenn du die richtige Struktur in GitLab implementierst, optimierst du nicht nur das Management deiner Softwareprojekte, sonder verbesserst auch die Sichtbarkeit auf den verschiedenen Ebenen deines Unternehmens. So kann sichergestellt werden, dass alle vom obersten Management bis zu den einzelnen Mitwirkenden die Informationen haben, die sie für fundierte Entscheidungen brauchen. \n\n> Starte noch heute und modelliere deine Organisationshierarchie [mit einer kostenlosen Testversion von GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[728],"2024-11-19","2024-07-22","Bewährte Methoden zum Einrichten von Unternehmenshierarchien, die skalierbar sind",[682,732,683],{"slug":901,"featured":6,"template":687},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:de-de:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":907,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":914,"config":921,"_id":923,"_type":16,"title":924,"_source":17,"_file":925,"_stem":926,"_extension":20},"/de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"ogTitle":909,"schema":910,"ogImage":911,"ogDescription":912,"ogSiteName":701,"noIndex":6,"ogType":702,"ogUrl":913,"title":909,"canonicalUrls":913,"description":912},"GitLab Agile-Planung verbessert kollaboratives Management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So verbessert die Agile-Planung von GitLab das kollaborative Projektmanagement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-16\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097041/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2822%29_718ZuurL0op4weunB2fBlD_1750097040694.png","Die Transformation, die GitLab für das Projektmanagement mit sich bringt, ist nicht nur die Verwendung eines Tools, sondern die Förderung einer Kultur der Zusammenarbeit und kontinuierlichen Verbesserung. Hier erfährst du, wie.","https://about.gitlab.com/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"heroImage":911,"body":915,"authors":916,"updatedDate":917,"date":918,"title":919,"tags":920,"description":912,"category":14},"Effektive Zusammenarbeit ist das Rückgrat des agilen Projektmanagements und ermöglicht es Unternehmensteams, qualitativ hochwertige Software effizient zu liefern. Die umfassende Plattform von GitLab verbessert die Zusammenarbeit, optimiert Workflows und unterstützt [Agile-Prinzipien](https://about.gitlab.com/de-de/solutions/agile-delivery/). In diesem Artikel erfährst du, wie GitLab Teams in die Lage versetzt, nahtlos zusammenzuarbeiten und Projektergebnisse zu verbessern.\n\n## Der Wert des kollaborativen Projektmanagements für Agile-Teams in Unternehmen \n\nDie Einführung kollaborativer Projektmanagementpraktiken ist für Agile-Teams unerlässlich, um in den dynamischen Entwicklungsumgebungen von heute erfolgreich zu sein. Hier erfährst du, warum das wichtig ist und wie GitLab Enterprise Agile Planning Unternehmen dabei hilft:\n\n- **Verbesserte Kommunikation:** Zusammenarbeit sorgt für einen reibungslosen Kommunikationsfluss zwischen allen Teammitgliedern, verhindert Missverständnisse und richtet alle auf gemeinsame Ziele aus. Dies ist in Agile-Unternehmensumgebungen, in denen schnelle Iterationen und kontinuierliches Feedback entscheidend sind, unerlässlich.\n  - *Durch die Aufteilung von Epics und die Verwendung von Kommentaren in Threads in GitLab sind alle auf dem gleichen Stand und es werden detaillierte Diskussionen innerhalb von Tickets gefördert.*\n- **Erhöhte Effizienz:** Durch die Förderung einer kollaborativen Atmosphäre können Teams die einzigartigen Fähigkeiten und das Fachwissen jedes Mitglieds nutzen, was zu einer schnelleren Problemlösung und Aufgabenerledigung führt. Tools für Zusammenarbeit optimieren Workflows, reduzieren Engpässe und ermöglichen es Teams, schneller Werte zu schaffen.\t\n  - *Die einheitliche Plattform von GitLab integriert alle Aspekte der Entwicklung, von der Planung bis zur Bereitstellung, und sorgt so für optimierte und effiziente Workflows.*\n\n- **Verbesserte Entscheidungsfindung:** Wenn Teammitglieder eng zusammenarbeiten, können sie unterschiedliche Perspektiven und Erkenntnisse austauschen, was zu einer besseren Entscheidungsfindung führt. Zusammenarbeit fördert eine Kultur der kollektiven Intelligenz, in der die besten Ideen identifiziert und umgesetzt werden.\n  - *Die Issue-Übersichten und Labels von GitLab helfen bei der Organisation und Priorisierung von Ideen und erleichtern die Bewertung von Optionen und das Treffen fundierter Entscheidungen.*\n- **Bessere Moral und mehr Engagement:** Die Arbeit in einer kollaborativen Umgebung, in der Beiträge geschätzt werden, kann die Moral und das Engagement des Teams erheblich steigern. Agile-Teams, die effektiv zusammenarbeiten, sind motivierter, fühlen sich stärker verantwortlich und setzen sich mehr für den Projekterfolg ein.\n  - *Erfolge können durch die Verknüpfung mit Beiträgen und Aktivitäten von Teammitgliedern in GitLab anerkannt und gefeiert werden.*\n- **Bessere Ergebnisse:** Gemeinsame Anstrengungen führen oft zu qualitativ hochwertigeren Ergebnissen. Kontinuierliches Feedback und Peer Reviews stellen sicher, dass Probleme frühzeitig erkannt und umgehend behoben werden, was zu ausgereifteren und robusteren Produkten führt.\n  - *Die Meilensteinverfolgung und die Projektvorlagen von GitLab gewährleisten projektübergreifend einheitliche Qualitätsstandards und ermöglichen gründliche Überprüfungen und Standardisierungen.*\n- **Anpassungsfähigkeit und Flexibilität:** Agile-Teams müssen in der Lage sein, schnell auf Feedback zu reagieren und sich an sich ändernde Anforderungen anzupassen. Zusammenarbeit bietet die Flexibilität, Pläne und Strategien in Echtzeit anzupassen, um sicherzustellen, dass das Team reaktionsfähig bleibt und sich an den Projektzielen orientiert.\n  - *Die Roadmaps und dynamischen Planungsfunktionen von GitLab ermöglichen die Anpassung von Zeitplänen und Prioritäten im laufenden Betrieb, sodass das Team agil bleibt und auf Veränderungen reagieren kann.*\n\nAls Produktmanagerin habe ich aus erster Hand erlebt, wie diese Vorteile die Leistung eines Teams verändern können. Durch die Integration dieser kollaborativen Praktiken können Agile-Teams ihre Produktivität, Innovation und den allgemeinen Projekterfolg steigern.\n\n> Sieh dir die [Updates und Einblicke zur Agile-Planung von GitLab an](https://about.gitlab.com/de-de/blog/categories/agile-planning/).\n\n## Mit GitLab zum Erfolg in der Agile-Softwareentwicklung \n\nGitLab ist mit seiner umfassenden Suite von Tools perfekt positioniert, um diese Zusammenarbeit zu unterstützen.\n\n- **Optimierte Agile-Entwicklung:** GitLab unterstützt die hierarchische Planung und ermöglicht es Teams, Projekte in Epics zu strukturieren, die dann in Funktionen, User Storys und Aufgaben unterteilt werden können. Diese klare Organisation stellt sicher, dass komplexe Projekte überschaubar und transparent sind, und fördert die kontinuierliche schrittweise Wertschöpfung. Durch die Aufteilung der Arbeit in detaillierte Segmente hilft GitLab Agile-Teams, fokussiert zu bleiben und Ziele effizient zu erreichen.\n\n![Verschachtelte Liste von Epics und untergeordneten Tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097050298.png)\n\n- **Verbesserte Sichtbarkeit und Verantwortlichkeit:** Das Management von Abhängigkeiten ist für funktionsübergreifende Initiativen von entscheidender Bedeutung. Die Tools von GitLab zum Erstellen, Verfolgen und Visualisieren von Abhängigkeiten vermitteln den Teammitgliedern ein klares Verständnis dafür, wie ihre Arbeit in das Gesamtprojekt passt. Diese Sichtbarkeit verhindert Engpässe und sorgt dafür, dass die Bemühungen mit den Projektzielen in Einklang stehen, was die Verantwortlichkeit und den koordinierten Fortschritt fördert.\n\n![Screenshot mit Abhängigkeiten für Initiativen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097050300.png)\n\n- **Einheitliche Plattform für alle Benutzer(innen):** GitLab vereint alle Beteiligten auf einer einzigen Plattform und beseitigt so die Silos, die oft durch die Verwendung unterschiedlicher Tools entstehen. Dies verbessert die Kommunikation und Zusammenarbeit zwischen den Teams. Ganz gleich, ob du Entwickler(in), Projektmanager(in), Qualitätssicherungsspezialist(in) oder UX-Designer(in) bist, GitLab stellt sicher, dass alle auf dieselben Daten und Tools zugreifen können, und fördert so eine kohärentere Arbeitsumgebung.\n\n- ** Zusammenarbeit und Kommunikation in Echtzeit:** GitLab unterstützt die Zusammenarbeit in Echtzeit durch Funktionen wie Merge Requests, Ticketverfolgung und Pipelines für die kontinuierliche Integration und Bereitstellung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)). Diese Funktionen optimieren den Entwicklungsprozess und fördern kontinuierliches Feedback und iterative Verbesserungen. Integrierter Chat, Kommentare zu Merge Requests und Echtzeit-Benachrichtigungen stellen sicher, dass alle Beteiligten auf dem Laufenden bleiben und an einem Strang ziehen.\n\n![Screenshot eines Chat-Gesprächs zwischen Produkt-, Entwicklungs- und Designteams](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097050305.png)\n\n- **Datengestützte Entscheidungsfindung und kontinuierliche Verbesserung:** Jede Aktion in GitLab kann gemessen werden und liefert wertvolle Erkenntnisse, die als Leitfaden für die strategische Planung und operative Anpassungen dienen. Mit den [Analysefunktionen von GitLab](https://about.gitlab.com/de-de/solutions/value-stream-management/) können Teams Key-Performance-Indicators wie Bearbeitungszeiten und Häufigkeit der Bereitstellung überwachen. Dieser datengesteuerte Ansatz stellt sicher, dass Entscheidungen auf Fakten und nicht auf Annahmen basieren, was den Lean-Prinzipien entspricht und kontinuierliche Verbesserungen fördert.\n\n![Dashboard für die Wertstromanalyse](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097050308.png)\n\n## Starte deine Agile-Unternehmenstransformation\n\nDie Transformation, die GitLab für das Projektmanagement mit sich bringt, ist aufregend. Es geht nicht nur um die Verwendung eines Tools, sondern um die Förderung einer Kultur der Zusammenarbeit und kontinuierlichen Verbesserung. Es war unglaublich bereichernd zu sehen, wie meine Teams von isolierten Bemühungen zu einer einheitlichen, effizienten und motivierten Belegschaft übergegangen sind.\n\nGitLab definiert kollaboratives Projektmanagement neu, indem es umfassende Planungswerkzeuge mit Echtzeit-Funktionen für die Zusammenarbeit in einer einzigen Plattform integriert. Dies fügt sich nahtlos in Agile-Praktiken ein und ermöglicht es Teams, Projekte effizienter und präziser zu verwalten. Für Unternehmen jeder Größe bietet GitLab die erforderlichen Werkzeuge, um die Komplexität der modernen Softwareentwicklung zu bewältigen und eine erfolgreiche und termingerechte Projektabwicklung zu gewährleisten.\n\n> Starte noch heute mit GitLab Enterprise Agile Planning [mit einer kostenlosen Testversion von GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).",[728],"2024-10-31","2024-07-16","So verbessert die Agile-Planung von GitLab das kollaborative Projektmanagement",[682],{"slug":922,"featured":92,"template":687},"how-gitlab-agile-planning-improves-collaborative-project-management","content:de-de:blog:how-gitlab-agile-planning-improves-collaborative-project-management.yml","How Gitlab Agile Planning Improves Collaborative Project Management","de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management.yml","de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"_path":928,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":929,"content":935,"config":941,"_id":943,"_type":16,"title":944,"_source":17,"_file":945,"_stem":946,"_extension":20},"/de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"title":930,"description":931,"ogTitle":930,"ogDescription":931,"noIndex":6,"ogImage":932,"ogUrl":933,"ogSiteName":701,"ogType":702,"canonicalUrls":933,"schema":934},"Wir stellen euch die neue Epic-Erfahrung für verbessertes Agile Planning vor","Ein Update für GitLab Epics, mit dem die Planung verbessert wird und deine Workflows optimiert werden durch nahtlose Migration, die ein besseres Projektmanagement ermöglicht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660011/Blog/Hero%20Images/blog-image-template-1800x945__21_.png","https://about.gitlab.com/blog/unveiling-a-new-epic-experience-for-improved-agile-planning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wir stellen euch die neue Epic-Erfahrung für verbessertes Agile Planning vor\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-03\",\n      }",{"title":930,"description":931,"authors":936,"heroImage":932,"date":937,"body":938,"category":14,"tags":939,"updatedDate":940},[728],"2024-07-03","Auf unserem kontinuierlichen Weg zu besserem Agile Planning in GitLab haben wir [kürzlich einen neuen Look vorgestellt](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/) (englischsprachiger Artikel). Dieses Update ist ein wichtiger Schritt hin zu einem vereinheitlichten, flexiblen Planungstool, das an deine Bedürfnisse angepasst ist. In diesem Artikel sehen wir uns einen entscheidenden Teil der Initiative an: die neue Epic-Erfahrung. \n\nDu erfährst mehr über die demnächst verfügbaren Funktionen von Epics und die Motivation hinter diesen Änderungen, die deine Projektmanagement-Möglichkeiten erweitern sollen.\n\n## Warum die neue Epic-Erfahrung?\n\n### Reaktion auf Feedback von Benutzer(innen)\nIm Rahmen unserer Mission, ein umfassendes Erlebnis für Agile Planning zu bieten, haben wir uns euer Feedback genau angehört. Benutzer(innen) haben von Schwierigkeiten mit der aktuellen Epic-Implementierung berichtet, wie zum Beispiel inkonsistente Funktionen zwischen Epics und Tickets sowie fehlende Flexibilität für unterschiedliche Workflows. Einige Probleme betrafen Workflow-Tools, wie zum Beispiel fehlende Beauftragte bei Epics, sowie fehlende wiederverwendbare Vorlagen. Die neue Epic-Erfahrung soll diese Probleme beheben und das Agile Planning intuitiver und effizienter machen.\n\n### Vereinheitlichtes Workitem-Framework\nUm diese Probleme zu beheben, haben wir ein vereinheitlichtes Workitem-Framework eingeführt. Diese neue Architektur garantiert Konsistenz übergreifend über alle Planungsobjekte – Epics, Tickets und Aufgaben – und vereinfacht so das Benutzererlebnis, während gleichzeitig die Funktionalität verbessert wird. Durch die Konsolidierung des zugrundeliegenden Codes können wir neue Funktionen und Verbesserungen schneller bereitstellen und ermöglichen so einen reibungsloseren, zuverlässigeren Planungsprozess.\n\n> Erfahre mehr darüber, [was dich mit Agile Planning von GitLab erwartet](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/) (englischsprachiger Artikel).\n\n## Hauptfunktionen der neuen Epic-Erfahrung\n\n### Erweiterte Detailseite\nEine der gravierendsten Änderungen ist die überarbeitete Epic-Detailseite. Das neue Design überzeugt durch eine klarere, intuitivere Oberfläche, mit denen du deine Epics einfacher verwalten und nachverfolgen kannst.\n\nDas sind einige der wichtigsten neuen Funktionen:\n* **Beauftragte** - weise Teammitgliedern Epics zu und verbessere so die Verantwortlichkeit und den Überblick.\n* **Integritätsprobleme** - bewerte den Status deiner Epics rasch mit den neuen Zustandsindikatoren.\n* **Zeiterfassung** - ermögliche einen transparenten Überblick über die aufgewendete Zeit und stelle sicher, dass Ressourcen in den Projekten effizient eingesetzt werden.\n* **Verlauf** - sieh dir den gesamten Verlauf des Epics an.\n* **Kurzbeschreibung** - sieh dir Beschreibungen von langen Workitems einfach an, ohne ewig scrollen zu müssen. Beschreibungen werden standardmäßig abgeschnitten und können über den Link „Mehr anzeigen“ als Volltext angezeigt werden. Dadurch wird dein Workflow optimiert, denn nun kannst du Beschreibungen rasch überfliegen und nur bei Bedarf den gesamten Text anzeigen. So vermeidest du unnötigen Text und die Lesbarkeit wird verbessert.\n* **Benutzerdefinierte Farbe** - passe die Farbe von Epics, die in der Roadmap angesehen werden, an, indem du benutzerdefinierte Farben festlegst. Du kannst dabei HEX- oder RGB-Codes nutzen oder aus einer erweiterten, vordefinierten Palette wählen.\n\n![Screenshot der neuen Epic-Erfahrung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674437/Blog/Content%20Images/Screenshot_2024-07-10_at_4.22.45_p.m..png)\n\n### Konsistenz über Planungsobjekte hinweg\nDie neue Epic-Erfahrung gleicht sehr der neuen Ticket-Erfahrung, die demnächst verfügbar sein wird (Achtung, Spoiler!) sowie den Aufgaben. So erwartet die Benutzer(innen) ein nahtloses, kohärentes Erlebnis. Durch diese Konsistenz können Workflows optimiert und die Lernkurve für neue Benutzer(innen) abgeflacht werden.\n\n### Zusätzliche Funktionen\nWir planen, iterativ spannende neue Funktionen hinzuzufügen, die deine Planung verbessern. Unser Ziel ist es, dir die Möglichkeit zu geben, Planungsprozesse mit GitLab so anzupassen, dass sie perfekt zu den einzigartigen Anforderungen deines Unternehmens passen. Sobald wir die neue Epic-Erfahrung veröffentlicht haben, kannst du dich mit jeder Release auf weitere Funktionen freuen! Und davon gibt es viele – hier ist ein kleiner Auszug unserer Favoriten:\n- [Vorlagen](https://gitlab.com/gitlab-org/gitlab/-/issues/428690)\n- [Benutzerdefinierte Felder](https://gitlab.com/groups/gitlab-org/-/epics/235)\n- [Konfigurierbare Status](https://gitlab.com/groups/gitlab-org/-/epics/5099)\n- [Epics auf Projektebene](https://gitlab.com/gitlab-org/gitlab/-/issues/31840)\n- [Klonen](https://gitlab.com/gitlab-org/gitlab/-/issues/339768)\n- [Verschieben in eine andere Gruppe/ein anderes Projekt](https://gitlab.com/gitlab-org/gitlab/-/issues/339766)\n- [Meilensteine](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n## Erwartungen an die Migration\nWir wissen, dass Änderungen disruptiv sein können. Daher haben wir die Migration zur neuen Epic-Erfahrung so nahtlos wie möglich gemacht. Alle vorhandenen Epic-Daten, APIs und URLs werden weiterhin wie erwartet funktionieren. Benutzer(innen) müssen für den Umstieg nichts tun. Unsere Self-Managed-Kund(inn)en können sich eine Vorschau des neuen Erlebnisses schon vor der allgemeinen Verfügbarkeit [hier](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html) in einer Testumgebung ansehen.\n\n## Feedback und Engagement der Community\nWir schätzen eure Beiträge und ermutigen euch, eure Erfahrungen mit der neuen Epic-Erfahrung zu teilen. Euer Feedback ist unerlässlich, um unsere Tools weiter zu verbessern. In unserem [Feedback-Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/463598) könnt ihr uns eure Gedanken und Vorschläge mitteilen.\n\n## Wie geht es weiter?\nDie neue Epic-Erfahrung in GitLab ist ein bedeutender Schritt für das Agile Planning. Mit erweiterten Funktionen, verbesserter Konsistenz und einem benutzerzentrierten Ansatz sind wir überzeugt, dass diese Änderungen deine Projektmanagementprozesse signifikant verbessern werden. Probier die neuen Funktionen aus und teile uns mit, was dir gefällt. Bleib auf dem Laufenden, denn wir arbeiten weiter an Innovationen und Verbesserungen.\n\n> [Setze ein Lesezeichen auf diese Seite](https://about.gitlab.com/de-de/blog/categories/agile-planning/), um über unsere Neuigkeiten zum Agile Planning auf dem Laufenden zu bleiben.",[682,683,732,733,684],"2025-04-22",{"slug":942,"featured":6,"template":687},"unveiling-a-new-epic-experience-for-improved-agile-planning","content:de-de:blog:unveiling-a-new-epic-experience-for-improved-agile-planning.yml","Unveiling A New Epic Experience For Improved Agile Planning","de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning.yml","de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"_path":948,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":949,"content":955,"config":961,"_id":963,"_type":16,"title":964,"_source":17,"_file":965,"_stem":966,"_extension":20},"/de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"title":950,"description":951,"ogTitle":950,"ogDescription":951,"noIndex":6,"ogImage":952,"ogUrl":953,"ogSiteName":701,"ogType":702,"canonicalUrls":953,"schema":954},"Agile Exzellenz entfesseln: GitLab Epics für nahtloses Portfolio-Management","Erfahre, wie die mehrstufigen Epics von GitLab das agile Portfoliomanagement revolutionieren, indem sie einen strukturierten und dennoch flexiblen Ansatz für die strategische Planung und effiziente Ausführung bieten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098713/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098713577.png","https://about.gitlab.com/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile Exzellenz entfesseln: GitLab Epics für nahtloses Portfolio-Management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"},{\"@type\":\"Person\",\"name\":\"Melissa Ushakov\"}],\n        \"datePublished\": \"2024-02-06\",\n      }",{"title":950,"description":951,"authors":956,"heroImage":952,"date":958,"body":959,"category":14,"tags":960},[728,957],"Melissa Ushakov","2024-02-06","Ein effektives Portfoliomanagement ist entscheidend für den Erfolg von Organisationen in der sich ständig weiterentwickelnden Landschaft der Softwareentwicklung. Um deine Geschäftsstrategie effektiv umzusetzen, musst du auf die richtigen Dinge setzen, deine Ressourcen optimal einsetzen und die Risiken minimieren.\n\nDie Portfolio-Management-Funktionen von GitLab bieten einen strukturierten und dennoch flexiblen Ansatz, um die Strategie mit der Umsetzung zu verbinden. In diesem Blogbeitrag werden wir die Vorteile der mehrstufigen Epics von GitLab und ihre zentrale Rolle im agilen Portfoliomanagement untersuchen.\n\n## Mehrstufige Epics von GitLab verstehen\n\nMit den mehrstufigen Epics von GitLab können Organisationen ihre Arbeit in einer hierarchischen Struktur organisieren, die einen klaren und detaillierten Überblick über die Projekte und ihre Abhängigkeiten bietet, damit Teams fundierte Entscheidungen treffen, potenzielle Herausforderungen vorhersehen und ihre Arbeitsabläufe optimieren können, um die Effizienz zu steigern und Projekte erfolgreich abzuschließen. Im Gegensatz zu anderen Tools erlaubt GitLab die Verschachtelung von Epics auf bis zu sieben Ebenen über verschiedene Gruppen und Projekte hinweg und ermöglicht so eine effiziente funktionsübergreifende Koordination.\n\n![epics portfolio management - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098727863.png)\n\n## Vorteile von mehrstufigen Epics im Portfolio-Management\n\nHier findest du vier Vorteile von mehrstufigen Epics im Portfolio-Management:\n\n### 1. Flexible Kompatibilität mit agilen Frameworks\n\nEpics passen sich nahtlos an verschiedene Scaled Agile Framework an, so dass Teams GitLab an ihre bevorzugte Arbeitsweise anpassen können. Mehrstufige Epics bieten ein flexibles Konstrukt zur Darstellung verschiedener übergeordneter Planungsaufgaben mit minimalem Konfigurationsaufwand. Diese Anpassungsfähigkeit bedeutet, dass Teams GitLab effizient für Produktplanungs-Workflows nutzen können, ohne dass sie umfangreiche Einstellungen vornehmen müssen, sodass sie sich mehr auf die strategische Planung und weniger auf die Konfiguration von Tools konzentrieren können.\n\n### 2. Granulare Aufschlüsselung der Arbeit\n\nMit den mehrstufigen Epics von GitLab können Organisationen komplexe Projekte in kleinere, überschaubare Komponenten aufteilen, so dass die Teams kleinere Iterationen identifizieren können, die eine schnellere und häufigere Bereitstellung von greifbarem Mehrwert für die Benutzer(innen) ermöglichen. Übergeordnete Epics bieten einen strategischen Überblick, der sich über mehrere Jahre erstrecken kann, während Epics, die näher an den Entwicklungsergebnissen liegen, in der Regel in wenigen Sprints abgeschlossen werden können. Epics können in Issues und Tasks unterteilt werden, um strategische Ziele mit taktischeren Ergebnissen zu verbinden.\n\n![epics portfolio management - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098727864.png)\n\n### 3. Echtzeit-Transparenz und Zusammenarbeit\n\nGitLab-Epics bieten Transparenz über den Fortschritt in Echtzeit und fördern die effektive Zusammenarbeit im Team. GitLab bietet eine beispiellose Rückverfolgbarkeit mit automatischen Fortschrittsaktualisierungen für Epics auf der Grundlage nachgelagerter DevSecOps-Aktivitäten für verknüpfte Workitems, sodass die Beteiligten fundierte Entscheidungen anhand der aktuellsten Informationen treffen, Ressourcen effektiv zuweisen und einen proaktiven Ansatz für die Verwaltung von Produktzeitplänen verfolgen können.\n\n![epics portfolio management - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098727866.png)\n\n### 4. Teamübergreifende Planung\n\nMehrstufige Epics erleichtern die effiziente Planung über mehrere Teams hinweg, indem sie eine zentrale Übersicht über die Arbeitsaufteilung und die Abhängigkeiten der Teams in der gesamten Organisation bieten und so eine kohärente Zusammenarbeit und Abstimmung der Bemühungen gewährleisten. Alle Informationen für die agilen Planungsprozesse und die Ausführung der Arbeit in deiner Organisation sind in einem einzigen Tool zusammengefasst, das den gemeinsamen Kontext der Arbeit eines Teams mit der übergeordneten Strategie darstellt.\n\n![epics portfolio management - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098727871.png)\n\nDie Portfolio-Management-Tools von GitLab, einschließlich der mehrstufigen Epics, stellen sicher, dass die strategische Planung nahtlos mit der Ausführung von Projekten übereinstimmt, sodass die Teams die Komplexität der Softwareentwicklung mit Präzision, Effizienz und einem klaren Fokus auf die übergreifenden Geschäftsziele steuern können.\n\nBist du bereit, das volle Potenzial der mehrstufigen Epics von GitLab zu nutzen und dein Portfolio-Management zu verbessern? Sieh dir unsere Abonnementoptionen auf unserer [Preisseite](https://about.gitlab.com/de-de/pricing/) an und schalte eine Vielzahl leistungsstarker Funktionen frei, die die Zusammenarbeit fördern, die Transparenz verbessern und deine Projekte zum Erfolg führen.\n",[682,839,683],{"slug":962,"featured":92,"template":687},"unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","content:de-de:blog:unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","Unlocking Agile Excellence Gitlab Epics For Seamless Portfolio Management","de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"_path":968,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":969,"content":975,"config":982,"_id":984,"_type":16,"title":985,"_source":17,"_file":986,"_stem":987,"_extension":20},"/de-de/blog/gitlab-for-agile-software-development",{"title":970,"description":971,"ogTitle":970,"ogDescription":971,"noIndex":6,"ogImage":972,"ogUrl":973,"ogSiteName":701,"ogType":702,"canonicalUrls":973,"schema":974},"So setzt du GitLab für die Agile-Softwareentwicklung ein","Wie Agile-Artefakte auf GitLab-Funktionen abgebildet werden und wie eine Agile-Iteration in GitLab aussieht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So setzt du GitLab für die Agile-Softwareentwicklung ein\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":970,"description":971,"authors":976,"heroImage":972,"date":978,"body":979,"category":14,"tags":980,"updatedDate":981},[977,728],"Victor Wu","2018-03-05","Hast du dich jemals gefragt, ob GitLab die [Agile-Methode](https://about.gitlab.com/de-de/solutions/agile-delivery/) unterstützt? Wenn du die Verwendung von GitLab in Betracht ziehst, ist es möglicherweise nicht offensichtlich, wie die Funktionen der DevSecOps-Plattform mit Agile-Artefakten übereinstimmen. Daher haben wir sie für dich aufgeschlüsselt.\n\nAgile ist eine der wichtigsten und transformativsten Methoden, die in den letzten Jahrzehnten im Bereich des Software-Engineerings eingeführt wurde. Obwohl sich nicht alle auf die detaillierte Terminologie der Agile-Konzepte einigen können, hat sie sich dennoch deutlich positiv auf die Softwareentwicklungsteams ausgewirkt. Du kannst dank [Agile-Softwareentwicklung](https://about.gitlab.com/de-de/solutions/agile-delivery/) und der Bereitstellungsprozesse effizient kundenorientierte Produkte erstellen.\n\nGitLab ist so konzipiert, dass es flexibel genug ist, um sich an deine Softwareentwicklungsmethodik anzupassen, unabhängig davon, ob es sich um Agile handelt oder davon inspiriert ist. In diesem Beitrag zeigen wir eine einfache Zuordnung von Agile-Artefakten zu GitLab-Funktionen und erklären, wie Kund(inn)en erfolgreich leistungsstarke [Agile-Softwarebereitstellungsteams](https://about.gitlab.com/de-de/solutions/agile-delivery/) mit GitLab unterstützen.\n\n## Inhaltsverzeichnis\n\n- [Zuordnen von Agile-Artefakten zu GitLab-Funktionen](#zuordnen-von-agile-artefakten-zu-gitlab-funktionen)\n  - [Agile-Artefakt → GitLab-Funktion](#agile-artefakt--gitlab-funktion)\n- [Eine Agile-Iteration mit GitLab](#eine-agile-iteration-mit-gitlab)\n  - [User Storys → GitLab-Probleme](#user-storys--gitlab-probleme)\n  - [Aufgabe → Aufgaben](#aufgabe--aufgaben)\n  - [Epics → GitLab-Epics](#epics--gitlab-epics)\n  - [Produkt-Backlog → GitLab-Issue-Übersichten](#produkt-backlog--gitlab-issue-übersichten)\n  - [Sprints → GitLab-Iterationen](#sprints--gitlab-iterationen)\n  - [Punkte und Schätzungen → GitLab-Ticketgewichtung](#punkte-und-schätzungen--gitlab-ticketgewichtung)\n  - [Agile Board → GitLab-Issue-Übersichten](#agile-board--gitlab-issue-übersichten)\n  - [Team-Workload → GitLab-Issue-Übersicht](#team-workload--gitlab-issue-übersicht)\n  - [Abarbeitungen → GitLab-Abarbeitungen](#abarbeitungen--gitlab-abarbeitungen)\n- [Starte deine Agile-Reise mit GitLab](#starte-deine-agile-reise-mit-gitlab)\n\n## Zuordnen von Agile-Artefakten zu GitLab-Funktionen\n\n### Agile-Artefakt → GitLab-Funktion \n\n- User Story –> [Probleme](https://docs.gitlab.com/ee/user/project/issues/) \n- Aufgabe –> [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) \n- Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/) \n- Punkte und Schätzung –> [Problemgewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) \n- Produkt-Backlog –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/Iteration –> [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) \n- Agile Board –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Team-Workload –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Abarbeitungsdiagramm –> [Abarbeitungsdiagramme](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## Eine Agile-Iteration mit GitLab\n\n### User Storys → GitLab-Probleme\n\nIn der Agile-Softwareentwicklungsmethodik beginnt man oft mit einer User Story, die ein einzelnes Feature erfasst, um den Benutzer(inne)n einen Geschäftswert zu bieten. In GitLab dient ein [Ticket](https://docs.gitlab.com/ee/user/project/issues/) diesem Zweck mit Leichtigkeit. GitLab-Tickets sind für Agile-Teams unerlässlich und bieten eine effektive Methode zum Verwalten von Aufgaben und Projekten. Softwareentwickler(innen) können Tickets erstellen, zuweisen und nachverfolgen, um eine klare Verantwortlichkeit und Sichtbarkeit des Fortschritts zu gewährleisten. Tickets kommen mit robusten Metadaten wie Beauftragte(r), Iteration, Gewichtung und Labels, was die Aufgabenpriorisierung und das Workflow-Management während des gesamten Softwareentwicklungsprozesses verbessert. Darüber hinaus wird die Teamzusammenarbeit bei Tickets mit Diskussionsthreads, Anhängen und Echtzeit-Updates optimiert, um eine effektive Kommunikation und Teamarbeit zu ermöglichen.\n\n![Screenshot eines GitLab-Tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nDas GitLab-Ticket hat einen Titel und einen Beschreibungsbereich in der Mitte, in dem du alle Details wie den Geschäftswert und die relevanten Personas in einer User Story dokumentieren kannst. Die Seitenleiste rechts bietet die Integration mit anderen Agile-kompatiblen Funktionen wie dem übergeordneten Epic, zu dem das Ticket gehört, der Iteration, in der das Ticket bearbeitet werden soll, und der Gewichtung des Tickets, die den geschätzten Aufwand widerspiegelt.\n\n### Aufgabe → Aufgaben\n\nOft wird eine User Story weiter in einzelne Aufgaben unterteilt. GitLab-[Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) rationalisieren das Projektmanagement, da Agile-Teams die Möglichkeit haben, User Storys in einzelne Arbeitsschritte aufzuteilen. Diese Funktion unterstützt das Agile-Framework, indem Softwareentwickler(innen) Aufgaben innerhalb ihrer Projekte erstellen, zuweisen und nachverfolgen können. Durch die direkte Integration des Aufgabenmanagements in GitLab können Teams einen zusammenhängenden Workflow aufrechterhalten, der sicherstellt, dass alle Projektaktivitäten der Softwareentwicklung einfach nachverfolgt und verwaltet werden können.\n\n[!Screenshot mit genauer Aufgabenverwaltung und Projektverfolgung mit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175696/Blog/rd4jnbnddseykj7f9x4q.png)\n\nVerbessere den Nutzen für Benutzer(innen) mit einer präzisen Aufgabenverwaltung und Projektverfolgung mit GitLab. Die Aufgaben sind mit den gleichen Metadaten wie Tickets ausgestattet, einschließlich Beauftragte(r), Iteration, Gewichtung, Label, Zeiterfassung und Funktionen für die Zusammenarbeit. Dieser umfassende Funktionsumfang ermöglicht es Agile-Teams und Projektmanager(innen), Workloads effektiv zu verwalten, Aufgaben zu priorisieren und eine nahtlose Zusammenarbeit zwischen Softwareentwickler(inne)n zu gewährleisten.\n\n### Epics → GitLab-Epics\nAndererseits können Agile-Entwicklungsfachkräfte eine Abstraktion über den User Storys angeben, die oft als Epic bezeichnet wird und auf einen größeren Benutzerfluss hinweist, der aus mehreren Funktionen besteht. In GitLab enthält ein [Epic](https://docs.gitlab.com/ee/user/group/epics/) auch einen Titel und eine Beschreibung, ähnlich wie ein Ticket, aber du kannst mehrere untergeordnete Tickets daran anhängen, um diese Hierarchie anzuzeigen.\n\n![Screenshot von verschachtelten GitLab-Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nMit GitLab-Epics können Agile-Teams große Projekte effizient organisieren und verwalten, indem sie Epics bis zu neun Ebenen tief verschachteln. Diese hierarchische Struktur bietet einen klaren Überblick über die Roadmap des Projekts und hilft Softwareentwickler(inne)n und Projektmanager(inne)n, komplexe Initiativen in überschaubare Komponenten zu unterteilen. Durch die Verwendung von untergeordneten und [verknüpften Epics](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html) können Teams den Fortschritt, die Abhängigkeiten und die Projektmeilensteine besser verfolgen, die Zusammenarbeit verbessern und eine kohärente Agile-Bereitstellung gewährleisten.\n\n### Produkt-Backlog → GitLab-Issue-Übersichten\n\nDie Produkt- oder Geschäftsinhaber(innen) erstellen diese User Storys in der Regel, um die Bedürfnisse des Unternehmens und der Kund(inn)en widerzuspiegeln. Sie werden in einem Produkt-Backlog nach Prioritäten sortiert, um die Dringlichkeit und die gewünschte Reihenfolge der Entwicklung festzuhalten. Die Eigentümer(innen) des Produkts kommunizieren mit den Stakeholdern, um die Prioritäten festzulegen, und verfeinern das Backlog ständig. In GitLab bietet eine [Issue-Übersicht](https://docs.gitlab.com/ee/user/project/issue_board.html), die mit Iterationen als Listen organisiert ist, ein Drag-and-Drop-Workflow-Erlebnis, mit dem du deinen Backlog mühelos priorisieren und Storys einem bevorstehenden Sprint zuweisen kannst.\n\n[Gif der GitLab Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175706/Blog/s6jqjqgqgwaaqc1ywkkn.gif)\n\n### Sprints → GitLab-Iterationen\n\nEin Sprint stellt einen begrenzten Zeitraum dar, in dem die Arbeit abgeschlossen werden soll. Das kann eine Woche, ein paar Wochen oder vielleicht einen Monat oder mehr umfassen. Die Eigentümer(innen) des Produkts und das Entwicklungsteam treffen sich, um zu entscheiden, welche Arbeiten für den kommenden Sprint vorgesehen sind. Die Funktion [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) von GitLab unterstützt dies: Weise Iterationen ein Startdatum und ein Fälligkeitsdatum zu, um den Zeitraum der Iteration zu erfassen. Das Team fügt dann Tickets in den Sprint ein, indem es sie dieser bestimmten Iteration zuweist.\n\nDurch die Verwendung von Iterationen nutzt du die erweiterten Funktionen von GitLab für agiles Projektmanagement und bietest eine bessere Transparenz und Kontrolle über deine Agile-Planung und -Bereitstellung. \n\n### Punkte und Schätzungen → GitLab-Ticketgewichtung\n\nAuch in diesem Meeting werden User Storys kommuniziert und der technische Aufwand für jede User Story geschätzt. In GitLab haben Tickets eine [Gewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) – Attribute, die du verwenden würdest, um den geschätzten Aufwand anzugeben.\n\nIn dieser Besprechung (oder in den folgenden) werden die User Storys weiter aufgeschlüsselt und manchmal werden technische Pläne und die Architektur dokumentiert. In GitLab können diese Informationen im Ticket oder in der [Beschreibung der Merge Request](https://docs.gitlab.com/ee/user/project/merge_requests/) dokumentiert werden, da die Merge Request oft der Ort ist, an dem die technische Zusammenarbeit stattfindet.\n\nWährend des Sprints (GitLab-Iteration) holen die Mitglieder des Softwareentwicklungsteams User Storys ab, an denen sie nacheinander arbeiten können. In GitLab haben Tickets Beauftragte. Du würdest dich also einem Ticket [zuweisen](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html), um zu zeigen, dass du jetzt daran arbeitest. Wir empfehlen dir, [eine leere und mit dem Ticket verknüpfte Merge Request zu erstellen](https://docs.gitlab.com/ee/user/project/issues/), um sofort mit dem technischen Zusammenarbeitsprozess zu beginnen, noch bevor du eine einzige Codezeile erstellst.\n\n### Agile Board → GitLab-Issue-Übersichten\n\nWährend des gesamten Sprints durchlaufen die Tickets verschiedene Phasen, wie z. B. `Ready for dev`, `In dev`, `In QA`, `In review`, `Done`, abhängig vom Workflow in deiner jeweiligen Organisation. Normalerweise sind dies Spalten in einem Agile Board. In GitLab kannst du mit [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) deine Phasen definieren und Tickets durch sie bewegen. Das Team kann unter Beachtung der Iteration und anderer relevanter Attribute [die Übersicht konfigurieren](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration). Während der täglichen Stand-ups betrachtet das Team das Board gemeinsam, um den Status des Sprints aus einer Workflow-Perspektive zu sehen.\n\n![Screenshot der GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nDie GitLab-Issue-Übersicht greift auch dynamisch auf Probleme zu, ähnlich wie die GitLab-Issue-Liste. Aber sie ermöglicht flexiblere Workflows. Du kannst individuelle Listen in der Übersicht einrichten, um die Phasen des Agile Boards widerzuspiegeln. Dein Team kann dann die User Storys steuern und verfolgen, während sie von z. B. „Bereit für die Entwicklung“ zu „Zur Produktion freigegeben“ wechseln.\n\n### Team-Workload → GitLab-Issue-Übersicht\n\nAgile Teams können ihre Workflows optimieren, indem sie Issue-Übersichten mit Listen erstellen, die den Verantwortlichen in GitLab zugeordnet sind. Mit dieser Funktion kannst du die Verteilung der Aufgaben unter den Teammitgliedern visualisieren und die agile Bereitstellung verbessern. Um es einzurichten, gehe zu deinem Projekt oder deiner Gruppe, erstelle eine neue Übersicht im Abschnitt „Boards“ und [füge Listen](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) für jede(n) Beauftragte(n) hinzu. Weise Teammitgliedern Tickets zu, und sie werden automatisch in den entsprechenden Listen angezeigt. Diese dynamische Ansicht ermöglicht eine ausgewogene Arbeitsbelastung und eine effektive Aufgabenverwaltung.\n\n![Screenshot der organisierten GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\nOrganisiere eine Issue-Übersicht nach beauftragter Person oder nach Team mithilfe von [Labels mit begrenztem Geltungsbereich]. Die Issue-Übersicht von GitLab ist unglaublich vielfältig und unterstützt Workflows über den gesamten Software-Entwicklungsprozess hinweg.\n\n### Abarbeitungen → GitLab-Abarbeitungen\n\nDas Entwicklungsteam möchte in Echtzeit wissen, ob es auf dem richtigen Weg ist, und die entstehenden Risiken mindern. GitLab bietet [Abarbeitungen](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), damit das Team die im aktuellen Sprint „abzuarbeitenden“ Aufgaben visualisieren kann, während sie abgeschlossen wird.\n\nGegen Ende des Sprints stellt das Entwicklungsteam die fertiggestellten Funktionen den verschiedenen Interessengruppen vor. Mit GitLab wird dieser Prozess mithilfe von [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) vereinfacht, sodass auch Code, der noch nicht für die Produktion freigegeben ist, in verschiedenen Test-, Staging- oder UAT-Umgebungen vorgeführt werden kann. Review Apps und [CI/CD-Funktionen](https://docs.gitlab.com/ee/ci/) sind in die Merge Request selbst integriert.\n\nDie gleichen Tools sind auch für Entwickler(innen) und QA-Rollen nützlich, um die Softwarequalität zu sichern, sei es durch automatisierte Tests mit CI/CD oder durch manuelle Tests in einer Review-App-Umgebung.\n\n![Screenshot von GitLab-Abarbeitungen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nDie GitLab-Abarbeitung ermöglicht es einem Team, die „abzuarbeitenden“ Aufgaben zu verfolgen, während sie in einem Sprint abgeschlossen werden. Auf diese Weise kannst du früher auf Risiken reagieren und dich anpassen. So kannst du Geschäfts-Stakeholder darüber informieren, dass bestimmte Funktionen voraussichtlich auf einen zukünftigen Sprint verschoben werden.\n\nTeam-Retrospektiven am Ende des Sprints können im [Wiki] von GitLab (https://docs.gitlab.com/ee/user/project/wiki/index.html) dokumentiert werden, sodass die gewonnenen Erkenntnisse und die Aktionspunkte im Laufe der Zeit nachverfolgt werden können. Während der eigentlichen Retrospektive kann sich das Team den [Iterationsbericht](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report) ansehen, der die Abarbeitung und andere Statistiken des abgeschlossenen Sprints anzeigt.\n\n## Starte deine Agile-Reise mit GitLab\nBist du bereit, dein Agile-Projektmanagement zu verbessern? GitLab bietet eine umfassende Palette von Funktionen, die auf Agile-Teams, Softwareentwickler(innen) und Projektmanager(innen) zugeschnitten sind und eine nahtlose Zusammenarbeit und effiziente Workflows gewährleisten. Erkunde unsere Preisoptionen, starte eine kostenlose Testversion und erfahre, wie GitLab deine Agile-Bereitstellungsprozesse verändern kann.\n\n> [Erfahre mehr über die Agile Planung mit GitLab](https://about.gitlab.com/pricing/) und starte noch heute deine Reise!\n",[682,732,684,755],"2025-05-14",{"slug":983,"featured":6,"template":687},"gitlab-for-agile-software-development","content:de-de:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","de-de/blog/gitlab-for-agile-software-development.yml","de-de/blog/gitlab-for-agile-software-development",2,[694,718,742,762,782,803,823,847,866],1758326216122]