Przykłady punktów historii: skala referencyjna od 1 do 13
Sześć przykładów backlogu, które pomogą Twojemu zespołowi porównać zadania, zweryfikować założenia i wybrać własne historie referencyjne.
Estymacja w punktach historii wyraża względny rozmiar pracy dla konkretnego zespołu, uwzględniając nakład pracy, złożoność i niepewność. Ukończony, dobrze znany element jest więc przydatnym punktem odniesienia przy omawianiu kolejnego. Przewodnik Atlassian dotyczący estymacji wyjaśnia tę względną metodę.
Na przykład zespół może przypisać znajomej zmianie ustawień 2 punkty, a nowemu procesowi powiadomień 5. Pytanie brzmi: jaka dodatkowa praca tłumaczy tę różnicę?
Poniższe przykłady pochodzą od fikcyjnego zespołu tworzącego współdzieloną przestrzeń dokumentów. Są to punkty wyjścia do dyskusji, a nie standardowe wyceny funkcji. Twój zespół może rozsądnie wybrać inne wartości.
Sześć przykładów na skali jednego zespołu
Załóżmy, że ten zespół ma już bibliotekę komponentów, uprawnienia do przestrzeni, usługę powiadomień oraz zautomatyzowane kontrole wokół swoich istniejących procesów. Każda estymacja obejmuje implementację, przegląd i testy niezbędne do spełnienia definicji ukończenia zadania w zespole.
| Punkty | Element backlogu | Zawarte w tym przykładzie | Dlaczego zespół umieścił to tutaj |
|---|---|---|---|
| 1 | Wyjaśnij pusty kanał aktywności | Zatwierdzony tekst i istniejący komponent stanu pustego; brak nowych zachowań | Mała, znana zmiana wpływająca na niewiele stanów |
| 2 | Pozwól administratorom przestrzeni zmienić wspólną nazwę wyświetlaną | Istniejący formularz ustawień, API i kontrola uprawnień administratora; walidacja oraz stany zapisu/błędu | Znana ścieżka z kilkoma sprawdzeniami zachowań; element referencyjny zespołu |
| 3 | Filtrowanie dokumentów po właścicielu | Istniejący komponent filtra i wsparcie API; zachowanie resetu i puste wyniki | Więcej stanów interakcji UI niż w elemencie referencyjnym, ze znaną ścieżką danych |
| 5 | Powiadom właściciela dokumentu, gdy ktoś prosi o dostęp | Istniejąca usługa dostarczania; sprawdzenia uprawnień, treść powiadomienia, obsługa duplikatów i link do żądania | Kilka istniejących części musi działać razem poprawnie |
| 8 | Przenieś własność dokumentu w obrębie przestrzeni | Nowa operacja transferu; zmiany uprawnień, współbieżne edycje oraz wpis audytowy | Szersza zmiana stanu z przypadkami awarii wymagającymi dokładnej zgody |
| 13 | Przenieś folder i jego dokumenty do innej przestrzeni | Uprawnienia docelowe, linki, częściowe błędy i zachowanie odzyskiwania | Zbyt wiele powiązanych decyzji, by ten element pozostał wygodny; omów podział |
Założenia infrastruktury mają znaczenie. Zespół bez usługi powiadomień wyceniałby dodatkową pracę w przykładzie za 5 punktów. Zespół ze sprawdzoną operacją transferu własności mógłby ustawić ten element na niższym poziomie.
Te liczby nie są wzorem. Liczenie ekranów UI, punktów końcowych czy kryteriów akceptacji nie odtworzy estymacji w sposób wiarygodny.
Jak zakres wpływa na estymację
Rozważ „zmianę nazwy wyświetlanej przestrzeni roboczej”. Tabela zakłada, że admin edytuje wspólną etykietę wyświetlaną w ustawieniach, korzystając z istniejącego punktu aktualizacji i kontroli uprawnień.
Teraz zmień warunki akceptacji:
| Wersja | Zakres | Szacunkowa estymacja |
|---|---|---|
| A | Zmień etykietę pokazywaną w ustawieniach przestrzeni; użyj istniejącej operacji zapisu | 2 |
| B | Zaktualizuj również zawartość zaproszeń i pamięć podręczną nawigacji; zachowaj spójność tych elementów, jeśli aktualizacja częściowo się nie powiedzie | 5 |
| C | Nazwa decyduje też o publicznym URL przestrzeni; zachowaj stare linki i obsłuż kolizje | Wstrzymaj się, aby wyjaśnić, potem możliwe 8 lub podział |
Wersja C stawia pytanie produktowe zanim zadane zostanie pytanie o rozmiar: czy zmiana nazwy w ogóle powinna zmieniać URL? Decyzja o zachowaniu stabilnego URL mogłaby usunąć dużą część dodatkowej pracy.
Jeśli jeden uczestnik głosuje 2, a inny 8, poproś każdego o opis zachowań, które uwzględnili. Mogą oboje konsekwentnie oceniać różne wersje. Przepisz warunki akceptacji przed ponownym głosowaniem.
Wybierz historie referencyjne, które Twój zespół pamięta
Wybierz dwa lub trzy ukończone elementy z wyraźnymi granicami. Mała znana zmiana, średni proces oraz większa, ale zrozumiała zmiana dają zespołowi więcej praktycznych punktów odniesienia niż pojedyncza abstrakcyjna liczba.
Do każdej historii referencyjnej zachowaj krótką notatkę:
- Jaki był efekt dla użytkownika?
- Jakie systemy i stany uległy zmianie?
- Jakie prace przeglądowe i weryfikacyjne były zawarte?
- Jakie założenia sprawiły, że było to proste lub trudne?
Następnie porównaj nową pracę z najbliższą historią referencyjną. „To przypomina naszą zmianę ustawień, ale dodaje dwie ścieżki uprawnień” daje konkretne punkty do dyskusji.
Jeśli zespół nie ma wspólnej historii dostarczania, wybierz dobrze rozumiany element jako tymczasową referencję. Przejrzyj go po dostawie i zachowaj widoczne założenia. Nie ma potrzeby tworzenia idealnej skali przed wspólnym zdobyciem doświadczenia przez zespół.
Skopiuj tę notatkę estymacyjną do elementu backlogu
Użyj poniższego jako pomocy do dyskusji w backlogu lub notatkach zespołu:
Efekt dla użytkownika:
Zawarte zachowania:
Wyraźnie wykluczone:
Najbliższa ukończona referencja:
Co powoduje, że jest to mniejsze lub większe:
Nieznane, które mogą zmienić zakres:
Decyzja: estymacja / podział / zbadanie
Uzgodniona estymacja, jeśli gotowa:
Następne wyjaśnienie i właściciel, jeśli potrzebne:
Oto wypełniony przykład dla elementu powiadomienia o dostępie:
Efekt dla użytkownika: właściciel dokumentu dowiaduje się, że członek przestrzeni poprosił o dostęp i może otworzyć to żądanie.
Zawarte: korzystanie z istniejącej usługi powiadomień, sprawdzenie uprawnień odbiorcy, link do oczekującego żądania oraz unikanie duplikatów powiadomień przy ponownej próbie dostarczenia.
Wykluczone: przypomnienia e-mail, codzienne podsumowania i automatyczne udzielanie dostępu.
Referencja: nasza 2-punktowa zmiana ustawień korzysta z jednej znanej ścieżki zapisu. Ten element łączy ścieżki żądania, uprawnień i dostarczania, więc wymaga więcej koordynacji i obsługi błędów.
Pytanie otwarte: czy usługa już zapobiega duplikatom powiadomień? Opiekun usługi potwierdzi to przed ustaleniem estymacji.
W fikcyjnym scenariuszu tabeli ta weryfikacja potwierdza wsparcie dla ponownego dostarczenia i zespół zgadza się na 5. Bez niej zespół musi omówić dodatkową pracę przed użyciem tej samej liczby. Referencja wyjaśnia porównanie; nie wylicza odpowiedzi.
Do przebiegu spotkania użyj przewodnika krok po kroku po Planning Poker. Obejmuje on prywatne głosowanie, omawianie różnic i wybór wyniku kolejnej rundy.
Kiedy liczba jeszcze nie jest przydatna
Wróć do wyjaśnień, gdy nieznany czynnik zmienia charakter pracy. „Jaki tekst powinno mieć powiadomienie?” to inna niepewność niż „Czy docelowa przestrzeń zezwala na użytkowników zewnętrznych?”
W przykładzie przenoszenia folderu zespół może najpierw ustalić mniejszy efekt dla użytkownika: przenieść jeden dokument między przestrzeniami, którymi zarządza użytkownik. Ta pierwsza część nadal wymaga wyraźnych uprawnień docelowych, zachowanych zasad dostępu i bezpiecznej obsługi awarii, aby przerwane przenoszenie nie utraciło dokumentu ani nie udostępniło go niewłaściwym osobom. Przenoszenie partii dokumentów może być osobnym zadaniem. Zmniejszenie wielkości partii zawęża zakres pracy; nie usuwa jednak potrzeby obsługi awarii.
Po podziale oszacuj każdy element osobno. Nowe wartości nie muszą sumować się ponownie do 13: zespół zmienił zakres i zdobył więcej wiedzy o pracy.
Najczęściej zadawane pytania zespołów
Ile godzin to historia o wartości 3 punktów?
Nie ma uniwersalnej konwersji. Przykłady tutaj porównują pracę w ramach fikcyjnego zespołu. Jeśli potrzebujesz prognozy dostawy, wykorzystaj własną historię dostarczania i aktualną zdolność przerobową, a niepewność omawiaj oddzielnie od wartości punktu.
Czy każdy błąd to element o wartości 1 punktu?
Nie. Powtarzalny błąd wyświetlania o znanej przyczynie różni się od sporadycznej utraty danych, której przyczyna jest nieznana. Wyjaśnij, co estymujesz: naprawę, badanie czy oba razem.
Czy każdy zespół musi dzielić historię wartą 13 punktów?
Nie. Tutaj 13 oznacza pracę, którą ten konkretny zespół chce rozważyć i podzielić. Granica Twojego zespołu zależy od jego odniesień i zdolności rozumienia oraz realizacji elementu.
Wprowadź swoje odniesienia do Planning Poker
Wybierz kilka nadchodzących elementów, opisz ich granice akceptacji i trzymaj historie referencyjne obok nich. Użyj Agilo Planning Poker podczas sesji estymacji zespołu.
Utwórz pokój Planning Poker, gdy elementy będą gotowe do omówienia.
