Scrum als Framework gibt ein paar wenige Dinge sehr explizit vor und lässt einige mehr bewusst unbeantwortet. Gerade hier (aber auch schon mit den Regeln) tun sich viele Teams schwer. Doch woran erkennt man nun, wenn etwas nicht läuft, wie es könnte? Wir stellen Smells vor, um ein paar typische Probleme zu identifizieren, erklären ihre Ursachen und stellen Konzepte vor, was man dagegen machen kann.

1. 1
Sebastian Bauer
inovex GmbH
Dominik Ehrenberg
crosscan GmbH

2. Sebastian Bauer
inovex GmbH
Dominik Ehrenberg
crosscan GmbH

3. Technische Schulden / Bugs
Smells:
Technische Nachholarbeiten im
Backlog
Lange Bugtracker-Listen und/oder
Bug-Fixing-Days
Unfertige Stories

4. Technische Schulden / Bugs
Smells:
Technische Nachholarbeiten im
Backlog
Lange Bugtracker-Listen und/oder
Bug-Fixing-Days
Unfertige Stories
Ursachen:
Technische Verantwortung liegt nicht
beim Dev-Team
Schlechte oder fehlende Tests
Sustainable Pace vs. “Output!Output! Output!”
Zu große Stories

5. Concepts-to-Go:
Statische Codeanalyse
“Refactor as you go”
Bugs pro Sprint einplanen (falls
Abbaubedarf besteht)
Maximale Größe für Stories im Sprint
festlegen
Zero Bug Policy
Technische Schulden / Bugs

6. Zu große Stories
Smells:
Stories ziehen sich über mehrere
Sprints
Backend-, Frontend-, Konzept-,
Feature- und Test-Stories
Kein Business Value sichtbar

7. Zu große Stories
Smells:
Stories ziehen sich über mehrere
Sprints
Backend-, Frontend-, Konzept-,
Feature- und Test-Stories
Kein Business Value sichtbar
Ursachen:
Stories werden erst im Planninggeschätzt
Kein Refinement
Unkontrollierbare Abhängigkeitenin den Stories

8. Zu große Stories
Concepts-to-Go:
Stories mit Business Value versehen
Maximale Größe für Stories im
Sprint festlegen ➟ Stories aufteilen
Hierarchisch visualisieren

10. Hempels Product Backlog

11. Hempels Product Backlog
Smells:
Das „Kühlschrank Backlog“
Stories werden im Planning
erstmals besprochen
Scope von Stories ändert sich
während des Sprint

12. Hempels Product Backlog
Smells:
Das „Kühlschrank Backlog“
Stories werden im Planning
erstmals besprochen
Scope von Stories ändert sich
während des Sprint
Ursachen:
“Damit wir es nicht vergessen”“Wir brauchen ein vollständiges,
geschätztes Backlog”
Keine Hierarchien (z.B. Epics) im
Backlog

13. Hempels Product Backlog
Concepts-to-Go:
Connextra Template ➟ „As a …“
Ablaufdatum für Stories / Product
Backlog Chaos Monkey
Product Backlog Eisberg

14. Hempels Product Backlog

15. Hempels Product Backlog
Concepts-to-Go:
Connextra Template ➟ „As a …“
Ablaufdatum für Stories / Product
Backlog Chaos Monkey
Product Backlog Eisberg
Priorisierung mittels Kano / WSJF

16. Hempels Product Backlog
Weighted Shortest Job First:
WSJF =
User Business Value + Time Criticality + Risk Reduction
and/or Opportunity Enablement
Job Duration

17. APOkalypse
Smells:
Mehr als ein PO pro Team
Sprints ohne Fokus oder zu vielen
unterschiedlichen Themen
Jede Story ist “Prio 1”

18. APOkalypse
Smells:
Mehr als ein PO pro Team
Sprints ohne Fokus oder zu vielen
unterschiedlichen Themen
Jede Story ist “Prio 1”
Ursachen:
Angst vor Kompetenzverlust
Politik

19. APOkalypse
Concepts-to-Go:
Name Game mit Stakeholdern
Priorisierungsproblematik in
Workshop transparent machen
Stakeholder Map erstellen
Gemeinsam auf einen PO
committen

20. Product Owner. vs. Team
Smells:
PO hinterfragt Commitment und
Schätzungen
PO darf nicht in Retrospektive
Satz im Review: „Hat PO so nicht
spezifiziert!“

21. Product Owner. vs. Team
Smells:
PO hinterfragt Commitment und
Schätzungen
PO darf nicht in Retrospektive
Satz im Review: „Hat PO so nicht
spezifiziert!“
Ursachen:
Team fühlt sich wenig für Produkt
verantwortlich
Scrum Master
Falsches Verständnis vom Zweck der
Abnahme im Review

22. Product Owner. vs. Team
Concepts-to-Go:
Velocity gehört dem Scrum Team
Retro für Storyanalysen nutzen
Review zusammen mit PO
vorbereiten
Refinement einführen

23. Let’s Go Kanban!
Smells:
Häufige Diskussionen über „Scrum
Overhead“
„Arsch auf Glatteis“-Situationen

24. Let’s Go Kanban!
Smells:
Häufige Diskussionen über „Scrum
Overhead“
„Arsch auf Glatteis“-Situationen
Ursachen:
Glaube, in Kanban flexibler zu seinBegrenztes Budget, kein flexibler
Scope
Keine „echten“ Produktinkremente
am Sprintende

25. Let’s Go Kanban!
Concepts-to-Go:
Scope mit Hilfe v. hierarchischen
Backlogs flexibler gestalten.
Lernen, „nein“ zu sagen
Regelmäßige Releases zum
Sprintende einführen (+ CI / CD)
Durchsatz messen und verwenden

26. meinscrumistkaputt.de
@scrumkaputt
/scrumkaputt