Story pointy w rozwoju — co to jest, skale oceny i zastosowanie
Story pointy — to względne jednostki miary złożoności zadań w elastycznych metodologiach tworzenia oprogramowania. W przeciwieństwie do godzin, story pointy uwzględniają nie tylko czas, ale także złożoność, ryzyko i niepewność zadania. Według danych Scrum.org, 2023, zespoły stosujące ocenę względną w story pointach o 25% rzadziej przekraczają terminy sprintów w porównaniu z zespołami oceniającymi w godzinach.
Najważniejsze
- Story pointy — względne jednostki złożoności zadania, nieprzypisane do czasu.
- Główne skale — Fibonacciego (1, 2, 3, 5, 8, 13, 21) i liniowa (1, 2, 3, 4, 5).
- Velocity — liczba story pointów, którą zespół realizuje w sprincie, używana do prognozowania.
- Główna zaleta — story pointy nie zależą od konkretnego programisty i odzwierciedlają złożoność dla zespołu.
- Kluczowa zasada — zadanie wzorcowe określa skalę: zespół ustala, co to jest 1 story point.
Czym są story pointy?
Story pointy — to metryka złożoności zadania stosowana w Scrum i innych metodologiach Agile. Zespół ocenia każde zadanie nie w godzinach, ale w jednostkach względnych: „to zadanie jest dwa razy bardziej złożone niż wzorcowe”. Takie podejście niweluje różnicę w szybkości różnych programistów i koncentruje się na złożoności.
Pochodzenie terminu
Pojęcie story pointów powstało na początku lat 2000. wraz z popularyzacją Scrum. Jednym z pierwszych metodę opisał Ron Jeffries w ramach Extreme Programming (XP). Chodziło o odejście od oceny w „osobogodzinach”, która zawsze jest niedokładna, na rzecz względnej złożoności, którą zespół określa kolektywnie. Obecnie story pointy są standardem branżowym dla zespołów Agile.
Czynniki uwzględniane w story pointach
Przy ocenie w story pointach zespół uwzględnia trzy czynniki: objętość pracy (ilość kodu, ekranów, logiki), złożoność (wyzwania techniczne, nowe technologie) i niepewność (niejasne wymagania, ryzyka). Jeden story point może oznaczać „proste zadanie bez ryzyka”, a 8 — „złożone zadanie z wysoką niepewnością”.
Skale story pointów: jak wybierać
Wybór skali story pointów wpływa na dokładność oceny i wygodę planowania. Najpopularniejszą skalą jest ciąg Fibonacciego, ale istnieją też alternatywy.
| Skala | Wartości | Zalety | Wady |
|---|---|---|---|
| Fibonacciego | 1, 2, 3, 5, 8, 13, 21 | Naturalny wzrost rozrzutu przy dużych zadaniach | Trudna dla nowych zespołów |
| Liniowa | 1, 2, 3, 4, 5 | Prosta i zrozumiała | Brak rozrzutu dla dużych zadań |
| Potęgowa | 1, 2, 4, 8, 16, 32 | Maksymalny rozrzut przy dużych zadaniach | Duże zadania trudno odróżnić |
| T-Shirt | S, M, L, XL | Szybka przybliżona ocena | Niedokładna, wymaga konwersji |
Dlaczego Fibonacciego? Psychologia skali
Ciąg Fibonacciego nie został wybrany przypadkowo. Różnica między 1 a 2 jest minimalna (50%), a między 13 a 21 — znacząca (62%). Odzwierciedla to rzeczywistość: małe zadania oceniane są dokładniej, duże — z większym rozrzutem. Gdy zadanie jest oceniane na 21 story pointów, zespół rozumie: „nie wiemy, ile to zajmie, ale na pewno więcej niż 13”. Skala Fibonacciego zapobiega fałszywej precyzji.
Zadanie wzorcowe — podstawa skali
Aby skala działała, zespół ustala wzorzec: „zadanie X to 1 story point”. Zazwyczaj wzorcem wybiera się proste, dobrze znane zadanie: „dodaj pole tekstowe na ekran” lub „napraw błąd typu literówka”. Wszystkie pozostałe zadania ocenia się względem wzorca. Bez wzorca story pointy tracą sens — każdy rozumie jednostkę inaczej.
Velocity zespołu i prognozowanie
Velocity (prędkość zespołu) — średnia liczba story pointów, którą zespół realizuje w jednym sprincie. To kluczowa metryka do prognozowania terminów projektu.
Jak oblicza się velocity
Velocity oblicza się na podstawie ukończonych zadań: sumuje się story pointy wszystkich zadań, które zespół zdążył dokończyć (definition of done spełniony). Niezakończone zadania nie są uwzględniane. Dla dokładności bierze się średnią z ostatnich 3-5 sprintów. Na przykład, jeśli zespół zrealizował 20, 22, 18 i 24 story pointy w ostatnich 4 sprintach, velocity = 21 sp.
Prognozowanie przez velocity
Znając velocity i całkowity wolumen backlogu w story pointach, można prognozować liczbę sprintów do wydania. Na przykład, jeśli w backlogu jest 210 story pointów, a velocity = 21, potrzeba 10 sprintów. To przybliżona prognoza, która jest doprecyzowywana w trakcie pracy. Ważne: velocity to średnia, a nie zobowiązanie. Planuj według dolnej granicy (18 sp), a nie średniej.
Jak zwiększyć velocity
Velocity nie można zwiększyć na żądanie — to symptom zdrowia procesów. Trwały wzrost velocity osiąga się poprzez: redukcję długu technicznego, poprawę procesów code review, ograniczenie przełączania kontekstu, automatyzację testowania i CI/CD. Ważne: velocity różnych zespołów nie można porównywać — każdy zespół definiuje story pointy inaczej.
Story pointy vs godziny: co i kiedy stosować
Story pointy i godziny mają różne cele, a wybór między nimi zależy od kontekstu. Doświadczone zespoły używają obu podejść do różnych zadań.
Kiedy story pointy sprawdzają się lepiej
Story pointy są niezastąpione przy planowaniu sprintów: nie zależą od tego, kto będzie wykonywał zadanie. Junior może zrobić 2 sp dziennie, senior — 4 sp, ale ocena zadania pozostaje 2 sp dla obu. Story pointy pozwalają śledzić wydajność zespołu bez porównywania programistów. Zmniejsza to presję polityczną i poprawia atmosferę w zespole.
Kiedy godziny są niezbędne
Godziny są potrzebne do zobowiązań zewnętrznych: kontrakty, kosztorysy, raporty dla klienta. Klient chce wiedzieć nie „8 story pointów”, ale „3 tygodnie”. Do konwersji story pointów na godziny używa się historical conversion rate: zespół wie, że 1 sp = około 4 godziny pracy. Konwersja powinna być przejrzysta i oparta na danych, a nie na domysłach.
Podejście kombinowane
Wiele zespołów stosuje podejście kombinowane: zadania oceniane są w story pointach do planowania sprintu, a następnie menedżer konwertuje je na godziny/dni do raportowania zewnętrznego. Ważne, aby nie mieszać dwóch systemów w jednym procesie: albo oceniasz w story pointach i wyliczasz czas z velocity, albo oceniasz bezpośrednio w godzinach.
Typowe błędy przy pracy ze story pointami
Wdrażanie story pointów często wiąże się z błędami, które niwelują zalety oceny względnej. Oto najczęstsze z nich.
Przywiązywanie story pointów do czasu
Najczęstszy błąd — zespół ustala: „1 sp = 4 godziny”. W tym przypadku story pointy tracą sens i zamieniają się w godziny pod inną nazwą. Story pointy powinny być względne, nieprzypisane do czasu. Jeśli zadanie A jest dwa razy bardziej złożone niż zadanie B, otrzymuje 2 sp, niezależnie od tego, ile godzin zajmie.
Ocena post-factum
Gdy zadanie ocenia się po jego wykonaniu — to nie jest ocena, tylko stwierdzenie faktu. Story pointy powinny być przypisywane przed rozpoczęciem pracy, w momencie maksymalnej niepewności. Ocena post-factum zniekształca velocity i nie przynosi korzyści dla planowania. Co więcej, stwarza fałszywe poczucie dokładności.
Porównywanie velocity różnych zespołów
Porównywanie velocity zespołu A i zespołu B — bezsensowne ćwiczenie. Każdy zespół definiuje wzorzec i skalę inaczej. Dla jednego zespołu 1 sp to proste zadanie na godzinę, dla innego — na dzień. Porównywać można tylko velocity jednego zespołu w dynamice: rośnie czy maleje.
Niekonsekwentna skala
Gdy różne zadania o identycznej złożoności otrzymują różne story pointy, a bardziej złożone — mniejsze, skala się psuje. Zespół powinien regularnie kalibrować skalę: co 3-6 sprintów retrospektywnie weryfikować, na ile oceny odpowiadały rzeczywistej złożoności. Poprawia to spójność ocen.
Często zadawane pytania
Ile godzin ma jeden story point?
Story pointy nie mają stałego odpowiednika w godzinach. To jednostka względna: 1 sp = złożoność zadania wzorcowego. Do konwersji na godziny użyj historical conversion rate swojego zespołu: podziel średnią liczbę przepracowanych godzin w sprincie przez velocity. Zazwyczaj 1 sp = 4-8 godzin, ale to indywidualne dla każdego zespołu.
Czy można używać story pointów w Kanban?
Tak, story pointów można używać w Kanban, ale z zastrzeżeniami. W Kanban nie ma stałych sprintów, dlatego velocity liczy się nie za sprint, ale za tydzień lub miesiąc. Zespoły Kanban często zamiast story pointów używają Cycle Time — czasu przejścia zadania od początku do końca. Wybór zależy od specyfiki zespołu.
Co zrobić, jeśli zespół nie może uzgodnić oceny?
Jeśli oceny się różnią (jeden daje 3 sp, drugi — 13), to sygnał, że zadanie jest słabo zrozumiane. Dekomponuj zadanie na mniejsze części. Omów ryzyka i niepewności, które widzą różni programiści. Jeśli zadanie jest duże — oceń je jako Spike (badanie na 2-4 dni) zamiast story pointów.
Jak przestać oceniać w godzinach i przejść na story pointy?
Przejście zajmuje 3-6 sprintów. Zacznij od wyboru skali (Fibonacciego — safest choice) i określenia zadania wzorcowego. Przeprowadź 2-3 sesje Planning Poker. Po każdym sprincie licz velocity. Nie konwertuj story pointów na godziny — daj zespołowi przywyknąć do nowego systemu. Po 3 sprintach zobaczysz, o ile poprawiło się planowanie.
Czy zmienia się ocena zadania w story pointach po jego wykonaniu?
Nie, ocena się nie zmienia. Story pointy to wstępna ocena złożoności dokonana przed rozpoczęciem pracy. Po wykonaniu zadania ocena pozostaje taka sama, nawet jeśli rzeczywisty nakład pracy był inny. Zmiana oceny post-factum zniekształca statystyki i pozbawia sensu prognozowanie. Analizuj rozbieżności na retrospektywie, ale nie zmieniaj oceny po fakcie.
Podsumowanie
- Story pointy — względne jednostki złożoności, nieprzypisane do czasu, podstawa oceny Agile.
- Główne skale — Fibonacciego (zalecana), liniowa, potęgowa, T-Shirt sizing.
- Velocity — liczba story pointów na sprint; kluczowa metryka do prognozowania terminów.
- Story pointy vs godziny — story pointy do planowania sprintów, godziny do zobowiązań zewnętrznych.
- Typowe błędy — przywiązywanie do czasu, ocena post-factum, porównywanie zespołów, niekonsekwentna skala.
- Zadanie wzorcowe — podstawa skali; bez niego story pointy tracą sens.
- Kluczowa zaleta — story pointy nie zależą od wykonawcy i pozwalają koncentrować się na wydajności zespołu.
Opracujemy aplikację mobilną pod klucz
IT Sectr tworzy aplikacje na iOS i Androida dla startupów i firm od 2017 roku. Doradzimy Ci i zaproponujemy najlepsze rozwiązanie.
Przeczytaj również