patrick/digitom_cc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
digitom_cc/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_leitfaden_user-stories.yaml

470 lines
No EOL
16 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# =============================================================================
# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN
# =============================================================================
# Modul: Stakeholder-Management (SHM)
# Typ: Arbeitsmaterial (Leitfaden)
# Version: 1.0
# Datum: 2025-12-09
# Status: Final
# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131
# =============================================================================
meta:
dokument_id: "SHM-A-01"
name: "Leitfaden User Stories"
typ: "Arbeitsmaterial"
zweck: |
Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen
aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte
Bedarfe in konkrete, nachvollziehbare Funktionswünsche.
zielgruppe: "Stakeholder-Manager:innen"
kontext: |
Im DIGIT-Kontext helfen User Stories, die Perspektive der
Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen.
Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung).
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
status_dokument:
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
inhaltlich_abgenommen_durch:
- person: "DPM-Teammitglied"
datum: "2025-09-17"
- person: "DPM-Leitung"
datum: null
abgenommen_in_gesamtkonzept: false
referenzen:
- dokument: "shm_bedarfsbewertung.yaml"
abschnitt: "schritt_0"
beschreibung: "Integration in Bedarfsbewertungs-Prozess"
- dokument: "shm_schema_bedarfssteckbrief.yaml"
abschnitt: "user_stories"
beschreibung: "Dokumentation der erhobenen User Stories"
# =============================================================================
# GRUNDLAGEN
# =============================================================================
grundlagen:
definition: |
User Stories beschreiben Anforderungen aus Sicht der Nutzenden.
Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare
Funktionswünsche.
grundformat:
schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]"
elemente:
- element: "Rolle"
beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')"
beispiele:
- "Sachbearbeiter*in Bauamt"
- "Abteilungsleitung"
- "Bürger*in"
- "Antragsteller*in"
- element: "Funktionalität"
beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)"
beispiele:
- "Bauanträge nach Flurstücknummer durchsuchen"
- "Urlaubsanträge digital genehmigen"
- "Bearbeitungsstatus online einsehen"
- element: "Nutzen"
beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)"
beispiele:
- "zusammenhängende Anträge schnell identifizieren"
- "Prozess auch im Homeoffice funktioniert"
- "nicht telefonisch nachfragen müssen"
mehrwert:
- aspekt: "Perspektivwechsel"
beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf"
- aspekt: "Verständlichkeit"
beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache"
- aspekt: "Priorisierung"
beschreibung: "Nutzen wird explizit und bewertbar"
- aspekt: "Validierung"
beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'"
# =============================================================================
# SCHRITT-FÜR-SCHRITT-ANLEITUNG
# =============================================================================
anleitung:
# ---------------------------------------------------------------------------
# SCHRITT 1: VORBEREITUNG
# ---------------------------------------------------------------------------
schritt_1:
name: "Vorbereitung des Gesprächs"
vor_dem_termin_klaeren:
- "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)"
- "Welcher Prozess ist betroffen?"
- "Gibt es Vorarbeiten oder Dokumentationen?"
materialien_bereithalten:
- "Bedarfs-Steckbrief"
- "Ggf. Prozessvisualisierung"
- "Beispiel-User-Stories zur Illustration"
# ---------------------------------------------------------------------------
# SCHRITT 2: EINSTIEG
# ---------------------------------------------------------------------------
schritt_2:
name: "Einstieg ins Gespräch"
grundprinzip:
falsch: "Welche User Stories haben Sie?"
richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten."
leitfragen_einstieg:
- "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt."
- "Was würde Ihnen die Arbeit erleichtern?"
- "Wobei verlieren Sie die meiste Zeit?"
# ---------------------------------------------------------------------------
# SCHRITT 3: ROLLEN IDENTIFIZIEREN
# ---------------------------------------------------------------------------
schritt_3:
name: "Die richtigen Rollen identifizieren"
typische_rollen:
verwaltungsintern:
- "Sachbearbeiter*in [Amt]"
- "Abteilungsleitung"
- "Verwaltungsmitarbeitende"
- "Amtsleitung"
- "Datenschutzbeauftragte*r"
verwaltungsextern:
- "Bürger*in"
- "Antragsteller*in"
- "Unternehmen"
- "Andere Institute"
- "Dienstleister"
wichtiger_hinweis: |
Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle"
# ---------------------------------------------------------------------------
# SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN
# ---------------------------------------------------------------------------
schritt_4:
name: "Funktionalitäten herausarbeiten"
prinzip: "Von der Lösung zum Bedarf"
uebersetzungen:
- stakeholder_sagt: "Wir brauchen eine Datenbank"
shm_fragt: "Was möchten Sie damit tun?"
story_wird: "...möchte ich Anträge zentral verwalten..."
- stakeholder_sagt: "Das System ist zu langsam"
shm_fragt: "Wobei genau verlieren Sie Zeit?"
story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..."
- stakeholder_sagt: "Wir wollen alles digitalisieren"
shm_fragt: "Was genau soll digital werden?"
story_wird: "...möchte ich Anträge online einreichen..."
# ---------------------------------------------------------------------------
# SCHRITT 5: NUTZEN EXPLIZIT MACHEN
# ---------------------------------------------------------------------------
schritt_5:
name: "Den Nutzen explizit machen"
nachfragen:
- "Warum ist das wichtig?"
- "Was können Sie dann besser machen?"
nutzen_kategorien:
- kategorie: "Effizienz"
beispiel: "...damit ich mehr Anträge bearbeiten kann"
- kategorie: "Qualität"
beispiel: "...damit weniger Fehler passieren"
- kategorie: "Service"
beispiel: "...damit Bürger*innen schneller Antworten erhalten"
- kategorie: "Compliance"
beispiel: "...damit wir gesetzeskonform arbeiten"
- kategorie: "Transparenz"
beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist"
# ---------------------------------------------------------------------------
# SCHRITT 6: FORMULIEREN
# ---------------------------------------------------------------------------
schritt_6:
name: "User Stories formulieren"
beispiel_gut:
rolle: "Sachbearbeiterin im Bauamt"
funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können"
nutzen: "zusammenhängende Anträge schnell identifiziere"
vollstaendig: |
Als Sachbearbeiterin im Bauamt
möchte ich Bauanträge nach Flurstücknummer durchsuchen können
damit ich zusammenhängende Anträge schnell identifiziere
beispiel_schlecht:
rolle: "Nutzer"
funktionalitaet: "eine bessere Suche"
nutzen: "es schneller geht"
vollstaendig: |
Als Nutzer
möchte ich eine bessere Suche
damit es schneller geht
probleme:
- "Rolle zu unspezifisch"
- "Funktionalität zu vage"
- "Nutzen nicht konkret"
# ---------------------------------------------------------------------------
# SCHRITT 7: PRIORISIEREN UND VALIDIEREN
# ---------------------------------------------------------------------------
schritt_7:
name: "Stories priorisieren und validieren"
validierungsfragen:
- "Habe ich Sie richtig verstanden?"
- "Ist diese Reihenfolge nach Wichtigkeit korrekt?"
- "Fehlt noch etwas Wesentliches?"
priorisierungsstufen:
- stufe: "Kritisch"
beschreibung: "Ohne geht es nicht"
- stufe: "Wichtig"
beschreibung: "Deutliche Verbesserung"
- stufe: "Nützlich"
beschreibung: "Wäre schön"
# =============================================================================
# TYPISCHE HERAUSFORDERUNGEN
# =============================================================================
herausforderungen:
# ---------------------------------------------------------------------------
# HERAUSFORDERUNG 1: LÖSUNGSDENKEN
# ---------------------------------------------------------------------------
loesungsdenken:
name: "Der Stakeholder denkt nur in Lösungen"
technik: "Die 5-Warum-Methode"
beispiel_dialog:
- sprecher: "Stakeholder"
aussage: "Wir brauchen ein Dashboard"
- sprecher: "SHM"
aussage: "Warum brauchen Sie ein Dashboard?"
- sprecher: "Stakeholder"
aussage: "Um die Zahlen zu sehen"
- sprecher: "SHM"
aussage: "Warum müssen Sie die Zahlen sehen?"
- sprecher: "Stakeholder"
aussage: "Um zu erkennen, wo sich Anträge stauen"
resultierende_story: |
Als Abteilungsleitung
möchte ich Engpässe im Antragsprozess erkennen
damit ich Ressourcen umverteilen kann
# ---------------------------------------------------------------------------
# HERAUSFORDERUNG 2: ALLES DRINGEND
# ---------------------------------------------------------------------------
alles_dringend:
name: "Alles ist wichtig und dringend"
technik: "Relatives Priorisieren"
hilfreiche_fragen:
- "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?"
- "Was würde am meisten wehtun, wenn es fehlt?"
- "Was nutzen Sie täglich vs. was nur monatlich?"
# =============================================================================
# QUALITÄTSKRITERIEN
# =============================================================================
qualitaetskriterien:
invest:
name: "INVEST-Kriterien"
beschreibung: "Qualitätsstandard für gute User Stories"
kriterien:
- buchstabe: "I"
name: "Independent"
beschreibung: "Unabhängig von anderen Stories"
- buchstabe: "N"
name: "Negotiable"
beschreibung: "Nicht in Stein gemeißelt"
- buchstabe: "V"
name: "Valuable"
beschreibung: "Klarer Nutzen erkennbar"
- buchstabe: "E"
name: "Estimable"
beschreibung: "Größe grob einschätzbar"
- buchstabe: "S"
name: "Small"
beschreibung: "In überschaubarer Zeit umsetzbar"
- buchstabe: "T"
name: "Testable"
beschreibung: "Überprüfbare Erfolgskriterien"
# =============================================================================
# BEISPIEL-STORIES
# =============================================================================
beispiel_stories:
- bereich: "Bürgerservice"
story:
rolle: "Bürger*in"
funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen"
nutzen: "ich nicht telefonisch nachfragen muss"
volltext: |
Als Bürger*in
möchte ich den Bearbeitungsstatus meines Antrags online einsehen
damit ich nicht telefonisch nachfragen muss
- bereich: "Interne Verwaltung"
story:
rolle: "Personalverantwortliche"
funktionalitaet: "Urlaubsanträge digital genehmigen können"
nutzen: "der Prozess auch im Homeoffice funktioniert"
volltext: |
Als Personalverantwortliche
möchte ich Urlaubsanträge digital genehmigen können
damit der Prozess auch im Homeoffice funktioniert
- bereich: "Schnittstellen"
story:
rolle: "Mitarbeitende im Einwohnermeldeamt"
funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen"
nutzen: "Bürger*innen sich nicht doppelt melden müssen"
volltext: |
Als Mitarbeitende im Einwohnermeldeamt
möchte ich Meldedaten automatisch ans Finanzamt übertragen
damit Bürger*innen sich nicht doppelt melden müssen
# =============================================================================
# CHECKLISTE FÜR SHM
# =============================================================================
checkliste:
name: "Checkliste für Stakeholder-Manager"
pruefpunkte:
- id: "CK-01"
pruefpunkt: "Rollen spezifisch identifiziert"
beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'"
- id: "CK-02"
pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)"
beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'"
- id: "CK-03"
pruefpunkt: "Nutzen explizit gemacht"
beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'"
- id: "CK-04"
pruefpunkt: "Stories mit Stakeholder validiert"
beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'"
- id: "CK-05"
pruefpunkt: "Prioritäten geklärt"
beispiel: "Kritisch / Wichtig / Nützlich zugeordnet"
- id: "CK-06"
pruefpunkt: "Zusammenhang zum Problem hergestellt"
beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse"
- id: "CK-07"
pruefpunkt: "In Bedarfs-Steckbrief übertragen"
beispiel: "Stories im Schema-konformen Format dokumentiert"
# =============================================================================
# DOKUMENTATION
# =============================================================================
dokumentation:
nach_dem_gespraech:
- schritt: 1
aktion: "Stories im Steckbrief sauber dokumentieren"
- schritt: 2
aktion: "Priorisierung vermerken"
- schritt: 3
aktion: "Offene Punkte notieren"
- schritt: 4
aktion: "Validierungstermin vereinbaren"
ablage:
ziel_dokument: "Bedarfs-Steckbrief"
ziel_abschnitt: "user_stories"
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
# =============================================================================
# HINWEISE
# =============================================================================
hinweise:
- typ: "Tipp"
text: |
Die erste User Story ist die schwerste. Mit etwas Übung entwickeln
Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe
strukturiert zu erfassen.
- typ: "Warnung"
text: |
Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist
es, den Bedarf zu verstehen – nicht, ihn zu lösen.
- typ: "Best Practice"
text: |
Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie
konkrete User Stories formulieren. Der Kontext hilft, die
richtigen Fragen zu stellen.
# =============================================================================
# ÄNDERUNGSHISTORIE
# =============================================================================
aenderungshistorie:
- version: "1.0"
datum: "2025-12-09"
aenderung: "Initiale Erstellung aus PDF-Vorlage"
autor: "DIGITOM-Projekt"
quelle: "Konzept_DPM_Abnahme20230925, Seiten 125-131"
Reference in a new issue View git blame Copy permalink