INVEST - czyli metoda jak stworzy膰 dobre User Story

INVEST jest metod膮 tworzenia dobrych User Stories. Pozwala sprawdzi膰, czy maj膮 odpowiednio sformu艂owan膮 tre艣膰, czy odnosz膮 si臋 do warto艣ci biznesowej Produktu. A tak偶e, czy ich wielko艣膰 i u偶yteczno艣膰 zosta艂y odpowiednio dobrane.

INVEST – om贸wione zagadnienia:

Wprowadzenie
N jak Niezale偶na
N jak Negocjowalna
W jak 奥补谤迟辞艣肠颈辞飞补 lub Werykalna
S jak Szacowalna
M jak Ma艂a
T jak Testowalna
Podsumowanie

INVEST – wprowadzenie

INVEST to akronim stworzony przez Billa Wake w 2003 roku. Ka偶da jego litera oznacza pocz膮tek s艂owa, kt贸re charakteryzuje dobr膮 User Story. Wed艂ug zasady INVEST ka偶da User Story powinna by膰:

Niezale偶na (Independent)
Negocjowalna (Negotiable)
奥补谤迟辞艣肠颈辞飞补 (Valuable)
Szacowalna (Estimable)
Ma艂a (Small)
Testowalna (Testable)

Wi臋cej na temat tego, czym jest User Story pisali艣my w osobnym artykule. Tutaj wspomnimy tylko, 偶e jest ona zwi臋z艂ym opisem nowej funkcjonalno艣ci Produktu napisanym w przyst臋pnym j臋zyku.

Creating the best User Story with INVEST

N jak Niezale偶na

Pierwsz膮 cech膮 dobrej User Story jest jej 苍颈别锄补濒别偶苍辞艣膰. Oznacza to, 偶e jej opis i charakterystyka powinny by膰 zrozumia艂e bez odniesienia do innych User Stories. Ale przede wszystkim to, 偶e jej realizacja nie powinna by膰 bezpo艣rednio uzale偶niona od realizacji innych User Stories. Nie b臋dzie to oczywi艣cie pe艂na 苍颈别锄补濒别偶苍辞艣膰. Tworzenia Produktu nie da si臋 bowiem podzieli膰 na zupe艂nie odr臋bne modu艂y. Jednak wa偶ne by pami臋ta膰 o zachowaniu mo偶liwie du偶ej samodzielno艣ci User Stories. Dzi臋ki temu nawet, gdy jedna z nich nie wejdzie do fazy realizacji, albo zostanie znacz膮co zmodyfikowana, pozosta艂e User Stories nie b臋d膮 musia艂y by膰 modyfikowane. Co do zasady, User Story powinna wi臋c stanowi膰 odr臋bn膮 i logiczn膮 ca艂o艣膰.

N jak Negocjowalna

User Story powinna by膰 negocjowalna. Oznacza to, 偶e wyznacza ona Cel, a nie spos贸b doj艣cia do niego.

Innymi s艂owy, okre艣la oczekiwan膮 cech臋 Produktu, a nie techniczne rozwi膮zanie, kt贸re powinno zosta膰 wdro偶one.

Negocjowanie User Story ma miejsce pomi臋dzy Product Ownerem a Zespo艂em Developerskim. Product Owner proponuje realizacj臋 pewnej funkcjonalno艣ci Produktu, czyli m贸wi „Co” zostanie zrobione. Natomiast do Developer贸w nale偶y odpowied藕 na pytanie „Jak”. Czyli wynegocjowanie konkretnych sposob贸w rozwi膮zania problemu postawionego w User Story.

W jak 奥补谤迟辞艣肠颈辞飞补 lub Wertykalna

W skr贸towcu INVEST litera V jest odczytywana dwa sposoby, jako:

奥补谤迟辞艣肠颈辞飞补 (Valuable)
Wertykalna (Vertical)

Oba rozwini臋cia daj膮 istotn膮 charakterystyk臋 dobrej User Story. Dlatego zdecydowali艣my wyja艣ni膰, co oznacza ka偶de z nich.

奥补谤迟辞艣肠颈辞飞补

奥补谤迟辞艣肠颈辞飞补 User Story to taka, kt贸ra jasno uzasadnia biznesowy sens wprowadzanej modyfikacji. Innymi s艂owy, trafnie odpowiada na pytanie Po co? dana modyfikacja powinna zosta膰 wprowadzona. I dlaczego jest to wa偶ne z punktu widzenia Interesariuszy.

Wertykalna

