Zacznij od celu i granic zadania
Napisz, kto potrzebuje zmiany, jaki problem rozwiązuje i co po jej wdrożeniu ma wyglądać inaczej. Potem określ zakres: ekran, usługę lub proces objęty pracą oraz elementy poza zadaniem. „Ulepszyć eksport” mówi mało. „Pozwolić opiekunom kont pobrać filtrowaną listę klientów” daje punkt wyjścia.
Dodaj oczekiwane zachowanie, uprawnienia, błędy i sposób sprawdzenia wyniku. Dołącz projekt interakcji, jeśli ma znaczenie. Podlinkuj kontrakt API lub opis danych, jeśli zadanie od nich zależy. Zapisz zależności i ich właścicieli. Niewiadome powinny trafić na listę pytań, a nie zostać ukryte w pewnie brzmiącym kryterium.
Funkcja: eksport klientów
Przed
Tytuł: Eksport klientów
Opis: Dodać przycisk eksportu na liście klientów. Ma być łatwy w użyciu i działać dla wszystkich klientów.
Developer nadal musi zgadywać, kto może eksportować, co oznacza „wszystkich”, jaki format przygotować, czy działają filtry, co zrobić przy pustym wyniku i czy API klientów już to obsługuje. Estymacja zawierałaby te domysły.
Po
Tytuł: Eksport filtrowanych klientów jako CSV
Kontekst i cel: Opiekunowie kont ręcznie kopiują dane kontaktowe klientów. Potrzebują jednego pliku do uzgodnionej listy kontaktów.
Zakres: Ekran Klienci, lista klientów i akcja eksportu CSV. Poza zakresem: eksport cykliczny i wysyłka e-mailem.
Użytkownik i uprawnienia: Product Owner musi potwierdzić przed startem, które istniejące uprawnienie pozwala na eksport.
Oczekiwane działanie: Eksport uwzględnia aktywne filtry i rekordy spoza bieżącej strony. Product Owner potwierdzi listę kolumn, kolejność i dozwolony zakres danych osobowych.
Przypadki brzegowe i błędy: Uzgodnić, czy pusty wynik pobiera plik z nagłówkami czy pokazuje komunikat. Pokazać jasny błąd, gdy żądanie się nie powiedzie. Nie ujawniać danych klientów osobie bez uprawnienia.
Zależności: Obsługa w API klientów i uzgodniony kontrakt CSV. Dołączyć specyfikację API oraz projekt przycisku i stanu ładowania.
Kryteria akceptacji po rozstrzygnięciu decyzji: Uprawniona osoba pobiera potwierdzone kolumny dla wszystkich pasujących klientów; osoba bez uprawnienia nie eksportuje; błąd i pusty wynik zachowują się zgodnie z uzgodnieniem.
Pytania do refinementu: Kto zatwierdza kolumny? Jaki jest maksymalny rozmiar eksportu? Czy eksport działa od razu, czy jako zadanie w tle? Jakie dane testowe obejmą filtry i pusty wynik?
To szkic do refinementu. Wskazany właściciel musi jeszcze potwierdzić otwarte decyzje przed pracą, która od nich zależy.
Błąd: formularz czasami się nie zapisuje
Przed
„Formularz czasami się nie zapisuje”. Brakuje kroków odtworzenia, wyniku faktycznego i oczekiwanego oraz środowiska. Developer może zacząć analizę logów, ale nie potrafi potwierdzić naprawy.
Po
„W formularzu edycji klienta na środowisku testowym kliknięcie Zapisz po zmianie adresu rozliczeniowego sporadycznie zwraca odpowiedź 409. Oczekiwane: nowy adres jest zapisany i pojawia się potwierdzenie. Faktyczne: zostaje stary adres, bez komunikatu. Kroki: otwórz klienta, zmień adres i kliknij Zapisz dwa razy w ciągu pięciu sekund. Problem wystąpił w trzech z pięciu prób na koncie testowym. Dołącz identyfikator żądania i wersję przeglądarki. Przed planowaniem wdrożenia sprawdź, czy błąd występuje też na produkcji.”
Teraz można rozpocząć diagnozę. Ticket nie udaje, że przyczyna jest znana.
Zadanie techniczne: aktualizacja Laravel
Przed
„Zaktualizuj Laravel”. Nie wiadomo, z której i do której wersji, które zależności są objęte pracą i jakie są ograniczenia zgodności.
Po
„Zaktualizuj aplikację z Laravel 10 do uzgodnionego wydania Laravel 11. Przed zmianą zależności potwierdź obsługiwaną wersję PHP i zgodność pakietów. Zachowaj zachowanie publicznego API, zaktualizuj lockfile i uruchom testy jednostkowe oraz integracyjne. Na stagingu sprawdź tworzenie faktur i logowanie. Wypisz pakiety wymagające osobnego zadania, zanim je zmienisz.” To zadanie techniczne; przerobienie go na User Story nie uczyni go jaśniejszym.
Zmiana UI: ułatwienie formularza
Przed
„Popraw ten formularz, żeby był bardziej intuicyjny”. Nie wiadomo, jaką trudność usunąć ani po czym poznać poprawę.
Po
„Na mobilnym formularzu zakupowym użytkownicy przeoczają wymagane pole kodu pocztowego, bo błąd pojawia się pod przyciskiem. Przenieś informację o walidacji obok pola, zgodnie z istniejącym wzorcem formularzy. Przy błędnym kodzie ustaw fokus na polu i pokaż uzgodniony komunikat; przy poprawnym kontynuuj zakup. Potwierdź tekst i projekt przed implementacją.”
Wersje „po” są krótkie, bo dodają tylko decyzje potrzebne do bezpiecznego następnego kroku. Checklista gotowości zadania pomoże znaleźć pozostałe luki, a poradnik kryteriów akceptacji — ustalić sposób przyjęcia wyniku.
Gdy ticket jest wystarczająco jasny, oszacuj pracę i osobno zaplanuj termin. Wcześniej narzędzie do analizy gotowości zadania może wskazać brakujące decyzje i przygotować szkic kryteriów do refinementu. Jego werdykt wspiera rozmowę, ale jej nie zastępuje.