Techniken um zu große User Stories zu splitten

Immer dann, wenn Epics ([glossary id=’1579′ slug=’epic’ /]) oder größere User Stories ([glossary id=’1577′ slug=’user-story’ /])der Umsetzung näher kommen oder sogar direkt im nächsten Sprint umgesetzt werden sollen, müssen diese gesplittet, also in kleinere Teile unterteilt werden. Andernfalls würden diese großen Anforderungen nicht innerhalb eines Sprints realisiert werden können und sind zu dem sehr schwer zu schätzen und für den Kunden zu priorisieren.

Manchmal ist die mögliche Teilung der Anforderung dabei direkt ersichtlich und kann sofort vorgenommen werden. Bei anderen Anforderungen kann es aber durchaus hilfreich sein, ein paar einfache Regeln oder Muster zum Schneiden von Anforderungen als Hilfestellung zu nehmen.

Eine Grundlegende Eigenschaft aller Techniken zur Teilung von Anforderungen ist dabei der vertikale Schnitt. Jedes System kann dabei als ein Zusammenspiel von mehreren Schichten gesehen werden.

Dazu gehört die Logik-Ebene in der die eigentliche Programmierung steckt, die Benutzeroberfläche sowie die zugrundeliegende Datenbankschicht. Auch Frontend und Backend können als separate Schichten gesehen werden. Wichtig für eine Anforderung ist nun, dass sie einen sinnvollen Durchstich durch alle Schichten aufweist. Nur so entsteht dabei ein voll funktionsfähiges Stück Software.

Splitten nach Daten und Datenbanktabellen

Die meisten Anforderungen verändern oder benutzen verschiedene Daten während der Interaktion. Genau zwischen diesen Daten kann oft sehr einfach eine User Story in kleinere Teile gebrochen werden. Gute Indikatoren dafür sind verschiedene Datenbanktabellen oder Speicherformate. Nehmen wir als Beispiel ein Online-Portal für Stellenanzeigen. Eine mögliche User Story wäre „Als Bewerber möchte ich meine Bewerbung online verfassen können“. Diese User Story kann nun weiter gegliedert werden in:

  • Als Bewerber möchte ich ein Foto hochladen
  • Als Bewerber möchte ich meine Kontaktdaten hinterlegen
  • Als Bewerber möchte ich meinen Lebenslauf als PDF hochladen
  • Als Bewerber möchte ich mehrere Zeugnisse hochladen

Splitten nach Aufwand

In vielen Fällen lässt sich einer Anforderung in eine Basisimplementation, in der der Großteil des Aufwands steckt, und kleinere Teilschritte aufteilen. Beispielsweise ließe sich die Anforderung „Als Anbieter möchte ich Rechnungen, Bestellungen und Mahnung als PDF senden.“ Natürlich in drei einzelne User Stories teilen:

  • Rechnung als PDF versenden
  • Bestellung als PDF versenden
  • Mahnung als PDF versenden

Der eigentliche Versandt und die Textbausteine sind jedoch der geringste Aufwand an dieser User Story. Zugrunde liegen ein einheitliches PDF-Layout und eine PDF-Bibliothek. Demnach könnte die User Story besser in folgende Teile zerschnitten werden:

  • Als Anbieter möchte ich einheitliche PDFs generieren
  • Als Anbieter möchte ich Rechnungen, Bestellungen und Mahnung als PDF versenden

Hier sei noch angemerkt, dass die beiden Stories zwar nicht völlig unabhängig voneinander sind, aber die zweite durchaus mit Dummy-Content zuerst realisiert werden könnten und in einem späteren Schritt der Testinhalt durch einen Aufruf der PDF-Funktion getauscht wird.

Splitten nach unbekannten oder risikoreichen Anteilen

Einigen Anforderungen liegen komplexe Algorithmen oder spärlich dokumentierte Bibliotheken zugrunde, die einen hohen experimentellen Aufwand erfordern. Dieser reine Forschungsanteil zur Evaluation der Machbarkeit oder des passenden Tools kann oft aus einer User Story herausgeschnitten werden und als eigene Anforderung definiert werden.

Splitten nach Qualität und Ausbaustufe

Typisch für große Anforderungen ist es, dass sie bereits in der maximalen Variante angedacht wurden. Dabei gibt es oft verschiedene Ausbaustufen, in die unterschieden werden kann, ohne die eigentliche Geschäftslogik komplett aus den Augen zu verlieren. So kann zum Beispiel ein Benutzerprofil in der einfachsten Variante auch ohne ein Profilfoto auskommen oder manche Daten über direkte SQL-Befehle statt eine komfortable Administrationsoberfläche gepflegt werden.

