.st0{fill:#FFFFFF;}

Rozmiar User Story 

 20 sierpnia, 2019

Łukasz Bręk

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.

Łukasz Bręk


15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum.
Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}