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)