Von der Anforderung zur User Story mit SAP Cloud ALM
Für zukünftige SAP Einführungs- und Migrationsprojekte ist die Strategie von SAP klar definiert: Das geht effizient und nachhaltig mit SAP Cloud ALM! Diese Meinung teilt blue.works ebenfalls. Aus diesem Grund beleuchtet der nachfolgende Blog wie man von den Anforderungen zu den User Stories gelangt. Die Vorgeschichte dazu, wie man vom Prozessumfang zum Anforderungsbacklog gelangt ist HIER beschrieben.
Das Beispiel: Transformationsprojekt für S/4HANA private Edition
Die nachfolgenden Erklärungen gehen von einem S/4HANA Transformationsprojekt aus, nicht genau spezifiziert ob on-premise, private oder public Cloud, wobei eher angelehnt an on-premise oder private Cloud. Zeitlich gesehen, befinden wir uns in der SAP Activate Methodologie in der Realize-Phase. Der Blog geht davon aus, dass ein Projekt in SAP Cloud ALM bereits angelegt ist, die Anforderungen erfasst, detailliert spezifiziert, genehmigt und der Realize-Phase zugewiesen sind.
Die User Story im Kontext
Um die User Story in den Kontext eines Projektes und dessen Anforderungen zu stellen wird hier der Begriff der User Story zu erläutern versucht. Die Menge der Arbeit (Backlog), die von einem Projekt geliefert werden soll, sind die Anforderungen. Die Bereitstellung dieser Funktionalität erfordert User Stories. Diese beschreiben, wie die Anforderungen aus den Geschäftsbereichen durch Entwickler, IT-Mitarbeiter, Tester usw. umgesetzt werden.
Kurz definiert: Die aus den Anforderungen erstellten User Stories teilen die zu erledigende Arbeit eines Projektes in kleinere, nachvollziehbare und umsetzbare Aufgaben.
Die Beziehungen der User Story zu anderen Belegen
Um den Kontext einer User Story weiter zu erläutern zeigt die nachfolgende Grafik die Beziehung einer User Story zu anderen Belegen in SAP Cloud ALM.
Die Beziehungen der User Story zum Prozess und der Prozesshierarchie
Die nachfolgende Grafik schliesst die Übersicht über den Kontext einer User Story ab, indem aufgezeigt wird wie sich eine User Story zu Prozessen und der Prozesshierarchie verbindet.
Vollständige Nachvollziehbarkeit
Mit der User Story wird nach dem Projekt, den Umfängen, den Lösungsszenarien, den Lösungsprozessen und den Anforderungen ein weiteres Element verwendet. Dies erhöht etwas die Komplexität. Allerdings ist aus obigen Grafiken ersichtlich, dass beinahe jedes Element mit jedem verknüpft ist. So entsteht eine vollumfängliche Verfolgbarkeit durch alle Elemente hindurch was in komplexen Projekten einen unglaublichen Mehrwert bietet.
Wer legt User Stories an?
Streng nach agilem Theoriebuch würde der Product Owner die User Stories aus den spezifizierten Anforderungen heraus anlegen. Die Praxis in SAP-Projekten sieht teilweise anders aus, da im SAP Bereich nicht immer agil gearbeitet wird. Oft kommt es vor, dass Entwickler oder Berater die User Stories selbst anlegen und direkt mit den notwendigen technischen Informationen anreichern.
Was geschieht in welchem Status?
In der folgenden Grafik werden die drei wichtigsten Stati einer User Story betrachtet. Daneben sind noch die zwei Stati «Gesperrt» und «nicht relevant» verfügbar. Auf diese wird hier nicht weiter eingegangen.
User Stories mit Unteraufgaben
Um eine User Story noch granularer zu unterteilen, ist es möglich, Unteraufgaben zu jeder User Story mit der Beziehung 1:n anzulegen. Der Erfüllungsgrad der Unteraufgaben ist direkt in der Kopfzeile einer User Story ersichtlich.
Der Inhalt einer User Story
Wieder streng nach agilem Theoriebuch, müsste die User Story in einem Satz nach dem Format «Ich als [ROLLE] möchte [FUNKTION], damit [NUTZEN]» erfasst werden. Wiederum sieht es in der Praxis etwas anders aus. Die Struktur des Inhalts kann, da es ein Freitextfeld ist, frei gewählt werden. Punkte wie «Beschreibung», «Kommentar» und «Defintion of Done» machen beispielsweise Sinn.
Drei Tipps aus der Praxis
Der Titel einer User Story ist verpflichtend. Da die Beziehung Anforderung – User Story 1:n sein kann, empfiehlt es sich dem Titel der User Story einen Präfix zu geben. SAP Cloud ALM bietet auf der Aufgaben App aktuell keine Filtermöglichkeit, um User Stories nach der zugewiesenen Anforderung zu suchen. Nehmen Sie mit uns Kontakt auf und wir verraten Ihnen einen kleinen Umweg, wie es eben doch möglich ist.
Die Sache mit den Unteraufgaben kann durchaus Sinn machen. Wenn wir uns die Beziehungen zwischen Anforderung – User Story – Unteraufgabe ansehen so ist diese 1:n:m. So entstehen rasch sehr viele Unteraufgaben und das kann (muss nicht) zu Unübersichtlichkeit führen. Zusätzlich zu erwähnen ist hier, dass Unteraufgaben nur an der User Story angehängt sind und nicht direkt an der Anforderung.
Da in der Praxis nicht nur ein einzelner Product Owner User Stories anlegt, können diese rasch mit sehr unterschiedlicher Inhaltsstruktur angelegt sein. Damit dies nicht geschieht empfiehlt es sich für die Anlage von User Stories ein Template zu hinterlegen. Immer wenn eine neue User Story angelegt wird, kann das Template mit einer entsprechend vordefinierten Struktur verwendet werden. Das hilft die User Stories konsistent gegen die «Defintion of Ready» zu prüfen. Wie Sie übrigens eine Template User Story entweder bearbeiten oder wieder löschen ist etwas versteckt in Cloud ALM. Nehmen Sie mit uns Kontakt auf und wir zeigen Ihnen das, und noch viel mehr, sehr gerne.
Fazit
Zusammengefasst bietet SAP Cloud ALM eine klare und effiziente Strategie um generell SAP Activate von der Theorie in die Praxis zu bringen. Mit SAP Cloud ALM, mit SAP Activate, mit dem vordefinierten Best-Practice Inhalt von SAP und auch dem Fit to Standard Ansatz werden S/4HANA Tranformationen effizienter und transparenter und müssen nicht auf «weissem Papier» beginnen. Der strukturierte Ansatz zur Erstellung eines Anforderungs-Backlogs sowie weitere Unterteilung in User Stories, wie im Blog erläutert, unterstreicht die Bedeutung einer sorgfältigen Planung und Umsetzung der Fit to Standard – Workshops. Behalten Sie die wichtigen Schritte im Blick und freuen Sie sich auf zukünftige Blogposts, die Ihr Projekt zum Erfolg führen werden.