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

Leave A Reply

Navigate