---
profile: digiestate-safe/2
status: angenommen
stand: 2026-10-18
---

# Gemeinsames SAFe-orientiertes DigiEstate-Profil

Dieses Profil steuert Software-, Text- und Unternehmensvorhaben mit Menschen
und KI. Es ist die gemeinsame Referenz für neue Projekte, kein Anspruch auf
vollständige SAFe-Konformität. Bestehende Projekte wechseln nur ausdrücklich.
Der [Work-Item-Vertrag](../contracts/WORK-ITEMS.md) bestimmt die Daten und ihren
Zugriff. Stack, Gitflow und konkrete Testwerkzeuge behalten eigene Quellen.

## Herkunft, Anpassung und Erweiterung

| Bereich | Einstieg | Herkunft und Grenze |
| --- | --- | --- |
| Vorhaben | Epic mit Nutzenhypothese und begrenztem MVP | [SAFe Epic](https://framework.scaledagile.com/epic/); organisatorischer Prozesspilot ist unsere Übertragung |
| Investition | Knapp begründete Alternativen, Aufwand, Risiken und Mittelgrenze | Vereinfachter Lean Business Case; keine Umstellung auf vollständige Wertstromfinanzierung |
| Lieferung | Feature, Story, Task nach Bedarf | [SAFe Features](https://framework.scaledagile.com/features-and-capabilities/); Verwendung ohne ART/PI ist eine lokale Anpassung |
| Portfolio | Eigener Epic-Fluss mit begrenzter Aufmerksamkeit | [SAFe Portfolio Backlog](https://framework.scaledagile.com/portfolio-backlog/) |
| Qualität | Passende Nachweise im selben Arbeitsschritt | Bestehende technische und redaktionelle Skills; konkrete Werkzeuge sind keine SAFe-Vorgabe |
| Arbeitsfluss | Explizite Regeln, WIP, Lieferzeiterwartung und Messung | [Kanban Guide](https://kanbanguides.org/the-kanban-guide/); kein reines Spaltenboard |
| Bereitschaft | Kriterien je Typ und nächstem Übergang | Refinement/Readiness; unsere konkrete Auswahl steht unten |
| Ablage | Eine Quelle, stabile IDs, Dateien oder API | DigiEstate-Konvention nach dem Datenvertrag |

Die allgemeine Skala R0–R4 entfällt im neuen Profil. Scaled Agile beschreibt
in einem [Praxisbeitrag zur Large-Solution-Verfeinerung](https://scaledagile.com/blog/large-solution-refinement-paving-the-super-highway-of-value-delivery/)
ein kontextabhängiges, mehrdimensionales Readiness-Modell. Das ist keine
verbindliche einheitliche Skala für alle Arbeitstypen. Wir prüfen stattdessen
die unten benannten Voraussetzungen. Alte Reifegrade bleiben historische
Angaben und erzeugen weder Bereitschaft noch Freigabe.

## Fachsprache

| Typ | Bedeutung | Nicht gleichsetzen mit |
| --- | --- | --- |
| Idee | Beobachtung, Problem oder Möglichkeit | Umsetzungszusage |
| Epic | Endliche Initiative mit eigener Nutzen-/Investitionsentscheidung | Projekt oder grosser Aufgabenordner |
| Feature | Zusammenhängende nutzbare Fähigkeit | Bereits eingetretener Geschäftsnutzen |
| Story | Kleines fachlich abnehmbares Ergebnis, auch Lernen oder Verbesserung | Technische Schicht |
| Task | Konkreter separat überprüfbarer Arbeitsschritt | Beliebig kleine Codeänderung |
| Portfolio | Fachlicher Steuerungsrahmen für Initiativen und Investitionsentscheidungen | Dateiablage oder Projektordner |
| Projekt | Optional beteiligtes Vorhaben oder organisatorischer Arbeitskontext | Heimat oder zwingender Elternknoten eines Epics |

Üblich ist Epic → Feature → Story → Task. Zwischenstufen dürfen ausbleiben;
eigenständige Stories/Tasks sind zulässig. Ideen werden über Herkunftsbezüge
verbunden, nicht durch Typwechsel überschrieben. Ein Epic kann mehrere
Projekte betreffen oder ohne Projektbeteiligung erfasst werden. Es gehört in
diesem Profil genau einem Portfolio an. Projektbeteiligung, fachliche
Verantwortung, Abhängigkeiten und technische Quellroute sind getrennt.
Business/Enabler beschreibt den Beitrag, Software/Organisation den Bereich.
Laufende Akquise ist Betriebsarbeit, «Vertrieb aufbauen» eine Veränderung.

## Portfolio, Beteiligung und Quellen

SAFe steuert Portfolio-Epics im Portfolio-Backlog/-Kanban. Der Epic Owner
begleitet das Epic; Arbeit zur Umsetzung geht an beteiligte ARTs/Wertströme.
SAFe schreibt kein «Heimatprojekt plus weitere Projekte» vor.
[Portfolio Backlog](https://framework.scaledagile.com/portfolio-backlog/),
[Lean Portfolio Management](https://framework.scaledagile.com/lean-portfolio-management-discipline/).
SAFe kennt auch ART-/Solution-Train-Epics; deren eigene Backlogs werden erst
mit diesen Erweiterungen modelliert. Dieses schlanke Profil verwendet
Portfolio-Epics, ohne ARTs oder PI Planning einzuführen.

Unsere konkrete Abbildung: portfolio_id ordnet jedes Work-Item einem Portfolio
zu, project_ids bezeichnet null bis mehrere beteiligte Projekte,
depends_on_ids bezeichnet vorausgesetzte Work-Items. Eine Beteiligung ist keine
Abhängigkeit und kein Leserecht. owner_id bezeichnet fachliche Verantwortung;
source_context_id löst ausschliesslich die führende Datei-/API-Quelle auf.
Projektordner dürfen Arbeitsdaten führen, ohne fachliches Elternobjekt zu sein.
Ein Portfolio und ein Epic brauchen kein künstlich erzeugtes Heimatprojekt.
Die Feldstruktur und genau eine Portfoliozuordnung sind unsere explizite
Vereinfachung; SAFe spezifiziert kein entsprechendes JSON-Schema.

## Bereitschaft und Entscheidungen

| Nächster Schritt | Benötigte Grundlage |
| --- | --- |
| Erfassen | Verständlicher Impuls; technische Metadaten werden mit Defaults ergänzt |
| Erkunden | Konkrete nächste Frage, verantwortliche Person und begrenzter Untersuchungsauftrag |
| Epic analysieren | Problem, Betroffene, erste Hypothese, Alternativen und relevante Risiken |
| Epic bereitstellen | Nutzenhypothese, Messplan, nutzbarer MVP/Pilot, grobe Investitionsannahmen und zuständige Entscheidung |
| MVP/Pilot starten | Gültige Freigabe für Umfang und Mittelgrenze, Verantwortlichkeit, Kapazität, keine startverhindernde Blockierung |
| Feature/Story/Task auswählen | Kleines nächstes Ergebnis, prüfbare Kriterien, Nachweisstrategie, relevante Folgen und geklärte Voraussetzungen |
| Lieferung starten | Auswahl, aktuelle Bereitschaft, ausführende Identität, Kapazität und erforderliche Freigaben |
| Lieferung abschliessen | Kriterien nachgewiesen, relevante Qualitätsregeln erfüllt, gültige Abnahme |
| Epic abschliessen | Begründete Portfolioentscheidung, Hypothesenbewertung, verbleibende Arbeit und Verantwortung sichtbar |

Eine Untersuchung darf ausführbar sein, obwohl ihr Ergebnis unbekannt ist.
Bereitschaft ist die begründete Prüfung der aktuellen Daten gegen eine Regel,
kein zusätzliches frei gepflegtes Statusfeld. Nenne konkret, was fehlt.
Offene Fragen blockieren nur den Schritt, dessen Ergebnis sie wesentlich
verändern würden. Kriterien werden nicht zur vollständigen Vorabspezifikation.

Verantwortliche Person, Ausführende und Abnehmende sind getrennt. Eine Person
darf mehrere Verantwortlichkeiten übernehmen. KI darf im ausdrücklich
delegierten Umfang handeln; strategische Investitionsentscheidungen liegen
zunächst beim zuständigen Menschen. Bestehende Autorisierungen gelten weiter.
Eine Zustimmung gilt für einen bestimmten Gegenstand und Stand. Änderungen
an ihrem Umfang benötigen eine neue Prüfung, nicht automatisch neue Zustimmung
für jede Metadatenkorrektur. Der Vertrag beschreibt die Bindung an den Stand.

## Arbeitsflüsse und Kapazität

Die verbindlichen Zustände/Übergänge stehen einmal in
[workflows.yaml](../contracts/workflows.yaml). Ihre Namen sind lokale Codes.
Epics verwenden den Portfoliofluss; Features/Stories/Tasks den Lieferfluss.
Ideen haben einen eigenen kleinen Erfassungsfluss.

WIP wird pro Portfolio, Team und ausführendem Agenten vereinbart. Ein Agent
bearbeitet standardmässig einen Task; das ist keine globale Firmengrenze.
Prüfung und blockierte aktive Arbeit zählen mit. Pausieren oder Zurücksetzen
in eine Wartespalte beendet einen begonnenen Durchlauf nicht stillschweigend.
Portfolioabschluss ist keine automatische Abnahme seiner Kinder.

Vereinbare für jede Messpopulation Einheit, Start, Ende, WIP-Limit und
Lieferzeiterwartung aus Zeit und Wahrscheinlichkeit. Kennzeichne die erste
Erwartung ohne Historie als Annahme und überprüfe sie anhand echter Daten.
Miss WIP, Alter, Durchlaufzeit und Durchsatz. Eltern und Kinder werden nicht
in derselben Population addiert. Abbrüche getrennt vom erfolgreichen Durchsatz
ausweisen; Rückgaben innerhalb der Prüfung bleiben im selben Durchlauf.
Wiedereröffnung erzeugt einen neuen nachvollziehbaren Durchlauf, ohne alte
Zeitpunkte zu überschreiben. Geschäftsmetriken sind keine Flow-Metriken.

Ordne zunächst mit begründeter Reihenfolge nach Nutzen, Dringlichkeit,
Lernwert, Risiko, Abhängigkeit und Aufwand. Bei echten Investitionskonflikten
kann [WSJF](https://framework.scaledagile.com/wsjf/) als transparente relative
Schätzung gewählt werden. Erfinde keine Punktwerte oder Scheingenauigkeit.

## Lernen und Abschluss

Trenne geliefert, fachlich abgenommen, geschäftlich bewertet und aus dem
Portfolio entlassen. Der [Portfolio-Flow](https://framework.scaledagile.com/portfolio-flow/)
grenzt Portfolioaufmerksamkeit von vollständiger Umsetzung ab. Offene
Lieferobjekte bleiben bei Übergabe sichtbar und verantwortlich zugeordnet.

Hypothesenbewertung: offen, gestützt, widerlegt oder unklar. Fehlende Baseline
oder unzureichende Beobachtung ist kein Erfolg. Vereinbare Messfenster und
Auswertungsverantwortung vor dem Pilot. Eine wesentlich neue Hypothese wird
ein neues verknüpftes Epic; Präzisierungen bleiben Revisionen. Begründe Stoppen,
Übergabe, Verwerfen und Ersetzen. Eine Pause erhält Grund und Wiedervorlage.

## Erweiterungspunkte

| Erweiterung | Bei Bedarf zu ergänzen | Heute ausdrücklich offen |
| --- | --- | --- |
| Strategie | Strategic Themes, OKRs, Roadmap | Zielmodell und Beziehungen |
| Grosse Lösungen | Capabilities, Solution-Koordination | Zusätzliche Typen und validierte Elternregeln |
| Teamkoordination | ART, Planning Intervals, PI Planning | Rollen, Planungstakt und teamübergreifende Zusagen |
| Finanzierung | Wertströme, Lean Budgets, Guardrails | Budgetmodell und weitergehende Rechte |
| Betrieb | Wiederkehrende Arbeit, weitere Workflows | Auslöser und Wiederholungsregeln |

Diese Slots sind dokumentierte fachliche Ansatzpunkte, keine zugesagte Roadmap.
Erzeuge keine leeren Instanzen oder generische Plugin-Infrastruktur. Eine
Erweiterung aktualisiert Profil/Vertrag bewusst und erhält bestehende Daten.

## Einführung

Neue Projekte verwenden `digiestate-safe/2` und Work-Item-Vertrag 2.
Explizit gewähltes [Profil 1](SAFE-PROFIL-V1.md) mit
[Vertrag 1](../contracts/WORK-ITEMS-V1.md) bleibt unverändert nutzbar;
Version 2 ist keine automatische Migration. Projekte ohne diese Auswahl bleiben im bisherigen Vertrag. Für deren Schema-2-Register
gelten weiterhin die dort dokumentierten Regeln; neue Defaults migrieren
keine alten Dateien. Die Übernahme erhält Kennungen, Pfade, Historie und
Nachweise; unbekannte Reifegrade werden nicht als Zustimmung übersetzt.

Die [Beispiele](../contracts/examples/README.md) prüfen Software und Vertrieb
mit denselben Typen. Ihre Zahlen und Rollen sind synthetisch und nicht freigegeben.