Zarządzanie produktem · 3 min czytania
Ten o 10% na refinement
Refinement w Scrumie: skąd 10% pojemności zespołu w starym Scrum Guide, co mówią o tym fazy Takeuchiego i Nonaki i co robić, gdy 10% to za mało.
Czy pamiętasz jeszcze te 10% na refinement?
W starszych wersjach Scrum Guide’a widniał zapis: „Refinement zazwyczaj nie zajmuje więcej niż 10% pojemności zespołu deweloperskiego”. Liczba ta u różnych osób, z różną dbałością o literę prawa, była pilnowana niemal religijnie.
Skąd się wzięło 10%?
Dziś warto zadać sobie pytanie: czym właściwie było to 10%? Czy to magiczna, sprawdzona empirycznie liczba, czy może po prostu pragmatyczna próba zrealizowania w praktyce koncepcji overlapping phases?
Co mówią o tym Takeuchi i Nonaka?
Powrót do korzeni: „The New New Product Development Game”. U podstaw Scruma leży idea Takeuchiego i Nonaki, która odchodziła od sztafety na rzecz „gry zespołowej”. Fazy rozwoju produktu powinny na siebie nachodzić. Podczas gdy budujemy funkcjonalność A, musimy już kształtować fundamenty pod funkcjonalność B. Te mityczne 10% miało być gwarancją, że zespół nie zapomni o patrzeniu w przód, zajęty bieżącymi sprawami.
Co zrobić, gdy 10% to za mało?
Co robiłeś w sytuacji, gdy najważniejsza rzecz dla zespołu potrzebowała nowych informacji, a limit czasu na refinement właśnie się wyczerpał? Gdy „najważniejsze” nagle staje się „najbardziej niejasne”?
Oto dwa podejścia, które sprawdzają się w boju:
- Stop the line (Andon Cord). Jeśli najwyższy element backlogu jest zablokowany brakiem wiedzy, nie udajemy, że robimy coś innego, byle „dobić” sprint. Czasem jedynym wyjściem jest świadome poświęcenie części bieżącego sprintu na rzecz wyjaśnienia. Lepiej coś odciąć z dołu, niż porzucić to, co jest najważniejsze.
- Bezpośrednie „nurkowanie” z biznesem. Zamiast czekać na kolejną sesję refinementu, angażujemy interesariuszy w trybie ad hoc. Skracamy pętlę informacji do absolutnego minimum, traktując zdobywanie wiedzy jako integralną część pracy, a nie spotkanie w kalendarzu.
Te 10% to była pomocna wskazówka czy raczej coś, co nie pozwalało zająć się tym, co istotne?
Dlaczego na początku wystarczy jedno zdanie na pomysł, opisałem we wpisie o jednozdaniowcach.
Bibliografia
- Takeuchi, H., Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 64(1), 137–146. hbr.org
- Schwaber, K., Sutherland, J. (2017). The Scrum Guide. scrumguides.org
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem
Tomasz Żelezny
Scrum Master · Agile Coach
Pomagam zespołom robić mniej rzeczy naraz i kończyć więcej. Piszę o przepływie pracy, decyzjach i o tym, gdzie znika wysiłek zespołów.
Twój zespół może więcej niż dowozi.
Zobacz, jak pomagam