User Story: Nutzen, Prozesse und Kriterien im CRM

Der Hauptunterschied liegt in der Perspektive und der Kommunikation. Eine herkömmliche Anforderung ist oft technisch oder abstrakt formuliert, während eine User Story immer kurz, leicht verständlich und aus Sicht des Endanwenders („Als [Rolle] möchte ich...“) geschrieben ist. Sie fördert das Gespräch statt einer starren Spezifikation.

Der Nutzen-Teil (Value) ist der wichtigste Aspekt, da er den Mehrwert für den Anwender oder das Unternehmen klar definiert. Nur wenn der Nutzen klar ist, kann das Entwicklungsteam die Story richtig priorisieren und sicherstellen, dass die umgesetzte CRM-Funktion das tatsächliche Problem des Nutzers löst.

Der Product Owner (oder ein Vertreter der Fachabteilung) ist der primäre Besitzer der Story. Er vertritt die Stimme des Kunden (Users), definiert die Akzeptanzkriterien und ist dafür verantwortlich, dass die Stories den Geschäftsanforderungen entsprechen, bevor sie ins CRM-System implementiert werden.

Der Fokus sollte immer auf dem Ergebnis und dem Nutzen liegen. Wenn eine Story technische Details zur Umsetzung enthält, handelt es sich meist um eine Task (Aufgabe) und nicht um eine Story. Die User Story beschreibt *was* erreicht werden soll, das Entwicklerteam entscheidet *wie* es im CRM umgesetzt wird.

Akzeptanzkriterien sind eine Liste von Bedingungen, die erfüllt sein müssen, damit die Story als "fertig" gilt. Sie werden vor der Implementierung (z.B. eines Vtiger Workflows) definiert und dienen dem Testteam als Grundlage, um zu überprüfen, ob die neue CRM-Funktion wie gewünscht arbeitet.

Der größte Fehler ist, Stories zu schreiben, die zu groß sind (Epics) oder die den Nutzen nicht klar benennen. Ein weiterer Fehler ist das Fehlen von Akzeptanzkriterien, was später zu Unklarheit darüber führt, wann die neue CRM-Anforderung wirklich abgeschlossen ist.

Ja, eine Story kann zu groß sein (dann wird sie als Epic bezeichnet). Beim Splitting wird das Epic in kleinere, unabhängige Stories zerlegt, die jeweils einen eigenen Wert liefern und in einem Sprint umgesetzt werden können. Gängige Splitting-Methoden sind die Aufteilung nach Rolle, Workflow-Schritt oder Datenmenge.

Die Stories werden nach ihrem Geschäftswert (Nutzen) und dem Aufwand bewertet. Die Stories mit dem höchsten Wert (z.B. zur Steigerung des Vertriebs) und dem geringsten Aufwand werden zuerst umgesetzt, wodurch schnellstmöglich ein messbarer Erfolg im CRM-Projekt erzielt wird.

Eine User Story sollte idealerweise einen Schritt oder einen Teilprozess eines CRM Workflows beschreiben. Zum Beispiel: *Als Vertriebsmitarbeiter möchte ich einen Lead automatisch qualifizieren, damit er in die nächste Pipeline-Phase verschoben wird.* Die Story ist die Anforderung, der Workflow (in Vtiger) ist die technische Umsetzung.

Sie beschreibt den Nutzen oft durch Segmentierung und Personalisierung, z.B.: *Als Marketing Manager möchte ich Kontakte anhand ihrer letzten Produktkäufe segmentieren, damit ich eine personalisierte Kampagne senden kann.* Dies legt die Grundlage für Automatisierungsregeln im Marketing.

Sie muss klar definieren, welche Metriken (KPIs) dargestellt werden sollen und welche Entscheidungen der Nutzer basierend auf diesen Daten treffen kann (z.B. *damit ich fundiertere Forecasts machen kann*). Sie beschreibt nicht das Layout, sondern den benötigten Geschäftseinblick.

Die häufigsten Rollen sind der Vertriebsmitarbeiter (Sales), der Marketing Manager und der Support Agent (Service), da diese die Hauptnutzer des CRM-Systems sind. Auch die Rolle des Systemadministrators (für Einstellungen und Berechtigungen) ist für Storys relevant.

Man muss die Rolle und den Kontext anpassen: *Als Vertriebsmitarbeiter unterwegs möchte ich die Kundenadresse per Spracheingabe erfassen, damit ich sie nicht manuell eintippen muss.* Die Story definiert die Anforderung unter Berücksichtigung des mobilen Nutzungsszenarios.

Sobald eine Story priorisiert und in das Sprint Backlog aufgenommen wurde (also "bereit" für die Umsetzung ist), wird sie vom Team in Tasks zerlegt. Die Tasks sind die technischen Schritte (*z.B. Datenbankfeld anlegen, UI implementieren, Testskript schreiben*), die zur Erfüllung der Story notwendig sind.

Es bedeutet, dass die Story keine starre Spezifikation ist. Sie ist eine Einladung zum Gespräch zwischen dem Product Owner und dem Entwicklungsteam. Das Team kann Vorschläge machen, wie die Story technisch am besten und effizientesten umgesetzt werden kann, ohne den definierten Nutzen zu verlieren.

Eine User Story sollte im Idealfall so klein sein, dass sie innerhalb eines Sprints (meist 1 bis 2 Wochen) fertiggestellt werden kann, inklusive Test. Nur so kann das Team schnell Feedback zur neuen CRM-Funktion erhalten und ggf. Anpassungen vornehmen.

Sie ist wertvoll, wenn der Nutzen direkt zu einem Geschäftsergebnis beiträgt, wie z.B. Zeitersparnis, Umsatzsteigerung oder Risikominimierung. Die Story muss den Nutzen klar quantifizieren (z.B. *damit wir 20% schneller Leads bearbeiten können*).

In Vtiger CRM können User Stories (oder die daraus abgeleiteten Tasks) in die Aufgabenverwaltung oder dedizierte Projektmanagement-Tools überführt werden. Das Team nutzt dann Schätzmethoden wie Planning Poker oder Story Points, um den Aufwand realistisch und gemeinsam einzuschätzen.

Man prüft, ob die Umsetzung dieser Story von anderen Stories abhängig ist. Wenn eine Story nur dann getestet oder ausgeliefert werden kann, wenn eine andere fertig ist, muss sie gesplittet oder anders formuliert werden, um Abhängigkeiten zu minimieren.

Akzeptanzkriterien hierfür wären messbar und verifizierbar, z.B.:

• "Der Speichern-Button ist auf allen Bildschirmgrößen sichtbar."
• "Die Ladezeit der Kundenakte beträgt maximal 1,5 Sekunden."
• "Der Nutzer muss maximal 3 Klicks benötigen, um einen neuen Lead anzulegen."