Splitten nach Akzeptanzkriterien

Das Teilen einer User Story nach Akzeptanzkriterien führt oft zu einer der anderen Schnittmethoden und ist lediglich ein Hilfsmittel zur Identifikation der richtigen Methode oder Schnittgrenze. Nehmen wir hier das Beispiel aus dem Abschnitt „Akzeptanzkriterien“ des vorherigen Kapitel: „Als Anwender möchte ich mich anmelden“. Diese Story könnte zum Beispiel geschnitten werden in

  • Als Anwender möchte ich mich mit meiner E-Mail-Adresse und meinem Passwort anmelden
  • Als Anwender möchte ich über Fehler bei der Anmeldung informiert werden
  • Als Administrator möchte ich fehlerhafte Anmeldungen in der Datenbank protokollieren
  • Als Administrator möchte ich Benutzer nach 3 fehlerhaften Anmeldeversuchen automatisch deaktivieren lassen

Priorisierung von Anforderungen 2/5 – Nach finanziellem Wert

Die verschiedenen Möglichkeiten zur Priorisierung von Anforderungen stellen wir ein einer kleinen Artikelserie dar. Bisher erschienen:

Nach finanziellem Wert

Alle Projekte und Unternehmen streben in irgendeiner Art und Weise die Gewinnmaximierung an. Das ist das Grundprinzip jedes wirtschaftlichen Handelns. Dabei kann man entweder den Gewinn über eine Erhöhung der Geldeinnahmen maximieren, oder über eine Senkung der Kosten. Einzelnen Anforderungen ist es meist schwer einen exakten Wert zuzuweisen. Bei größeren Themengebieten oder Epics ([glossary id=’1579′ slug=’epic’ /]) ist dies schon einfacher. So kann über die Marktforschung grob abgeschätzt werden wie viele Nutzer die Anforderung dem Projekt bescheren würde oder wie viele der bestehenden Nutzer mehr für den Service oder das Produkt ausgeben würden. So kann vielleicht errechnet werden, dass das Hinzufügen einer Bezahlmöglichkeit per Kreditkarte statt lediglich des bestehenden Lastschriftverfahrens einen Mehrgewinn von 20.000 € bedeutet. Sind die Kosten für die Entwicklung geringer ist dies ein sinnvolles Feature und sollte entsprechend hoch priorisiert werden.

Andererseits ist es auch möglich über bestimmte Funktionen Kosten einzusparen. So lassen sich gewisse Prozesse, die im Moment Ressourcen auf Seiten des Kunden erfordern durch eine Automatisierung effizienter gestalten. Typisches Beispiel dafür ist das Rechnungswesen. Während bei ein paar Mahnungen pro Monat die Anfertigung der Mahnung per Hand die kostengünstigste Methode ist, würde sich vielleicht bei mehreren hundert Mahnungen eine Automatisierung sehr schnell amortisieren.

Die besonderen Herausforderungen von Webprojekten

Web- oder Multimedia-Projekte stellen eine ganz besondere Herausforderung für das Projektmanagement und dessen Methoden dar. Zum einen ist dieses Feld noch vergleichsweise jung und eine Professionalisierung fand erst in den letzten Jahren wirklich statt. Zum anderen haben sie einige typische Eigenschaften, die das Leben als Projektleiter und vor allem den Einsatz von Management-Frameworks aus der Software-Entwicklung deutlich erschweren.

Nehmen wir zuerst die reinen Eckdaten. Ein typisches Projekt dauert selten länger als 3 Monate, Pflege und Weiterentwicklung ausgenommen. Projektteams bestehen selten aus mehr als 10 Personen. Im Schnitt ist eher eine Laufzeit von 4 Wochen mit 5 Personen typisch für ein Multimedia-Projekt.

Hier jeden Schritt und jedes Prozess-Artefakt aus dem [glossary id=’1561′ slug=’pmbok’ /] einzuhalten, oder einen mehrwöchigen Sprint-Zyklus von Scrum nach Handbuch einzusetzen, ist utopisch und würde jeden Kosten- und Zeitrahmen sprengen.

Die nächste Herausforderung besteht in dem Projekt-Ziel. Hier hat der Kunde oft nur sehr vage Vorstellungen von dem gewünschten Ergebnis und den Möglichkeiten der angepeilten Medien-Plattformen. Er hat sicher eine starke Erwartungshaltung, geprägt durch erfolgreiche Kampagnen und Applikationen, kann diese jedoch nicht konkret kommunizieren. Dies erfordert eine deutlich stärkere Beratung und auch ein gewisses Vertrauen zwischen beiden Parteien.

