Przykładowa tabela dla Product Backlogu
Chciałbym pokazać bardzo prosty sposób, jak można przedstawiać User Stories w tabelarycznym Product Backlogu. Pomysł ten przyszedł mi do głowy, gdy natrafiłem na jeden z moich starych Product Backlogów sprzed dziewięciu lat i pomyślałem: „Wow, w porównaniu do tego, co robię dziś, jest całkiem przestarzały." Dlatego pokażę Wam tutaj szablon Product Backlogu w formie tabeli (np. Excel).
Jak być może wiecie, jestem wielkim zwolennikiem pisania Backlogu za pomocą User Stories i budowania tych User Stories w następujący sposób:
„Jako ______ chcę ______, aby ________."
Mogłoby to wyglądać tak: „Jako częsty podróżnik chcę mieć dostęp do internetu podczas lotu, aby móc aktualizować mojego bloga podczas podróży, zamiast zapisywać jedynie dokument tekstowy, z którym mógłbym zaktualizować bloga dopiero później." (Czy możecie się domyślić, gdzie to napisałem?)
Pracując z arkuszem Excel, uważam za najłatwiejsze użycie elementów składowych User Stories jako nagłówków kolumn. W ten sposób otrzymuje się nagłówki „Jako", „chcę" i „aby" lub „ponieważ". Istota każdej historii jest wtedy dobrze widoczna. Można również dodać kolejne kolumny, np. dla numeracji, uwag, statusu itp. W poniższym przykładzie dodałem również kolumnę dla nadrzędnego tematu danej Story.
| ID | Temat | Jako... | chcę... | aby... | Uwagi | Priorytet | Status |
| 2 | Gra | Moderator | stworzyć nową grę, wpisując nazwę i opcjonalny opis | móc zapraszać innych do oceniania | Jeśli gier nie można zapisywać i wracać do nich, opis nie jest konieczny | wymagany | done |
| 2 | Gra | Moderator | zapraszać innych do oceniania, dając im adres URL, za pomocą którego mogą dołączyć do gry | móc rozpocząć grę | Adres URL powinien być sformatowany tak, aby można go było łatwo przekazać przez telefon | done | |
| 5 | Gra | Estymator (osoba, która ma wystawić ocenę) | dołączyć do gry, wpisując swoje imię na stronie, do której otrzymałem adres URL | móc uczestniczyć w grze | done | ||
| 6 | Gra | Moderator | rozpocząć rundę, wpisując element w wieloliniowe pole tekstowe | móc go ocenić | done | ||
| 8 | Gra | Estymator | zobaczyć element, który ma być oceniony | wiedzieć, za co wystawiam ocenę | done | ||
| 40 | Gra | Uczestnik | mieć karty zawsze w tej samej kolejności przy wielokrotnym losowaniu | łatwiej porównywać oceny | Zastąpione przez A08, aby historia nie mówiła o "tej samej kolejności", bo to może być szczegół UI | done | |
| 35 | niefunkcjonalne | Użytkownik | aby aplikacja szybko reagowała na moje działania | nie nudzić się | done | ||
| 36 | niefunkcjonalne | Użytkownik | dobrych stron błędów, gdy coś idzie nie tak | móc ufać systemowi i jego twórcom | done | ||
| A11 | niefunkcjonalne | Badacz | aby wyniki były zapisywane w sposób nieidentyfikowalny | móc badać dane, np. czy oceny przypominają pierwszą opinię wystawioną przez "Estrmatora A" | Nie należy zapisywać nazw ani tekstu, ale każdą kartę, kto ją zagrał i ostateczną ocenę | ||
| A05 | Gra | Moderator | zmienić jeden z ocenianych elementów | lepiej odzwierciedlał rozumienie elementu przez zespół | |||
| 22 | Archiwum | Moderator | eksportować dane gry jako plik CSV | móc dalej przetwarzać stories i oceny | Wyeksportowany plik powinien być możliwy do ponownego importu do systemu | done |
Moja ulubiona struktura User Stories
=> Pisanie User Stories