Rozwini臋cie litery V jako Wertykalna zosta艂o zaczerpni臋te z metodyki Agile. Wertykalna User Story zawiera now膮 cech臋 Produktu widoczn膮 dla U偶ytkownika. Czyli nie koncentruje si臋 na horyzontalnej „poprawie funkcjonowania” w wybranej warstwie Produktu. Przeciwnie, dobudowuje do niego kolejne „pi臋tro”.

Innymi s艂owy, User Story opisuje, w jaki spos贸b zmodyfikowa膰 ca艂o艣膰 dzia艂ania Produktu odpowiadaj膮c na pytanie Co konkretnie zostanie ulepszone? Oznacza to r贸wnie偶, 偶e ka偶da funkcjonalno艣膰 Produktu nabudowuje si臋 na ju偶 istniej膮cych rozwi膮zaniach.

S jak Szacowalna

Dobra User Story powinna by膰 szacowalna. Oznacza to, 偶e musi jasno okre艣la膰 zakres modyfikacji, kt贸re trzeba wprowadzi膰 w produkcie, aby User Story zosta艂a uznana za zrealizowan膮. Dzi臋ki temu Zesp贸艂 Developerski jest w stanie okre艣li膰 czas i nak艂ady pracy konieczne do jej wykonania.

Zakres i trudno艣膰 zadania s膮 najcz臋艣ciej szacowane w jednostkach nazywanych Story Points. S膮 one relatywne. A ka偶dy Zesp贸艂 Developerski wypracowuje w praktyce warto艣膰 Story Point bazuj膮c na wcze艣niejszych 诲辞艣飞颈补诲肠锄别苍颈补ch.

W osobnych artyku艂ach opisali艣my wi臋cej na temat Pr臋dko艣ci Zespo艂u Developerskiego i sposobach jej mierzenia.

M jak Ma艂a

User Story przyj臋ta do realizacji przez Zesp贸艂 Developerski powinna by膰 kr贸tka. Czyli czas jej planowanej realizacji powinien by膰 nie d艂u偶szy ni偶 czas trwania jednego Sprintu. Je艣li Developerzy podczas Planowania Sprintu odkryj膮, 偶e User Story zaproponowana przez Product Ownera jest zbyt d艂uga, powinni podzieli膰 j膮 na mo偶liwie niezale偶ne od siebie cz臋艣ci.

T jak Testowalna

Pod ostatni膮 liter膮 akronimu INVEST kryje si臋 s艂owo testowalna. Oznacza ono, 偶e modyfikacja Produktu opisana w User Story musi by膰 konkretna i mo偶liwa do sprawdzenia. Innymi s艂owy, powinna istnie膰 mo偶liwo艣膰 weryfikacji, czy rozwi膮zanie zaimplementowane przez Developer贸w dostarczy艂o zak艂adan膮 warto艣膰 okre艣lonemu Interesariuszowi.

Podsumowanie

INVEST to akronim opisuj膮cy dobrze napisan膮 User Story. Powinna ona by膰:

Niezale偶na od innych User Stories. Po to, by mog艂a by膰 modyfikowana lub usuni臋ta z Backlogu Produktu, je艣li zaistnieje taka potrzeba.
Negocjowalna. Powinna okre艣la膰 co zostanie zrobione, pozostawiaj膮c wyb贸r sposobu Developerom.
奥补谤迟辞艣肠颈辞飞补, czyli uzasadniaj膮ca biznesowy sens modyfikacji Produktu. Lub te偶 Werykalna, czyli prezentuj膮ca now膮 cech臋 Produktu widoczn膮 dla U偶ytkownika.
Szacowalna, czyli posiadaj膮ca daj膮c膮 si臋 okre艣li膰 wielko艣膰 i kryterium uko艅czenia.
Ma艂a na tyle, aby mog艂a zosta膰 uko艅czona w jednym Sprincie.
Testowalna tak, aby mo偶na by艂o okre艣li膰 z ca艂膮 pewno艣ci膮, 偶e zosta艂a zrealizowana.

Sprawd藕 r贸wnie偶 – Najcz臋stsze b艂臋dy pope艂niane przy pisaniu User Story

Je艣li podobaj膮 Ci si臋 tre艣ci, kt贸re tworzymy, sprawd藕 r贸wnie偶:

Autor: Karolina Berecka
Karolina, jako project menad偶erka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przep艂ywu pracy i optymalizacji proces贸w. Jej umiej臋tno艣ci organizacyjne i zdolno艣膰 do pracy pod presj膮 czasu sprawiaj膮, 偶e jest najlepsz膮 osob膮 do zamieniania skomplikowanych projekt贸w w rzeczywisto艣膰.

Zobacz wszystkie posty

凯发k8旗舰厅

Przerwa konserwacyjna

Scrum Guide | 20. INVEST, czyli jak stworzy膰 dobre User Story