W poprzednim tekście poruszyłem wątek najpopularniejszego formatu opisywania pomysłów, a mianowicie User Stories (historyjki użytkownika). Teraz czas na alternatywy.

Niby podobne, niby historyjki, ale… 🙂

Job Story

Przykładowe Job Story:

Gdy mój komentarz zostanie zaakceptowany przez moderatora, chcę dostać powiadomienie e-mail, aby śledzić ten wątek.

Proste? No pewnie!

Mamy tu 3 składowe.

Gdy <warunek/bodziec>, chcę <aby coś się wykonało>, aby <motywacja/dlaczego>.

Podobne do User Stories, ale:

• bez persony (użytkownika)
• za to z określeniem warunku (w jakiej sytuacji coś się wydarzy), więc dookreślamy kontekst co bywa bardzo istotne.

Całkiem sensownie działa też zapis w formie kolejnych wierszy, np.

Gdy mój komentarz zostanie zaakceptowany przez moderatora
chcę dostać powiadomienie email,
aby śledzić ten wątek.

Taki układ wizualny w jakiś sposób wydaje mi się jeszcze bardziej interesujący – wizualnie jest krótki, konkretny i czytelny.

To co lubię w Job Stories to fakt, że w jednym zdaniu zawierają to co najważniejsze (why), ale także dookreślają kontekst (co nie jest tak łatwe w przypadku User Stories).

Pomijamy “dla kogo” (persona, stosowana w User Stories). Czy to źle? Nie każdy zespół stosuje persony. A inne zespoły nawet nie muszę o nich pisać wprost, bo wszyscy je tak dobrze znają, że pisanie za każdym razem “jako <typ użytkownika>” to prowadzi do jakiegoś znużenia (?) formatem. Co o tym sądzisz? Podziel się komentarzem pod tym wpisem!

Problem Story

Kolejne podejście to moje ulubione podejście. Ulubione ze względu na prostotę i super możliwości użycia w ramach Backlog Refinementu.

Przykładowo:

W celu szybszego ładowania strony będziemy kompresowali obrazki.

Czy to nie pięknie proste?

W celu <jakiś problem do rozwiązania> zbudujemy/zrobimy <rozwiązanie>.

Zawiera to co najważniejsze, czyli dlaczego. A w dodatku informuje o pomyśle jak to rozwiązać. Wszystko krótko i zwięźle.

Jednak magia zaczyna się wtedy, gdy autor pomysłu przychodzi tylko z pierwszą częścią do zespołu, a drugą dopisują wspólnie w ramach Backlog Refinementu. Np. Product Manager przynosi do zespołu problem i w Backlogu wpisuje:

W celu szybszego ładowania strony…

i z całym zespołem dyskutujemy co można w tym celu zrobić. A po dyskusji dopisujemy:

… będziemy kompresowali obrazki.

Czy można na takie rozwiązanie wpaść bez zespołu? Pewnie! Jednak lepiej zostawiać to do wspólnej dyskusji, albowiem wówczas możemy znaleźć inne sposoby na problem + uczymy zespół, że też może zgłaszać swoje sugestie.

Problem Story można wynosić na różne poziomy “zagłębienia” tematu. Co mam na myśli:

W celu zwiększenia konwersji na stronie ABC przyspieszymy jej ładowanie.

W celu szybszego ładowania strony będziemy kompresowali obrazki.

Bardzo łatwa metoda do “wyuczenia” :) Spróbujesz?