ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
6.4 KiB
2025-07-08 - Planungsprämisse - Kapazitäten pro Team pro PI
Version: 23 | Last modified: 2026-01-22T14:15:09.919+01:00 Source: confluence page ID 455052465
Inhalt
Kapazität Die ARTs werden zu jedem PI die Kapazitäten der Teams validieren und gegebenfalls anpassen Standardteam (8-13 Personen / 20% - 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. Beispiel: Team hat Kapazität 8; Für Increment 41 wird 20% abgezogen: 6,5 wird eingetragen. Es werden nur in 0,5 Schritten eingetragen (6; 6,5; 7; 7,5) usw. 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 | 9 Personen inkl PO/SM; | Cortex | ja | 8 | 10 Personen inkl PO; | Thalamus | ja | 8 | 11 Personen inkl PO; |
| | | |
| | | |
| | | | ART SuNBestätigung am  Teamname | Standardteam ja/nein | JS pro PI | Kommentar | Atlas | ja | 9 | 11 Pers., neues Komponententeam mit neuen Services / Komponenten, Betrieb ab Q1/26 Steigerung der Kapazität aufgrund von EffizienzsteigungerungsmaÃnahmen auf die PIs verteilt | TADA | ja | 7 | 7 Pers., DevOps (Vera) Steigerung der Kapazität aufgrund von EffizienzsteigungerungsmaÃnahmen auf die PIs verteilt | Rocket | ja | 7 | 9 Pers., DevOps (FBZE) | BEAT | ja | 11 | 12 Pers., neues Teamübergreifend agierendes Team | Puls | ja | 12 | 10 Pers., neues Teamübergreifend agierendes Team | Flux | nein | 11 | 13 Pers., neues Komponententeam, keine Velocity, Betrieb ab Q1/26 Steigerung der Kapazität aufgrund von EffizienzsteigungerungsmaÃnahmen auf die PIs verteilt | FaMe | nein | 11 | 15 Pers., neues Komponententeam mit neuen Services / Komponenten, Betrieb ab Q1/26 Steigerung der Kapazität aufgrund von EffizienzsteigungerungsmaÃnahmen auf die PIs verteilt | Netzfahrplan | nein | 7 | 16 Pers., DevOps (AFK, iTrain) Steigerung der Kapazität aufgrund von EffizienzsteigungerungsmaÃnahmen auf die PIs verteilt | Neues Team | nein | 3 | Team im Aufbau startet erst PI 39 | ART KommunikationTeamname | Standardteam ja/nein | JS pro PI | Kommentar | AQuA | ja | 8 | | Carpo | ja | 6 | Aufrechterhaltung Betrieb KOMBau | Io | ja | 8 | | Metis | ja | 8 | | Pandia | ja | 6 | Aufrechterhaltung Betrieb KOMBau | ART Uj KonstruktionTeamname | Standardteam ja/nein | JS pro PI | Kommentar | Galaxy | ja | 8 | 11 Personen; Anteil Ops, Wartung 30%. | Planbau | nein | 8 | 21 Personen | Adams | ja | 8 | 14 Personen; Ãbernahme von AstBau als neues Thema | Ains | ja | 8 | 13 Personen; Anteil Ops, Wartung 30% | Bestand | nein | 11 | 28 Personen; Anteil Ops, Wartung und Infrastruktur 30%; Allg. ujBau und Nfpl Anforderungen 15% | Faps | ja | 8 | 12 Personen | Flow | ja | 9 | 16 Personen | Nexus | ja | 8 | 11 Personen | ART Uj VeröffentlichungTeamname | Standardteam ja/nein | JS pro PI | Kommentar | BIS | ja | 7,5 | 8 Personen, 6 Entwickler | Adapt | ja | 7,5 | 10 Personen, 6 Entwickler | Triton | ja | 5,5 | 8 Personen, 4 Entwickler | Juice | ja | 5 | 7 Personen, 3 Entwickler | GFD-Z | nein | 11,5 | 22 Personen, 10 Entwickler 30% Betrieb | Team JS aktualisiert mit Trio ART C2S Plattform Teamname | Standardteam ja/nein | JS pro PI | Kommentar | OMI | ja | 6 | 10 Personen | neXt | nein | 5 | 4 Personen | YAK | nein | 10 | 11 Personen (reines Entwicklerteam) | Prozesse | nein | 5 | 4 Personen (reines BA Team) |
| | | |
|  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. Fokus Entwicklung und Automatisierung. | QuEST Core | nein | 2 | Virtuelles Team bestehend aus 1 Entwickler plus Spezialpersonen, die je nach Bedarf mit X % allokiert werden. Fokus Prozesse und Release. | QuEST Ops | nein | 3 | Virtuelles Team bestehend 3 Technischen Tester plus Spezialpersonen, die je nach Bedarf mit X % allokiert werden. Fokus Testdurchführung, Analyse, Reporting |
| | | |
| | | |
| | | |
| | | |