INWESTuj w historyjki

W telegraficznym skrócie technika podziału user stories opiera się na sześciu zasadach zawartych w poniższej tabelce.

Litera Znaczenie Opis
I Independent Każda historyjka powinna być niezależna. Chodzi o zminimalizowanie ryzyka powstania zależności, które spowodują zablokowanie jednej historyjki przez drugą.
N Negotiable Historyjki, dopóki nie są częścią sprintu mogą być zmieniane, przepisywane, modyfikowane.
V Valuable Historyjka musi dostarczać wartość biznesową.
E Estimable Zespół zawsze musi być w stanie oszacować wielkość (w Story Pointach) historyjki.
S Small Jeśli nie jest możliwe oszacowanie/zaplanowanie/ustalenie priorytetu z określonym poziomem pewności dla historyjki, oznacza to, że jest ona za duża.
T Testable Historyjka oraz jej opis (np. Kryteria akceptacji) muszą dostarczać niezbędnych informacji w celu zaimplementowania/przeprowadzenia testów w trakcie prac deweloperskich.

Independent – niezależne

Łatwiej pracować z historyjkami (właściwe z każdym zadaniem), kiedy nie jest ona zależna od innej historyjki. Product Owner ma wtedy większą swobodę w ustalaniu priorytetów, dzięki czemu może maksymalizować dostarczaną przez zespół wartość biznesową.

Oczywiście rzeczywistość jest różna  W naszym zespole już nie raz małą miejsce sytuacja, że jedno zadanie miało wycenę 5SP a następne, bardzo podobne, już 2-3SP. W pierwszym zadaniu została wypracowana architektura rozwiązania oraz szablon testów automatycznych, dzięki czemu każda następna historyjka może mieć już niższą wycenę.

Negotiable – negocjowalne

Dobra historyjka to taka, która jest negocjowalna. Mówiąc inaczej, historyjka to nie zakontraktowana funkcjonalność. Jak napisał Mike Cohn w User Stories Applied. Historyjka jest zaproszeniem do dyskusji, oddaje istotę problemu, cel biznesowy a nie niskopoziomowe szczegóły implementacji danej funkcjonalności.

Valuable – wartościowe

Historyjka musi dostarczać wartość biznesową. Jest to szczególnie ważne w przypadku próby podziału historyjki na mniejsze elementy. Pamiętajmy, że dodanie tabelki do bazy danych i oprogramowanie dla niej funkcji CRUD nie ma żadnej wartości dla klienta! Klient nie będzie mógł korzystać z produktu mając oprogramowaną warstwę dostępu do danych. Dlatego często spotykanym w literaturze/szkoleniach/itd przykładem jest tort składającego się z wielu warstw. Zamiast dostarczać klientowi warstwę po warstwie, starajmy się zaoferować kawałek (choćby niewielki) ale zawierający wszystkie warstwy.

Estimable – możliwe do oszacowania

Szacowanie, z natury, nie musi być (i nie jest) super precyzyjne. Wchodząc na podwórko Scruma, mówimy, że mylimy się szybko i tanio. Historyjka musi zawierać wycenę. Wycena ta, chodź niedokładna, pozwala Produkt Ownerowi ustalić odpowiednio priorytety i wybrać te historyjki, które dostarczą największą wartość biznesową w kontekście wyceny wykonanej przez zespół wykonawczy.

Small – małe

Historyjki powinny być na tyle małe aby miały szansę zmieścić się w jednej iteracji. Ponadto mniejsze historyjki można dokładniej/precyzyjniej oszacować. Przykładowo formularz do wprowadzania i edytowania danych pracownika łatwiej oszacować w porównaniu do całego modułu zarządzania pracownikami.

Testable – testowalne

Dobra historyjka, to taka, do której można napisać testy automatyczne. Oznacz to, że historyjka zawiera szczegóły, które są wskazówką dla zespół wykonawczego, w jaki sposób wykonać swoją pracę. Najlepiej, kiedy takie szczegóły, w postaci kryteriów akceptacji, luźnych uwag zapisanych w trakcie dyskusji, itp, pojawiają się zanim zespół wykonawczy przystąpi do implementacji rozwiązania. Pozawala to spojrzeć na całość zagadnienia, wraz z jego ograniczeniami.

“Testowalność” – świadomość tego, jak sprawdzić poprawność danej funkcjonalności, zawsze była cechą charakterystyczną dobrych wymagań biznesowych.

 

Źródła: