Temat: User story dla strony z brakiem wyników wyszukiwania

Cześć, zastanawiam się jak skonstruować dobre user story dla strony dla braku wyników wyszukiwania.
Co sądzicie o tym: „Jako klient, chcę po wpisaniu frazy do wyszukiwarki otrzymać wynik, tak aby nie trafić na <ślepy zaułek>”.

Temat: User story dla strony z brakiem wyników wyszukiwania

Nie bardzo wiem, gdzie i co ma prezentować wyszukiwarka, a uzasadnienie biznesowe jest dla mnie nieczytelne. Generalnie w samym user story wpisałbym czego dotyczy dana wyszukiwarka lub jaki chcę mieć wynik wyszukiwania, a kwestię obsłużenia braku wyniku (prezentacja) wpisałbym w kryteriach akceptacyjnych.

Przykładowo:

"Jako KLIENT, chcę mieć wyszukiwarkę produktów, tak aby móc odnaleźć interesujący produkt, który będę mógł zakupić."

Kryteria:
*Wyszukiwarka
- wybór kategorii
- filtrowanie po zakresie cenowym
- etc.

*Wyniki:
- widoczne zdjęcia produktów
- możliwość sortowania
- sortowanie domyślne - według popularności, malejąco
- brak wyników wyszukiwania - dedykowana strona/komunikat
- etc.

Nie powinno się rozbijać każdego warunku dla funkcjonalności na osobną historyjkę. Z założenia każda historyjka reprezentuje oddzielne funkcjonalności w ogóle lub luźno ze sobą powiązane, tak aby można było nimi swobodnie sterować w backlogu.

Temat: User story dla strony z brakiem wyników wyszukiwania

Michał Kotarba:
Nie bardzo wiem, gdzie i co ma prezentować wyszukiwarka, a uzasadnienie biznesowe jest dla mnie nieczytelne. Generalnie w samym user story wpisałbym czego dotyczy dana wyszukiwarka lub jaki chcę mieć wynik wyszukiwania, a kwestię obsłużenia braku wyniku (prezentacja) wpisałbym w kryteriach akceptacyjnych.

Przykładowo:

"Jako KLIENT, chcę mieć wyszukiwarkę produktów, tak aby móc odnaleźć interesujący produkt, który będę mógł zakupić."

Kryteria:
*Wyszukiwarka
- wybór kategorii
- filtrowanie po zakresie cenowym
- etc.

*Wyniki:
- widoczne zdjęcia produktów
- możliwość sortowania
- sortowanie domyślne - według popularności, malejąco
- brak wyników wyszukiwania - dedykowana strona/komunikat
- etc.

Nie powinno się rozbijać każdego warunku dla funkcjonalności na osobną historyjkę. Z założenia każda historyjka reprezentuje oddzielne funkcjonalności w ogóle lub luźno ze sobą powiązane, tak aby można było nimi swobodnie sterować w backlogu.

Zgodze sie, ze user stories powinny byc niezalezne, wertykalnie zdefiniowane i reprezentowac jakis end-to-end flow. Jednak czasami nawet najlepiej zdefiniowana historia, spelniajaca INVEST i majaca swietne kryteria akceptacji bedzie po prostu za duza na jeden sprint (na przyklad: zespol wyestymuje ja na 8 punktow, a jego velocity to 5, stad taki commitment bedzie ryzykowny). Wtedy dalsze rozbicie 'pierwotnej' historii wedlug poszczegolnych kryteriow akceptacji moze okazac sie byc wyjsciem z sytuacji. W opisywanym przykladzie mniejsza historia zdefiniowana tak:

jako klient
chce miec mozliwosc sortowania wynikow wyszukiwania rosnaco
tak, abym mogl bardzo szybko znalezc produkt o najnizszej cenie

moglaby byc dobrym kandydatem wciaz przynoszacym wartosc biznesowa i nieco mniejszym, realnym do dostarczenia po jednym sprincie.

Temat: User story dla strony z brakiem wyników wyszukiwania

Maciej Kurek:

Michał Kotarba:
Nie powinno się rozbijać każdego warunku dla funkcjonalności na osobną historyjkę. Z założenia każda historyjka reprezentuje oddzielne funkcjonalności w ogóle lub luźno ze sobą powiązane, tak aby można było nimi swobodnie sterować w backlogu.

Zgodze sie, ze user stories powinny byc niezalezne, wertykalnie zdefiniowane i reprezentowac jakis end-to-end flow. Jednak czasami nawet najlepiej zdefiniowana historia, spelniajaca INVEST i majaca swietne kryteria akceptacji bedzie po prostu za duza na jeden sprint (na przyklad: zespol wyestymuje ja na 8 punktow, a jego velocity to 5, stad taki commitment bedzie ryzykowny). Wtedy dalsze rozbicie 'pierwotnej' historii wedlug poszczegolnych kryteriow akceptacji moze okazac sie byc wyjsciem z sytuacji. W opisywanym przykladzie mniejsza historia zdefiniowana tak:

jako klient
chce miec mozliwosc sortowania wynikow wyszukiwania rosnaco
tak, abym mogl bardzo szybko znalezc produkt o najnizszej cenie

moglaby byc dobrym kandydatem wciaz przynoszacym wartosc biznesowa i nieco mniejszym, realnym do dostarczenia po jednym sprincie.

True, ale wydaje mi się, że przykład akurat dotyczył konkretnej sytuacji albo był nietrafiony w kwestii problemu. Niektóre historyjki nie byłoby sensu rozbijać na mniejsze, bo traci się spójność w kontekście działania danej funkcjonalności. Wiadomo jednak, że wszystko jest sprawą dogadania się z zespołem i w niektórych przypadkach można odejść od standardowych schematów. :)

Temat: User story dla strony z brakiem wyników wyszukiwania

Maciej Kurek:

Zgodze sie, ze user stories powinny byc niezalezne, wertykalnie zdefiniowane i reprezentowac jakis end-to-end flow. Jednak czasami nawet najlepiej zdefiniowana historia, spelniajaca INVEST i majaca swietne kryteria akceptacji bedzie po prostu za duza na jeden sprint (na przyklad: zespol wyestymuje ja na 8 punktow, a jego velocity to 5, stad taki commitment bedzie ryzykowny). Wtedy dalsze rozbicie 'pierwotnej' historii wedlug poszczegolnych kryteriow akceptacji moze okazac sie byc wyjsciem z sytuacji. W opisywanym przykladzie mniejsza historia zdefiniowana tak:

jako klient
chce miec mozliwosc sortowania wynikow wyszukiwania rosnaco
tak, abym mogl bardzo szybko znalezc produkt o najnizszej cenie

moglaby byc dobrym kandydatem wciaz przynoszacym wartosc biznesowa i nieco mniejszym, realnym do dostarczenia po jednym sprincie.

Po pierwsze kryterium "ślepy zaułek" jest słabo zdefiniowanym wymaganie.
A po drugie podejście jak wyżej, z rozbiciem na poszczególne funkcjonalności jest jak najbardziej słuszne.
Najpierw robisz samą wyszukiwarkę, później np. sortowanie, opcje zaawansowane itd.

W ten sposób otrzymujesz przyrost produktu którym możesz się pochwalić Klientowi, oczywiście zaczynając od tej najbardziej wartościowej, biorąc pod uwagę zależności (nie ma sensu robienie sortowania wyników bez samej wyszukiwarki :))