Nie potrzebujesz skomplikowanej hierarchii dla User Stories
Konsultanci i dostawcy narzędzi zdają się mieć skłonność do komplikowania wszystkiego. Wydaje się, że im bardziej komplikujemy sprawy, tym bardziej klienci nas potrzebują. I dzięki temu narzędzia i usługi się sprzedają, jak sądzę.
Z drugiej strony uważam, że zbędna złożoność może być niezwykle frustrująca. To samo dzieje się, gdy wprowadza się takie skomplikowane hierarchie lub taksonomie dla User Stories!
Ostatnio widziałem zespół, który przy planowaniu i szacowaniu stosował następującą kolejność:
- Feature
- Saga
- Epic
- Novel
- Story
- Task
Ani Product Owner, ani Scrum Master, ani zespół deweloperski tego nie potrzebują. Gdy zespoły Scrum są zmuszone do używania skomplikowanych taksonomii dla swoich User Stories, spędzają czas na zastanawianiu się, czy dana Story to Epic, Saga czy zwykły nagłówek. Te rozważania są jak drugoplanowe postacie w książce, które niepotrzebnie komplikują fabułę.
Wiem, co teraz chcecie powiedzieć. Tak, ja też wielokrotnie pisałem o Epicach i Temach. Ale to tylko etykiety. Story jest i pozostaje Story, dlatego polecam tę taksonomię dla User Stories:
Story jest Story jest Story.
Niektóre User Stories są duże i mogą być oznaczone etykietą „Epic". Wcześniej używałem filmów jako porównania. Wszystkie filmy są filmami, ale niektóre są romantycznymi komediami — to etykieta, tak jak „Epic".
Również „Theme" odnosi się do grupy powiązanych User Stories, ale nie musi mieć nic wspólnego z hierarchią. W porównaniu z filmami byłoby to na przykład zgrupowanie filmów o szpiegach, zawierające filmy o Jamesie Bondzie i filmy Austin Powers. Gdyby chodziło o grupę komedii, filmy Austin Powers nadal by należały, ale filmy z Jamesem Bondem już nie.
„Theme" i „Epic" to więc tylko etykiety i nie mają nic wspólnego z hierarchiami. Nie komplikujcie rzeczy bardziej niż to konieczne. Do tej pory nie znalazłem dobrego powodu dla rozbudowanych hierarchii lub taksonomii User Stories.
Tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony.