Gerade Design, Konzeption, Kommunikationsstrategie und andere kreative Disziplinen stoßen oft auf Unverständnis beim Kunden, vor allem in Bezug auf den Aufwand.

Blickt man abseits des eigentlichen Projektes auf die Organisation und Arbeit in Agenturen, kommen weitere Herausforderungen hinzu, die in dieser Ausprägung in der Industrie eher selten zu finden sind.

Hier liegt die größte Herausforderung im Multitasking, bzw. Multiprojektmanagment, und einer sehr kurzlebigen Ressourcenplanung. Nicht nur die Projektleiter betreuen mehrere Kunden und Projekte gleichzeitig, auch Entwickler, Grafiker und andere Team-Mitglieder müssen mit verschiedenen Projekten parallel jonglieren. Hier ist oft die genaue Planung und Priorisierung für den Mitarbeiter unklar, oder er wird regelrecht von einem Projekt in das nächste geworfen.

Das erhöht zum einen die Aufwände, die bei Task- und Projekt-Wechseln anfallen (ramp-up und ramp-down), zum anderen aber auch die Frustration der Mitarbeiter. Als Konsequenz der schnell wechselnden Projekt-Planung für einen Mitarbeiter fehlt diesem oft die Chance zu Projektbeginn mit den anderen Teammitgliedern starten zu können, und damit auf einem einheitlichen Informationsstand zu agieren und zu Projektende die Früchte des Erfolgs ernten zu können. Ist ein Projekt zu Ende und der Live-Einsatz beim Kunden ein voller Erfolg geworden, stecken viele Teammitglieder bereits im Stress des nächsten Projektes und können den Projekterfolg, und damit auch ihren ganz persönlichen Beitrag zum Projekt, gar nicht richtig genießen.

Was tun wenn Kunde nicht immer verfügbar oder bevollmächtigt?

Das komplette Anforderungsmanagement und das [glossary id=’1572′ slug=’product-backlog’ /] als Motor der gesamten Entwicklung basieren auf der engen Zusammenarbeit mit dem Kunden. Der Projektleiter sollte in ständigem Kontakt mit dem Kunden stehen und diesen bei der Pflege des Backlogs unterstützen. Allein dazu ist mindestens einmal pro Woche ein gemeinsames Meeting notwendig. Dazu kommt die Teilnahme an den Sprint-Meetings. Weiterhin basieren die Anforderungen zu einem großen Teil auf dem Dialog mit dem Kunden. Er sollte also gut für das Team erreichbar sein, um auch kurzfristig Entscheidungen treffen zu können.

Leider gibt die Praxis dies nicht immer her. Der Kunde stimmt seinen Urlaub nicht mit dem Entwicklungsteam ab, hat eventuell gar nicht die volle Verantwortung für das Produkt, und damit nicht die volle Entscheidungskompetenz, ist überraschend für einige Tage auf einem Seminar und für das Team nicht erreichbar und immer wieder müssen feste Termine wie Sprint-Meetings verschoben werden. Dies nimmt alle Agilität aus dem Prozess. Zusammen mit der passenden Vertragsgestaltung und Bereitschaft des Kunden ist dies sicherlich das größte Problem an dem agile Projekte scheitern.

Leider gibt es hier auch keine einfachen Best Practices, die das Problem umgehen. In meinen Projekten haben sich zwei Methoden am häufigsten bewährt. Zum einen muss gerade in den ersten Iterationen der Kunde zwanghaft in das Projekt integriert werden. Die Entwickler sollten noch stärker mit dem Kunden kommunizieren, am besten auch persönlich oder wenigstens telefonisch und nicht nur per Email. Der Projektleiter sollte ebenfalls im ständigen Kontakt mit dem Kunden stehen. Dadurch merkt er erst wie wichtig er in diesem Projekt ist. Natürlich wird zu Projektbeginn das Verfahren mit dem Kunden besprochen und er wird für das Thema sensibilisiert. Dennoch ist er völlig andere Projektformen gewohnt und wird den ständigen Kontakt vielleicht sogar als nervig empfinden. Zu der starken Einbindung gehört aber auch eine frühe Eskalation. Die Auswirkungen von Verfügbarkeits-Problemen oder mangelnder Entscheidungskompetenz sollten ihm sehr früh deutlich gemacht werden. Dabei helfen Tools wie ein Burn-Down-Chart zur direkten Visualisierung der Auswirkungen.

