Scrum und Requirements

Scrum ist im Großen und Ganzen recht einfach gestrickt. Dies betrifft auch das Backlog bzw. generell die Abhandlung von Requirements, also Anforderungen. Vorschriften werden hier keine gemacht. Ein Backlog ist eine Sammlung aus Anforderungen, wie diese beschrieben werden, bleibt der gesamten Scrum-Mannschaft überlassen.

Im Grunde müssen Anforderungen verständlich sein und nachvollzogen werden können. Nur so ist es möglich, zu einer sinnvollen Umsetzung zu kommen. Dabei ist es unerheblich ob die Anforderung als User Story, als Use Case oder anderweitig erfasst wurde.

Fehler beim Beschreiben der Anforderungen

In manchen Fällen legt man sich fix auf eine Methode, Anforderungen zu beschreiben, fest. Dies führt in der Regel dazu, dass eine Unterscheidung der Anforderungen vorgenommen werden muss, beispielsweise auf Basis der Herkunft oder des Inhaltes. Dies geschieht, da die Form/Vorschriften der verwendeten Methode nicht eingehalten werden können.

Technische Notwendigkeiten, Änderungen/Erweiterungen an der Basis der Anwendung bringen dem Benutzer nicht unmittelbar einen Vorteil (siehe Value in Bezug auf User Stories), ist aber für weitere Implementierungen etc. natürlich oftmal notwendig. Um dies nun nicht (fälschlicherweise) in eine User Story quetschen zu müssen entsteht schnell eine “Gegenveranstaltung” zum Backlog. Quasi die technische Variante davon.

Dies trübt nicht nur die Übersichtlichkeit, sondern bringt auch weitere Nachteile mit sich:

  • Dem Product Owner ist das gesamte Ausmaß nicht bewusst
  • Keine ordentliche Priorisierung möglich
  • Keine Release Forecasts
  • Generell sind Auswirkungen nicht erkennbar

Weitere Nachteile stehen Gewehr bei Fuss.

Wie Anforderungen erfassen

Für die Mehrzahl der Anforderungen ist relativ schnell klar, welche Methode sich als sinnvoll erweist. Für Anforderungen, die mit der gewählten Methode nicht sinnvoll beschreibbar sind, ist eine passende Möglichkeit zu wählen. Eine, mit deren Hilfe die Anforderung für alle Beteiligten (und vielleicht später dazustoßenden Personen) verständlich erfasst werden kann, ohne eine Methode missbrauchen zu müssen.

Unterschiedliche Orte der Erfassung sollten ebenfalls vermieden werden um ein gesamtheitliches Chaos zu vermeiden. Es bedarf ein wenig Flexibilität an dieser Stelle, um einen Wildwuchs im Anforderungsmanagement zu verhindern.

Der Nachteil der Heterogenität der Anforderungen macht sich positiv bemerkbar:

  • Übersichtlichkeit
  • Product Owner ist involviert
  • Weniger Diskussionen wann diese “außern vor”-Punkte untergebracht werden
  • Mögliche Planung + Forecasts
  • Korrektere Zahlen
  • usw.

Wie überall muss man auch hier abwägen ob ein Beharren auf Regeln immer sinnvoll ist, siehe auch

Individuals and interactions over processes and tools

(Manifesto for Agile Software Development)

Veröffentlicht von Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
Cookies anzeigen