Nie ma magicznej liczby, która określa właściwy rozmiar Backlogu. Zatem, jak to ogarnąć?
Mike Cohn pisał, aby w Backlogu nie było więcej niż 100-150 elementów. Te liczby wydają się rozsądnym limitem – bo czy jesteśmy w stanie więcej ogarnąć? Jednak życie pokazuje, że produkty i projekty są bardzo zróżnicowane – nie można wrzucić ich do jednej kategorii „liczbowej”. Zatem, to co pisze Cohn, to tylko wskazówki.
Pewnym jest, że im więcej elementów w Backlogu, tym większe ryzyko, że utraci on swoją czytelność, a nawet możliwość sprawnego zarządzania. Ich liczba potrafi być tak duża, że nikt nie kojarzy co tam w ogóle jest 😁
Zdarzają się jednak i odwrotne sytuacje – Backlog jest niezwykle skromny. Może to doprowadzić do dwóch problemów:
- Zespół, w końcu, nie będzie miał nad czym pracować, lub
- to nad czym będzie pracował nie będzie miało najwyższej możliwej wartości (będą tam same zapychacze, nieaktualne historyjki o niskiej wartości).
Powyższe wpływa demotywująco na Zespół i generuje marnotrawstwo.
Jak widzisz, warto unikać dwóch skrajnych sytuacji: nadmiaru i niedoboru. Gdzie leży jednak ten „złoty środek”?
Wyobraźmy sobie, że Product Owner znika na 2 tygodnie i Deweloperzy chcą zaplanować Sprint. Czy będą mogli to zrobić, na podstawie tego jak zorganizowany jest Backlog i znajomości produktu? To jeden z sygnałów, że Backlog jest w ogóle użyteczny i jakoś ogarnięty. To pewne uproszczenie, ale myślę, że rozumiesz o co chodzi.
Dodatkowo, jest pewna „zasada”, którą lubię rekomendować: wypielęgnowane tyle historyjek, że starczy Zespołowi na zaplanowanie dwóch Sprintów. Nie wszędzie to pasuje, ale w wielu przypadkach tak. Backlog może mieć różny rozmiar, ale Zespół powinien znać najbliższą wizję, na której może się skupić. Im dalej w przyszłość, tym bardziej będzie ona rozmazana, co jest całkiem naturalne i nie powinniśmy się tego bać.
Oceń ten post
[yasr_visitor_votes size=”large”]
Do ilustracji posta użyłem zdjęć/grafik od: Rawpixel.