Untertitel: Warum digitale Verwaltung um Bürgerziele geschnitten werden muss – und warum Feature-Kataloge allein keinen Nutzen liefern.
Eine Kommune digitalisiert den Kita-Antrag. Das Projekt startet mit einem Lastenheft von 180 Anforderungen: Rollen, Felder, Schnittstellen, PDF-Export. Nach zwei Jahren gibt es ein Formular mit allen Pflichtfeldern der Verwaltung. Eltern scheitern trotzdem – weil niemand die Story „Als Elternteil will ich einen Kita-Platz beantragen und den Status sehen“ von Anfang bis Ende durchgedacht und geliefert hat.
Digital wurde spezifiziert. Nutzen wurde nicht geliefert.
Die These in einem Satz
User-Story-getriebene Entwicklung liefert Bürgernutzen in prüfbaren Schritten – nicht Feature-Kataloge mit Abnahme am Ende.
Kein reines Scrum-Ritual. Kein Ticket-Theater. Sondern: Wer · Was · Warum – mit Akzeptanzkriterien, kleinen vertikalen Lieferungen und Priorität nach Nutzen.
Wo Reibung herkommt
Reibung entsteht strukturell: Feature-Kataloge statt Bürgerwege, Abnahme am Spezifikationstext, Integration erst am Projektende, und Priorität nach Lautstärke statt nach Nutzen.
Dann wirkt das Projekt modern – bis man zusieht, dass der Alltag nicht erledigt ist. Wer nur Ziegel stapelt, baut keinen Raum.
Was es nicht ist
User-Story-getriebene Entwicklung ist kein Ersatz für Fachrecht, Architektur oder Barrierefreiheit und kein reines Agil-Theater. Sie steuert Schnitt und Lieferung – sie ersetzt weder Verfahren noch den Willen, Nutzen vor Katalog zu stellen.
Story steuert Schnitt. Akzeptanz steuert fertig. Keines ersetzt die Haltung, „Anforderung erfüllt“ ohne Demo-Wert abzulehnen.
Drei Säulen
1. Story als Nutzen-Vertrag
Formulierung mit Rolle, Ziel und Warum. Akzeptanzkriterien, die man demonstrieren kann. Story-Mapping entlang der Bürgerreise – von Antrag über Status bis Bescheid und Rechtsbehelf. Fertig heißt: Demo-Wert, nicht nur Haken in der Liste.
2. Inkrement als Lieferform
Vertikale Slices statt horizontaler Schichten bis zum Big Bang. Frühe Integration der kritischen Wege. Häufige Demos am echten Flow. Messbar: Zeit bis nutzbares Inkrement; Abbruchquote. Klein liefern heißt lernen, bevor es teuer wird.
3. Priorität und Haltung
Product Ownership: Nutzen vor Ticket-Menge. Stakeholder sehen Bürgerwege, nicht nur Meilenstein-Folien. Anforderung erfüllt ohne Nutzen ist unfertig. User-Story-getrieben bauen heißt: schneiden, liefern, prüfen – nie nur spezifizieren und hoffen.
Der kulturelle Kern
| Ohne Story-Steuerung | Mit User-Story-getriebener Entwicklung |
|---|---|
| Feature-Liste / Organigramm | Story: Wer · Was · Warum |
| Big-Bang-Release | Inkremente mit Demo-Wert |
| Abnahme = spezifiziert | Abnahme = erledigt |
| Priorität: Lautstärke | Priorität: Nutzen + Risiko |
Die Leitfrage: Bauen wir Systeme für die Organisation – oder erledigbare Wege für den Bürger, in kleinen, prüfbaren Schritten?
Entscheidungsfilter
- Gibt es für den kritischen Bürgerweg eine klare Story (Wer · Was · Warum)?
- Sind Akzeptanzkriterien so formuliert, dass man sie demonstrieren kann?
- Wird in kleinen vertikalen Inkrementen geliefert – oder erst am Ende integriert?
- Steuert Nutzen und Risiko die Priorität – oder nur Lautstärke?
- Zählt „fertig“ erst, wenn der Nutzen im Flow erledigt werden kann?
Kurzformel
Bürgerziel als Story · klein liefern · am Nutzen prüfen