# 2026-06-30 - Planungsprämisse - Kapazitäten pro Team pro PI Version: 1 | Last modified: 2026-05-27T15:47:15.915+02:00 Source: confluence page ID 593814109 --- Inhalt Kapazität Die ARTs werden zu jedem PI die Kapazitäten der Teams validieren und gegebenfalls anpassen Standardteam (8-13 Personen / 70% Entwicklung - 30% Betrieb) = 8 Capability JS in einem PI Berücksichtigung der PufferFür die Planung wird ein Puffer berücksichtigt. Wenn die Kapazität der Teams ermittelt ist, bitte die Kapazität abzüglich des Puffers auf dem Conceptboard pro Increment eintragen. In der Planung wird ein Puffer von durchschnittlich 15 % berücksichtigt.  Beispiel: Team hat Kapazität 8; Für Increment 42 wird 20% abgezogen: 6,5 wird eingetragen. Es werden nur in 0,5 Schritten eingetragen (6; 6,5; 7; 7,5) usw. Team hat JS = 8 | PI41 | PI42 | PI43 | PI44 | % | 95% | 90% | 90% | 80% | JS | 7,5 | 7 | 7 | 6,5 | Schritte Ermittle / bestätige die Kapazität deiner Teams. Berechne / adaptiere den Puffer und trage diesen auf dem Conceptboard ein. Verifikation während der Planung Sicherstellung, dass die Kapazität und Puffer nicht überschritten werden. TeamsART BARDTeamname | Standardteam ja/nein | JS pro PI | Kommentar | AST | nein, Spezifikationsteam und Testteam für Zusammenarbeit mit dem externen Lieferanten HaCon | 8 | | FOps | Nein, dieses Team macht Fachliche Betriebsführung. Kein DevOps | | Kapazität der Teams ist nicht in den Meilensteinen abgebildet. Grund: Vorgabe von Management: 70% Strategie (Meilensteine), 30% Betrieb (diese sind nicht in den Strategischen Meilensteinen abgebildet) | InfraTec | Nein, dieses Team macht hauptsächlich technische Betriebsführung, ca. 30% Weiterentwicklung. | | Kapazität der Teams ist nicht in den Meilensteinen abgebildet. Grund: Vorgabe von Management: 70% Strategie (Meilensteine), 30% Betrieb (diese sind nicht in den Strategischen Meilensteinen abgebildet) | BaBeDas | | 8 | | PzE | | 8 | | | | | | | | | | ART CM Teamname | Standardteam ja/nein | JS pro PI | Kommentar | Analytics Dashbords | ja | 8 | notwendige ad-hoc-Auswertungen für Fachbereiche können in den angenommen 30% für Betrieb sichergestellt werden | NeMo Business Intelligence | ja | 8 | notwendige ad-hoc-Auswertungen für Fachbereiche können in den angenommen 30% für Betrieb sichergestellt werden | CMDP Crush | ja | 8 | Durch Teamanpassungen/-Verschiebung von Marlin ab PI 37 sind im Team 8 Personen | CMDP Marlin | ja | 8 | | | | | | | | | | | | | | ART IDBFTeamname | Standardteam ja/nein | JS pro PI | Kommentar | Blaupause | nein | 8 | reines Konzeptionsteam | PHOENIX | nein | 8 | reines Dev-Team | Atlas | nein | 2 | reines Betriebsteam, entwickelt Plattform aber weiter | IMpuls | nein | 5 | Anforderungsmanagement Team | Teams werden durchgängig voll ausgelastet, Steuerung erfolgt über Kanbanpriorisierung durch die ART-Steuerung auf Capability-/Featureebene. | ART K&KTeamname | Standardteam ja/nein | JS pro PI | Kommentar | Iris | ja | 8 | 6 Personen inkl PO/SM; | Hippocampus | ja | 8 | 8 Personen inkl PO/SM; | Cortex | ja | 8 | 7 Personen inkl PO; | Thalamus | ja | 8 | 11 Personen inkl PO; | | | | | | | | | | | | | ART SuNAktualisierung 07.01 aufgrund ART-interner Roadmap-Planung Teamname | Standardteam ja/nein | JS pro PI | Kommentar | Atlas | nein | 8 | 12 Pers., Betrieb ab Q1/26 Velocity aufgrund von Erfahrungswerten | TADA | nein | 7 | 10 Pers., DevOps Velocity aufgrund von Erfahrungswerten | Rocket | nein | 8 | 9 Pers., DevOps Velocity aufgrund von Erfahrungswerten | BEAT | nein | 12 | 10 Pers., teamübergreifend agierendes Team Velocity aufgrund von Erfahrungswerten | Puls | nein | 10 | 7 Pers., teamübergreifend agierendes Team Velocity aufgrund von Erfahrungswerten | Flux | nein | 9 | 15 Pers., Betrieb ab Q1/26 Velocity aufgrund von Erfahrungswerten | FaMe | nein | 11 | 14 Pers., Betrieb ab Q1/26 Velocity aufgrund von Erfahrungswerten | Netzfahrplan | nein | 6 | 14 Pers., DevOps Velocity aufgrund von Erfahrungswerten | Fuse  | nein | 8 | 14 Pers. | ART KommunikationTeamname | Standardteam ja/nein | JS pro PI | Kommentar | Europa | ja | 7 | 8 Personen, DevOps | Carpo | ja | 7 | 10 Personen, DevOps | Io | ja | 7 | 9 Personen, Go-Live / Hypercare, Einführung DevOps | Metis | ja | 7 | 9 Personen, Go-Live / Hypercare, Einführung DevOps | Pandia | ja | 7 | 10 Personen, DevOps | ART Uj KonstruktionTeamname | Standardteam ja/nein | JS pro PI | Kommentar | Galaxy | ja | 8 | 11 Personen; Anteil Ops, Wartung 20%.  | Planbau | nein | 8  | 23 Personen; Anteil Ops, Wartung 20%. | Adams | ja | 8 | 15 Personen; Anteil Ops, Wartung 5% (nur 5% aufgrund von Buchungsvorgabe Hypercare) | Ains | ja | 8 | 13 Personen; Anteil Ops, Wartung 22.5% | Bestand | nein | 11 | 32 Personen; Anteil Ops, Wartung und Infrastruktur 30%; Allg. ujBau und Nfpl Anforderungen 15%  | Faps | ja | 8 | 12 Personen; Anteil Ops, Wartung 25% | Flow | ja | 9 | 14 Personen; Anteil Ops, Wartung 5% (nur 5% aufgrund von Buchungsvorgabe Hypercare) | Nexus | ja | 8 | 12 Personen; Anteil Ops, Wartung 5% (nur 5% aufgrund von Buchungsvorgabe Hypercare) | ART Uj VeröffentlichungTeamname | Standardteam ja/nein | JS pro PI | Kommentar | IVö (BIS, Adapt, Trion, Juice) | ja für alle Teams | 26 | 33 Personen,  19 Entwickler | GFD-Z (Hermes, Merkur) | nein | 11,5 | 22 Personen, 10 Entwickler 30% Betrieb | ART C2S Plattform Teamname | Standardteam ja/nein | JS pro PI | Kommentar | OMI | ja | 4,5 | 9 Entwickler; Betriebskapazität mind. 50 % | neXt | nein | 3 | 4 Entwickler; Betriebskapazität mind. 50 % | YAK | nein | 7,5 | 10 Entwickler | Prozesse | nein | 4 | KEIN Dev Team | Allgemeine Info: |  Team Quest Teamname | Standardteam ja/nein | JS pro PI | Kommentar | QuEST Dev | nein (4 Entwickler:innen + 2 FEs + 1 Spezial) | 6 | Virtuelles Team bestehend aus 4 Entwicklern plus Spezialpersonen, die je nach Bedarf mit X % allokiert werden. | QuEST Core | nein | 2 | Virtuelles Team bestehend aus 1 Entwickler plus Spezialpersonen, die je nach Bedarf mit X % allokiert werden. | QuEST Ops | nein | | Virtuelles Team | | | | | | | | | | | | | | | | |