Diese Schocktherapie sollte aber auch belohnt werden. Primärer Fokus des Projektleiters muss am Anfang sein, den Kunden die positiven Seiten von Scrum spüren zu lassen. Dazu gehören vor allem schnelle, funktionsfähige Ergebnisse. Diese ist der Kunde für gewöhnlich erst nach etlichen Wochen gewohnt. Hat er die Vorteile erst einmal selber wahrgenommen wird er energischer in den Prozess eintauchen und den ständigen Kontakt zum Team zu schätzen wissen.

Die zweite Methode besteht darin wieder etwas Agilität aus der Anforderungsanalyse zu nehmen und wenigstens die Anforderungen für einen Sprint im Vorhinein mit allen Akzeptanzkriterien und Details zu definieren und schriftlich zu dokumentieren. Damit wird das Team etwas entlastet und Leerlaufzeiten reduziert. Die einzelnen Anforderungsworkshops für diese Analyse sind zwar länger, lassen sich aber besser auf Kundenseite planen als die ständige Verfügbarkeit. Weiterhin sollte hier sicher gestellt sein, dass die wirklichen Entscheider an dem Workshop teilnehmen und das aktualisierte Backlog im Anschluss kurz per E-Mail bestätigen.

Durch eine Mischung beider Methoden und einer längeren Kundenbeziehung wird dieses Problem auf Dauer gemildert und ein immer agileres Arbeiten wird möglich.

Priorisierung von Anforderungen 1/5

Das [glossary id=’1572′ slug=’product-backlog’ /] und der komplette Entwicklungsprozess basiert auf dem Prinzip, die wichtigsten und kritischsten Anforderungen zuerst umzusetzen. Damit wird zum einen das Ziel verfolgt möglichst schnell eine Software mit Mehrwert zu haben, die bereits von der Zielgruppe getestet werden kann oder eventuell schon nach wenigen Iterationen auf den Markt gebracht werden kann.

Da es verschiedene Möglichkeiten gibt Anforderungen zu priorisieren möchten wir die einzelnen Möglichkeiten gerne in separaten Artikeln beleuchten. Die Artikelserie wird so aussehen:

  • Einführung
  • Priorisierung nach Finanziellem Wert
  • Priorisierung nach Kosten
  • Priorisierung nach Risiken und Abhängigkeiten
  • MuSCoW Priorisierung

Einführung

Je schneller der Kunde Ergebnisse sieht, desto eher kann er Kurskorrekturen vornehmen und Feedback aus anderen Quellen berücksichtigen. In agilen Projekten ist meist das Budget fest vorgegeben und der tatsächliche Umfang des Projektes, der Scope, hängt von den ausgewählten Features des Backlogs ab, die tatsächlich umgesetzt werden. Oder anders ausgedrückt, werden einige Anforderungen gar nicht mehr umgesetzt, wenn das Budget, und die letzte Iteration zu Ende sind.

Aus diesem Grund wird das Backlog immer vollständig nach der Priorität sortiert. Somit ergibt sich eine geplante Umsetzungsreihenfolge und ein grobes Gefühl, anhand der Geschwindigkeit des Teams, welche Anforderungen im Budget umgesetzt werden können und welche eventuell nicht mehr in die Entwicklung gelangen.

Die Priorisierung der Anforderungen sollte sich dabei stets an dem erwarteten Geschäftswert der Anforderung orientieren. Doch was heißt in diesem Zusammenhang genau Geschäftswert und wie wird er berechnet? Hierzu werden verschiedene Parameter und Details einer Anforderung zur Berechnung herangezogen. Welchen Einfluß hat die Anforderung auf die Kundenzufriedenheit? Welche Auswirkung hätte das Fehlen der Funktionalität auf die Kundenzufriedenheit? Wie viel Geld bringt die Funktionalität beziehungsweise welche Kosten werden dadurch gespart? Welchen Aufwand verursacht sie in der Entwicklung? Ist sie selber ein Risiko oder adressiert sie die Beseitigung eines Risikos? Ergibt sich eine Priorität aus der Abhängigkeit zu einer anderen Anforderung?

Die Gegenüberstellung all dieser Faktoren und deren Beurteilung liegt in den Händen des Kunden. Er selber muss eine gesunde Einschätzung für die Reihenfolge der Anforderungen geben können. Unterstützt wird er dabei vom Team, das die risikoreiche oder mit Abhängigkeiten versehene Anforderungen frühzeitig identifiziert und deutlich kennzeichnet.

Projektmanagement als Kreativdisziplin

Ich bin kein großer Fan von Prozessen. Ich betrachte Projektmanagement als eine extrem kreative Arbeit. Kein Projekt gleicht dem anderen und kein Kunde reagiert und denkt wie der nächste. Immer wieder müssen für neue Situationen und Probleme pragmatische, kreative Lösungen gefunden werden. Lösungen, die Mitarbeiter- und Kundenzufriedenheit, Mehrwert und Qualität des Projekt-Ergebnisses, finanziellen Gewinn und die nachhaltige Verbesserung der Agentur-Abläufe berücksichtigen.

