# ============================================================================= # 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"