Stefan Jackmuth
Durch ein anstehendes Transformationsprojekt beschäftige ich mich wieder einmal mit den Grundlagen von Agile Auditing, wie dem Einsatz von guten User Stories. Die Internal Auditor meines Mandanten möchten nämlich möglichst früh erfahren, warum sie agile Methoden einsetzen sollten und welche Änderungen sich für ihre Arbeitsweise ergeben. Oha, das klingt doch nach einer guten Story, oder doch nicht?
Warum überhaupt User Stories?
Aus meiner Sicht, weil sie nahezu alle Werte des Agile Manifesto unterstützen oder durch den Aufbau Aspekte der Werte in den Fokus nehmen. Zusätzlich ist der Aufbau von User Stories sehr einfach zu verstehen. Die erstellten User Stories wandern ins Backlog und stellen damit so etwas, wie den Arbeitsvorrat für eine Prüfung dar.
Für uns als Team sind sie Grundkonstrukt für...
die Planung und Abbildung der wirklichen Arbeit,
die Kommunikation im Prüfteam,
die Kommunikation mit dem Auftraggeber,
die Kommunikation mit dem Auditee,
den Überblick, ob wir noch auf Kurs sind.
In der Praxis nutze ich das Backlog oder ein Board, um mit den Ansprechpartnern zu sprechen und zu visualisieren, was wir vorhaben und wo wir gerade stehen. Bestimmt habe ich noch Aspekte vergessen, aber die obenstehende Liste sollte Grund genug sein, dass man User Stories etwas genauer unter die Lupe nimmt.
Struktur von User Stories
User Stories sollen den späteren Benutzer oder Kunden in den Fokus stellen und sind nach einem einfachen Schema formuliert: Als [Nutzer] möchte ich [Funktion], damit / um / weil [Wert].
Sie werden genutzt, um die Arbeit im Audit zu strukturieren und den Mehrwert ggü. dem Kunden (z. B. Auditee, Chief Audit Executive, Audit Committee etc.) zu kommunizieren.
Wenn man nach Informationen zu User Stories sucht, lassen sich die üblichen Beispiele aus der Softwareentwicklung finden:
Ein Neukunde soll einen neuen Account erstellen können, um im Webshop Artikel zu bestellen.
Die User Stories werden typischerweise auf (digitalen) Notizzetteln festgehalten und durch weitere Angaben verfeinert. Vor Corona hatten die physischen Zettel einen gewaltigen Vorteil: Kurze und prägnante Formulierungen sind gefragt, für mehr ist kein Platz. Durch verschiedenfarbige Zettel lassen sich Kategorien etc. leicht erkennen.
Auch vor Corona gab es natürlich schon Systeme, sei es Jira (als großer Platzhirsch), Meistertask etc., um sich digital zu verwalten. In meiner Wahrnehmung probieren jetzt einfach mehr Auditor diese oder auch einfache Tools in Kombination mit agilen Arbeitsweisen aus. Oftmals wird dann das genommen, was schon in den Softwarepaketen (Microsoft 365) da ist, z. B. der Microsoft Planner.
Audits, einfach agil!
Sie möchten auf einen Schlag geballtes Wissen tanken, was Ihr nächstes Audit von 0 auf 100 bringt?
Hier anmelden!
Die Übertragung auf Internal Audit
Die Übertragung auf unsere Arbeitsrealität als Internal Auditor empfinde ich immer wieder als Herausforderung. Ich versuche sie einmal an folgendem vereinfachtem Audit zu beschreiben: Mit unserem IT-Audit-Team haben wir für einen Versicherungskunden den Zahlungsverkehrsprozess (abgekürzt als ZV-Prozess) und die korrespondierenden Systeme untersucht. Für die Interne Revision des Kunden war der Prozess in großen Teilen eine Black Box. Daraus hat sich die erste User Story ergeben:
Die Interne Revision möchte einen Gesamtüberblick über den ZV-Prozess, um die Risiken des Prozesses genauer zu kennen und für die zukünftige Planung besser berücksichtigen zu könnnen.
Was schnell auffällt: In der Story sind zwei [Werte] enthalten und die Story kann vielleicht nicht mehr als kurz und prägnant bezeichnet werden. Schauen wir uns ein weiteres Beispiel an, bevor wir generelle Tipps und Tricks aufstellen.
Der:die Leiter:in Zahlungsverkehr möchte die Rezertifizierungsberichte für das Filesystem geprüft haben, um sicherzustellen, dass die regulatorische Anforderungen korrekt umgesetzt sind.
Die obenstehende User Story ist während des Kick-Offs mit dem Fachbereich entstanden. Sie soll dabei sinnbildlich für die Abbildung der „Wünsche“ des Fachbereichs an unser Audit stehen.
Exkurs für Nicht-Banker/Versicherer
Eine „regelmäßige und anlassbezogene Überprüfung [der Berechtigungen] innerhalb angemessener Fristen“ ist nach z. B. „Versicherungsaufsichtliche Anforderungen an die IT“ (kurz VAIT) durch die fachlich Verantwortlichen vorzunehmen. Typischerweise werden dafür durch die IT Berichte mit den Benutzern und den zugewiesenen Berechtigungen erstellt und vom Fachbereich kontrolliert.
Was macht eine gute User Story aus?
Kurz und prägnant sind natürlich nicht die einzigen Qualitätskriterien und zum Glück gibt es diverse, sehr spannende Ausarbeitungen zum Thema. Ähnlich, wie Ziele SMART sein sollen, gibt es bei User Stories das Akronym INVEST. Übrigens ein Ansatz, der schon 2003 publiziert wurde.
Da soll mir noch einmal jemand sagen, dass Agilität alter Wein in neuen Schläuchen sei. Es ist eher alter Wein in alten Schläuchen, den wir nur gerade im Keller entdeckt haben.
INVEST in your Stories...
- I – Independent – eine Story sollte nicht von einer anderen Story abhängig sein
- N – Negotiable – eine Story gibt die Leitplanken vor, aber lässt Verhandlung über die genaue Ausgestaltung zu
- V – Valuable – eine Story bringt einen Mehrwert für das Unternehmen, nicht für uns als Internal Audit
- E – Estimable – eine Story sollte schätzbar und damit einhergehend einen konkreten Anhaltspunkt bieten, was alles in der Story umzusetzen ist
- S – Small – eine Story sollte recht klein und konkret gestaltet sein, dadurch wird auch klarer, was im Rahmen der Leitplanken zu erledigen ist
- T – Testable – eine Story muss überprüfbar sein, um dem Team Anhaltspunkte zu geben, ob sie erledigt ist oder nicht
Beispiel 1 - der klare Auftrag
Wenden wir INVEST auf unsere beiden Beispiele an, wobei ich die Reihenfolge umdrehen möchte:
Der:die Leiter:in Zahlungsverkehr möchte die Rezertifizierungsberichte für das Filesystem geprüft haben, um sicherzustellen, dass die regulatorische Anforderungen korrekt umgesetzt sind.
I – Ja, klare Abgrenzung des Themas, das sich auch gut von anderen Stories trennen lässt
N – Ja, genauer Umfang der Prüfungshandlung und was das exakte Soll aus „regulatorische Anforderung“ ist, kann vom Team ausgestaltet werden
V – Ja, das Unternehmen erhält eine Aussage, ob in diesem kleinen Bereich die Regulatorik umgesetzt ist (ohne hier die Diskussion über den Mehrwert, der dadurch entsteht beginnen zu wollen)
E – Ja, da das Thema gut abgegrenzt ist, kann eine Schätzung gelingen
S – Ja, da kleine Prüfungshandlung mit klaren Sollvorgaben...
T – ... mit klar überprüfbaren Aspekten: Das Team weiß, wann es fertig ist und wann nicht.
Beispiel 2 - die Erwartungshaltung
Die Interne Revision möchte einen Gesamtüberblick über den ZV-Prozess, um die Risiken des Prozesses genauer zu kennen und für die zukünftige Planung besser berücksichtigen zu könnnen.
I – Nein, da sich erst aus allen anderen User Stories der Rückschluss auf die Risiken geben lässt
N – Ja, aber die Leitplanken sind sehr weit gesteckt
V – Jein, da der zu realisierende Mehrwert sehr grob umrissen ist
E – Nein, da potentiell vieles im Unbekannten liegt
S – Nein, da es so etwas, wie die Erwartungshaltung an die Prüfung beschreibt
T – Nein, da es nicht klar ist, wann der Kunde (die Interne Revision) zufrieden ist
Was lässt sich aus Beispiel 2 lernen?
Dass INVEST uns an dieser Stelle nur zeigt, dass es keine gute User Story ist. Das Beispiel 2 illustriert eine Erwartungshaltung des Kunden (ich verwende bewusst nicht das Wort Ziel, da es in der aktuellen Form nicht SMART ist), nicht eine gut bearbeitbare User Story. Trotzdem ist das so formulierte Beispiel ein guter Einstieg, um weitere User Stories zu schreiben und diese Erwartungshaltung zu operationalisieren. Dafür gibt es noch einige weitere gelungene Methoden, die aber für uns als Internal Audit noch eine gewisse Adaption benötigen. Deswegen dazu mehr im nächsten Beitrag.
Fazit
User Stories sind für mich ein tolles Werkzeug geworden, um Kommunikation zu lenken und nichts aus der Diskussion heraus zu lassen. In Verbindung mit einem Board (dazu kommen wir noch) und einem agilen Framework, wie Scrum (auch dazu kommen wir noch), kann ich leicht sehen, wo ich im Audit stehe. Ich erreiche Transparenz, auch weil von außen gut erkennbar ist, ob die Wünsche des Kunden (in diesem Fall eine Revisionsabteilung) eingeflossen sind und wir auf einem gemeinsamen Kurs sind.
Auch wenn ich bereits viele Listen in diesem Beitrag genutzt habe, möchte ich noch eine weitere Nutzen und INVEST um meine persönlichen Tipps ergänzen, auf was ich bei User Stories achte:
von groß (zum Beispiel einer Erwartungshaltung oder Risiken) nach klein arbeiten
immer im Team beginnen zu schreiben, aber eine Person am Schluss die Sprache vereinheitlichen
Akzeptanzkriterien (keine Sorge, hier steht bald der Link zum nächsten Artikel) vereinbaren, da sie die User Story besser überprüfbar machen
Jede User Story muss außerdem folgenden Fragen begegnen können:
Welches Risiko wird mit der User Story geprüft?
Ist die Prüfungshandlung relevant für unseren Auftrag?
Ist uns klar, welche Prüfungshandlungen vorgenommen werden sollen?
P.S. die User Story aus der Einleitung können Sie gerne selbst einmal bewerten und mir per LinkedIn, Xing oder Mail schreiben!
Sie haben immer noch nicht genug
von Agilität is a groaßer Schmarrn?
Mit unserem Newsletter erhalten Sie alle zwei Wochen
- aktuelle Artikel und Whitepaper,
- unsere Kategorien "schon gewusst?" und "was uns gerade inspiriert"
- und die aktuellen Termine unserer Audinare.
Was erhalten wir dafür?
- Die Chance Sie von uns und unserem Know-how zu überzeugen.