Nie ma czegoś takiego jak idealny rozmiar User Story. Jedne wymagania są mniejsze, inne większe. Ważne, aby zespoły, które mają je przekształcać w działające oprogramowanie czuły się z nimi dobrze. Są jednak pewne czynniki, które warunkują rozmiar Historyjki Użytkownika.
Pułapka ilości
User Story, czyli Historyjka Użytkownika to nic więcej niż dobra praktyka na sposób zapisu wymagań w naszym backlogu. W podlinkowanym tekście opisaliśmy już ich strukturę czy warunki, jakie powinny spełniać. Dla przypomnienia: US to nie tylko „jako… chcę… aby…”, ale także wysokopoziomowe kryteria akceptacji (HLAC).
Często też pytacie nas o idealny rozmiar User Story. Jak duże, bądź jak małe powinny być wymagania? Pytanie wydaje się być proste, odpowiedź jest instynktowna dla wszystkich pracujących w Scrum. Wymagania, a więc i US-y, muszą mieścić się w Sprincie. Oznacza to, że rozmiar User Story powinien pozwalać na ukończenie jej w iteracji o wybranej długości. Ale czy jedna historyjka na Sprint to dobry wybór?
Zarówno zdrowy rozsądek, jak i doświadczenie pokazuje, że nie. Posiadanie np. 6 elementów w Backlogu Sprintu powoduje, że przy braku możliwości ukończenia jednego z nich, mamy kilka innych, które mogą je „zastąpić”. W sytuacji, w której mamy tylko jedno wymaganie, skupienie się wyłącznie na nim powoduje, że wystąpienie najmniejszych problemów, opóźnień, konieczności doprecyzowania wymagania wpędza nas w niemałą pułapkę. Na potrzeby tego posta nazwijmy ją „Pułapką ilości”.
Rozmiar User Story
Zbadajmy warunki brzegowe – wiemy już, że jedno User Story na Sprint to za mało. Ale zaplanowanie 20 małych wymagań również nie jest dobrym pomysłem. Dojdziemy w ten sposób do sytuacji, w której realizując niektóre z nich dotykać będziemy tego samego obszaru. A to znaczy, że np. zamiast zrobić kilka zmian hurtem, będziemy każdą z nich opisywać, realizować i testować osobno. Doprowadzi to do inflacji punktowej, a to z kolei negatywnie wpłynie na nasz „budżet”.
Co w takiej sytuacji zrobić? Zdecydowanie warto łączyć ze sobą powiązane wymagania, gdy są za małe. Z drugiej strony, jeżeli są za duże – koniecznie je podzielmy! Jak więc określić ten najlepszy rozmiar?
W literaturze światowej mówi się, że idealna historyjka powinna mieć wielkość od 1/6 do 1/10 prędkości zespołu (velocity). Z powyższego otrzymujemy również inną, prostszą odpowiedź – nasz Backlog Sprintu powinien zawierać od 6 do 10 wymagań. I nawet jeśli nie jest to idealny przepis dla każdego zespołu, to na pewno jest to najlepszy punkt wyjścia. Z naszego #białkowego doświadczenia możemy powiedzieć, że sprawdza się to też w praktyce!
Mniejsze jest lepsze?
Co jeszcze przemawia za małymi wymaganiami? Wszystko. Jesteśmy je w stanie szybciej „przegadać” podczas Product Backlog Refinementu. Łatwiej jest je dostarczyć w postaci potencjalnie wdrażalnego przyrostu oprogramowania, bo po prostu zrealizujemy je szybciej. Małe rzeczy zawierają mniej niuansów i pułapek. Dzięki temu także będziemy mogli częściej badać reakcje naszych klientów czy rynku – szybko dostaniemy informację zwrotną. A czy nie o to właśnie chodzi w naszych staraniach o minimalizowaniu Time To Market?
Jestem przekonany, że sami mieliście okazję zaobserwować, że o wiele łatwiej jest dostarczyć małe wymaganie. Jeżeli już mamy z czymś problem, z czymś się nie wyrabiamy albo męczymy się bez końca, to na pewno nie będzie to najmniejsze User Story w danym Sprincie.
Wiąże to się z faktem, że duże wymaganie o wiele trudniej jest wyszacować i zaplanować. W końcu znajduje się w nim wiele niewiadomych i pytań, o których jeszcze nie wiemy, że powinniśmy je zadać. To trochę tak, jak z odległością, każdy z nas z większą lub mniejszą precyzją powie, ile to jest dziesięć metrów i jak długo zajmie nam ich pokonania. Czy z taką samą precyzją uda nam się określić, jak daleko od miejsca, w którym stoimy kończy się kilometr i ile czasu zajmie nam jego przejście?
Żeby tylko nie przesadzić
W pogoni za małym rozmiarem User Stories nie zapominajmy jednak o jednej, niezwykle ważnej sprawie. US powinien reprezentować sobą potrzebę biznesową naszego klienta, czyli inaczej mówiąc – powinien nieść za sobą jakąś wartość. Dzieląc duże kawałki naszego Backlogu Produktu na mniejsze części łatwo przesadzić. Zostajemy wtedy z wymaganiami, które co prawda przybliżają nas do celu, ale same w sobie nie są nic warte.
Pamiętajmy, że ta wspomniana potrzeba biznesowa jest ujęta w opisie historyki („Aby…”). Ten opis musi ulec zmianie podczas wydzielania mniejszych wymagań z naszego Epica.
Jak we wszystkim tak i w tym procesie potrzebny jest umiar. Czynności dzielenia wymagań na te o właściwej wielkości da się nauczyć. Potrzebny jest tylko dobry schemat dzielenia i… praktyka. Na nią na szczęście mamy dużo czasu, bo wymaganie możemy podzielić w każdym momencie! Nie ma znaczenia, czy wymaganie jeszcze znajduje się w Backlogu Produktu, czy właśnie jest planowane przez zespół na bieżący Sprint. Nie bójmy się dzielić!
Jeśli potrzebujesz pomocy w temacie dzielenia User Story, zapraszamy do skorzystania z naszych usług. W dziale szkolenia znajdziesz wszystkie informacje potrzebne do zapisania się na warsztat Wymagania w projektach agile, na którym dużo czasu poświęcamy właśnie na osiąganie idealnego rozmiaru User Story.
"W literaturze światowej mówi się, że idealna historyjka powinna mieć wielkość od 1/6 do 1/10 prędkości zespołu" – o jakiej literaturze wspominasz Łukasz?