Das bedeutet natürlich nicht, dass ein solides Verständnis von Projektmanagement-Methoden unwichtig ist. Ganz im Gegenteil. Dadurch, dass Prozesse nur als Rahmenwerk gesehen werden und dynamisch auf Situationen reagiert wird, muss ein noch tiefer greifenderes Verständnis der einzelnen Tools und Methoden beim Projektleiter vorhanden sein. Er muss wissen, für welches Projekt welche Vorgehensweise Sinn ergibt und für welche Situation welches Tool zum Einsatz kommen muss.

Späte Detaillierung von Anforderungen ist auch Herausforderung fürs Team

Nicht nur für den Kunden ist die späte Konzeption der Details Neuland. Bei den ersten Scrum-Projekten des Teams ist auch hier ein Umdenken notwendig. Viele Programmierer scheuen es, ohne detaillierte Spezifikation zu starten und mit einer nicht komplett durchdachten Architektur als Grundlage zu beginnen. Auch in der Grafik wird meist ein vollständiger Katalog an Inhalten und Funktionen gefordert. Im Nachhinein eine weitere Navigationsebene hinzuzufügen oder eine weitere Spalte für Inhalte zu integrieren sei zu schwierig.

Die Praxis zeigt jedoch zwei wesentliche Bestätigungen für die Vorgehensweise von Scrum: Zum einen funktionieren einfache Lösungen die später komplexer werden im Regelfall sehr gut. Man muss sich daran gewöhnen und etwas Vertrauen darin haben, aber es funktioniert. Unterstützt wird dies durch viele Frameworks für Rapid Prototyping, also der frühen Entwicklung von Prototypen die dann sukzessive in das finale System umgebaut werden. Zum anderen verändern sich die Anforderungen sowieso, egal wie gut man zu Beginn geplant hat. Sehr oft sind die Designer anschließend traurig, dass sie mit einem perfekt konzipierten Design gestartet haben, und der Kunde es durch Änderungswünsche Stück für Stück verschlechtert. Wenn man diesen Umstand bewusst antizipiert und sich darauf einstellt, ist man hinterher auch wesentlich zufriedener mit dem Ergebnis.

Hoher Beratungsaufwand und unerfahrene Kunden in Webprojekten

Im Vergleich zur klassischen Softwareentwicklung bieten die aktuellen Trends und Entwicklungen im Internet eine schier undurchdringbare Menge an Möglichkeiten und Kommunikationskanälen. Dazu spielen der visuelle Anspruch und oft auch der reine Geschmack des Kunden eine wesentlich höhere Rolle. Kaum eine andere Branche innerhalb der IT-Welt muss derartig hohe Aufwände in der Kundenberatung leisten, um das Projekt zum erfolgreichen Ziel zu führen.

Sicher hat der Kunde oft bereits eine klare Vorstellung im Kopf und kann diese vielleicht sogar artikulieren. In Scrum, und auch in meinem Verständnis von Dienstleistung, geht es aber weniger darum die Lösung des Kunden umzusetzen, als mehr gemeinsam eine Lösung zu finden, die Ziele des Kunden zu erreichen.

Das erfordert ein enormes Know-How, welches über die Fachgebiete Projektmanagement oder Softwareentwicklung weit hinausgeht. Kann der Projektleiter diese Beratungsleistung nicht selber stemmen, muss er entsprechende Berater oder Team-Ressourcen in das Projekt mit einkalkulieren.

Die Schieflage: Einfache Methode um Probleme am Kanban Board zu visualisieren

In vielen Büchern wird bei Kanban gerne mit roten Stickern oder Blitzen gearbeitet, die auf eine Karte geklebt werden, sobald es ein Problem mit dieser Aufgabe gibt und diese den Fluss blockiert.
Das funktioniert auch hervorragend. Mein Team kam allerdings eigenständig (ihr könnt euch gar nicht vorstellen, wie sehr mich das mit Stolz erfüllt hat…) auf die Idee, die Karte ganz einfach um 45° zu drehen.

Da sonst alle Karten an der Wand sehr ordentlich und genau nebeneinander bzw. untereinander hingen, stach diese eine Karte sofort hinaus. Und durch die “Schieflage” der Karte war jedem sofort klar, in welchem Zustand sich die Aufgabe befindet. Dieser kleine Kniff ist auf jeden Fall sofort in meine Toolbox gewandert!

Navigate