Skale trudności - Story Points, skala 1-6 i inne metody w oparciu o React Native

Gdy już poznamy psychologiczne aspekty podejścia do estymacji i mamy odpowiednie zaplecze techniczne, możemy przejść do jednego z kluczowych pojęć w estymacji projektów IT - skali trudności. Dzięki niej programiści, managerowie oraz klienci mogą w prosty sposób zobaczyć zaawansowanie danego zadania oraz jego orientacyjny czas realizacji. Na podstawie skali trudności możemy również analizować velocity zespołu, co pozwala na jeszcze dokładniejsze estymacje. W praktyce stosuje się wiele różnych abstrakcyjnych jednostek służących do pomiaru skali trudności.

Dlaczego więc używamy jednostek abstrakcyjnych, a nie godzin?

Otóż estymacje w godzinach tworzą wrażenie, że dokładnie wiemy, ile czasu zajmie dane zadanie. To pozorna precyzja, która nie uwzględnia kontekstu, nieoczekiwanych problemów czy różnic między platformowych. Do tego dochodzi indywidualna moc przerobowa dewelopera - jedno zadanie może zająć jednej osobie 2 godziny, a innej dokładnie to samo zadanie 6 godzin. Co najgorsze, godzinowe estymaty łatwo stają się obietnicą wobec biznesu. Jeśli powiemy, że coś zajmie od 3 do 5 godzin, klient może spodziewać się efektów już po 2,5 godziny. W efekcie psuje to relacje i zaufanie między deweloperami a biznesem, bo takie estymaty często są nietrafione. Z punktu widzenia Project Managera, godzinowe wyceny utrudniają również planowanie sprintów i tworzenie roadmapy, ponieważ nie oddają relatywnej trudności zadań.

Na swojej drodze możesz spotkać się jeszcze z terminami względnej bądź absolutnej złożoności zadań. Absolutna złożoność zadań to nic innego jak konkretna informacja godzinowa - “To zajmie 2h”. Względna złożoność zadań wykorzystuje abstrakcyjne jednostki (np. Story Points) co pozwala powiedzieć - “To zadanie jest mniej więcej dwa razy trudniejsze niż tamto”. Badania pokazują, że zespoły dochodzą do konsensusu szybciej porównując relatywnie („czy to bardziej jak login, czy bardziej jak wdrożenie płatności?”), dzięki czemu estymata jest stabilniejsza i odporniejsza na indywidualne różnice.

Mając już to wyjaśnione, przejdźmy do najczęściej stosowanej skali oceny trudności.

1. Story Points

Story Pointy to jeden z kluczowych elementów metodologii SCRUM. Są to jednostki miary (abstrakcyjne), które służą do estymacji pracy, biorąc pod uwagę zarówno złożoność, jak i wysiłek potrzebny do ukończenia user story. Dzięki Story Pointom:

• możemy porównywać relatywną trudność zadań - np. zadanie o wartości 2 SP jest mniej więcej dwa razy trudniejsze niż zadanie o wartości 1 SP,
• unikamy estymacji w godzinach, co pozwala skupić się na względnym porównywaniu zadań między sobą,
• estymacja obejmuje nie tylko czas, ale także złożoność techniczną, ryzyko i niepewności.

Dodatkowym dużym atutem stosowania Story Pointów jest możliwość pomiaru velocity zespołu, co ułatwia planowanie sprintów i prognozowanie dostarczanej wartości.

Najczęściej do określania Story Pointów używa się liczb z ciągu Fibonacciego (1, 2, 3, 5, 8, 13…). Wynika to z faktu, że zespołowi łatwiej jest zdecydować, czy dane zadanie zasługuje na 8 SP, czy wystarczy 5 SP, niż precyzyjnie porównywać np. 6 SP do 5 SP - zasada ograniczenia iluzji precyzji. Rosnące wartości w ciągu Fibonacciego odzwierciedlają również fakt, że im większe zadanie, tym więcej niepewności i trudniej ocenić jego dokładną złożoność. W kilkuosobowych zespołach stosowanie takiego podejścia generuje też pożyteczne pytania w dyskusji: np. „Dlaczego przypisałeś temu zadaniu 8 SP? Ja uważam, że wystarczą maksymalnie 3 SP.”

Jak Story Pointy odzwierciedlają niepewność?

Małe zadania, zwykle o wartości 1-3 SP, są stosunkowo pewne, a ryzyko ich realizacji niewielkie. Średnie zadania, przyjmujące wartości 5-8 SP, zawierają już pewne niewiadome - mogą wiązać się z integracjami, różnicami między platformowymi lub wymagać dodatkowej analizy. Duże zadania, o wartości 13 SP i wyżej, są obarczone wysoką niepewnością; wymagają pogłębionej analizy i dyskusji, a niekiedy konieczna jest ich dekompozycja na mniejsze części, aby móc je wiarygodnie oszacować.

2. Alternatywne metody oceniania skali trudności

2.1 Skala liniowa 1-6

Na początku zespoły często wybierają skalę liniową, aby łatwiej wystartować, a dopiero później przechodzą na Story Pointy i ciąg Fibonacciego. W tej metodzie zespół stosuje proste wartości: 1, 2, 3, 4, 5, 6, gdzie:

• 1 to bardzo małe i proste zadanie,
• 6 to bardzo duże, trudne i obarczone ryzykiem zadanie.

Zaletą skali liniowej jest niewątpliwie niski próg wejścia dla nowych osób - jest po prostu łatwa do zrozumienia. Wytłumaczenie jej klientowi również nie stanowi problemu: „6 to zadanie najtrudniejsze, 1 to najprostsze”. Dodatkowo, dla nas - Polaków - jest naturalna, ponieważ przypomina szkolną skalę ocen.

Niestety skala liniowa jest obarczona dużą iluzją dokładności i słabiej podkreśla niepewność przy większych zadaniach. Dla porównania, w ciągu Fibonacciego widzimy wyraźny przeskok między zadaniem 3 SP a 13 SP, co naturalnie skłania do rozbijania większych tasków na mniejsze części. Skala liniowa często prowadzi też do nadmiernej „matematyzacji” estymacji i sporów o detale - deweloperom łatwiej jest dyskutować, czy zadanie powinno mieć 5 SP czy 8 SP, niż czy powinno mieć 3 czy 4 SP.

2.2 T-shirt sizes

Jest to kolejna łatwa do wyobrażenia skala - t-shirt sizes: XS, S, M, L, XL (czasem XXL). Każdy z rozmiarów odpowiada relatywnej złożoności i wysiłkowi, przy czym pomijamy używanie liczb.

Skala jest bardzo intuicyjna, ponieważ wszyscy na co dzień rozumiemy różnicę między S a XL, co ułatwia jej wprowadzenie zarówno do nowego, jak i doświadczonego zespołu. Unika iluzji precyzji, bo nie opiera się na liczbach - jest to jednak jednocześnie jej największa wada. Brak liczb utrudnia mierzenie velocity zespołu, a same rozmiary są mniej dokładne przy planowaniu sprintu. Doskonale nadaje się do porównywania i priorytetyzowania zadań, ale trudniej budować na niej konkretny plan realizacji sprintu.

3. Story points dla React Native - przykłady

1-2 SP: Proste zmiany

• zmiana tekstu,
• zmiana koloru tekstu,
• drobna poprawka w stylach (np. zwiększenie paddingHorizontal dla danego ekranu),
• dodanie/podmiana ikony w istniejącym przycisku,
• podmiana endpointu w istniejącym API callu.

3-5 SP: Standardowe funkcjonalności

• nowy ekran z podstawowym formularzem i walidacją (np. dane Twojego zwierzaka),
• ekran z listą dostępnych gości pobraną z API z podstawowym loading/error state,
• dodanie lokalnego storage (async-storage, MMKV) dla podstawowych danych,
• integracja z bibliotekami UI,
• stworzenie prostej nawigacji,
• dodanie splash screena.

8-13 SP: Złożone funkcjonalności

• wieloetapowy bądź złożony w inny sposób formularz z walidacją i obsługą błędów,
• synchronizacja danych offline-online za pomocą Tanstack Query + persystencja MMKV,
• integracja z Google Maps/Stripe,Firebase, Push Notifications (rejestracja urządzenia, obsługa tokenów, reakcje na kliknięcia),
• zaawansowana nawigacja,
• obsługa deeplinków,
• złożone animacje wymagające React Native Reanimated / React Native Gesture Handler.

21+ SP: Ogromne zadania przeznaczone do dekompozycji

• system zamówień z koszykiem, checkout, płatnościami,
• migracja na nową dużą bibliotekę (upgrade Apollo / React Navigation etc.),
• pełna obsługa offline-first z kolejką mutacji oraz retry logic,
• zaawansowany system skanowania QR/Barcode’ów wraz z integracją z API,
• integracja z wieloma usługami naraz (np. logowanie Google/Apple/Facebook + backend).

4. Skala 1-6 dla React Native - przykłady

1: Proste zmiany UI/tekstu

• zmiana koloru przycisku,
• zmiana koloru tekstu,
• podmiana ikony,
• poprawa literówki,
• dodanie marginesu w stylach.

2: Podstawowe formularze, proste komponenty

• dodanie prostego formularza logowania z TextInput + Button,
• walidacja formularza logowania,
• stworzenie komponentu UserAvatar z obrazkiem i username,
• stworzenie prostej listy elementów statycznych za pomocą FlatList.

3: Integracja API, nawigacja

• pobranie danych z API używając Axios/Fetch,
• wyświetlanie listy produktow z backendu używając FlatList i obsługą paginacji,
• konfiguracja react navigation i dodanie szczegółów produktu z parametrami w navigation.navigate() aby otworzyć ekran ze szczegółami produktu.

4: Złożona logika, state managment

• użycie TanStack Query/Apollo do cachowania i synchronizacji danych,
• obsługa trybu offline-first używając MMKV i NetInfo,
• implementacja optymistycznych updateów,
• zagnieżdżone formularze z walidacją warunkową,
• integracja z Redux/Zustand do globalnego stanu,
• własne hooki zarządzające logiką biznesową.

5: Integracja z Native modules, rozwiązywania problemów międzyplatformowych

• podłączenie SDK do płatności np. Stripe, Adyen, które wymagają natywnej konfiguracji w plikach natywnych,
• własny native module,
• integracja push notyfikacji wykorzystując Firebase Cloud Messaging i APNs,
• debugging różnic pomiędzy iOS i Android,
• debugging problemów tylko na jednym systemie.

6: Zmiany architekturalne, poprawa performance aplikacji

• migracja do React Native New Architecture (Fabric + TurboModules),
• refaktoryzacja całego state managmentu,
• wprowadzenie modułowej architektury,
• optymalizacja list,
• code splitting,
• profilowanie i usuwanie memory leaków,
• wdrożenie CI/CD wykorzystując Bitrise/EAS.

5. Czynniki zwiększające złożoność

Oprócz samych skal zadań (1-6, Story Points) istnieją czynniki, które znacząco zwiększają złożoność implementacji. Można je traktować jak multiplikatory trudności. Część z nich można zauważyć już w przytoczonych wcześniej przykładach dla poszczególnych skal.

Jednym z największych czynników zwiększających złożoność w tworzeniu aplikacji mobilnych za pomocą React Native (choć podobne zjawisko można zauważyć także we Flutterze) są różnice między iOS a Androidem. Oba systemy mają własny sposób przyznawania uprawnień, znaczące różnice w wyglądzie i zachowaniu oraz często całkowicie inne API. Co działa „out of the box” na Androidzie, może wymagać dodatkowej konfiguracji na iOS lub, co gorsza, w ogóle nie być możliwe do wykonania.

Kolejnym istotnym czynnikiem zwiększającym złożoność jest integracja z zewnętrznymi systemami. Niejednemu deweloperowi sen z powiek spędziła np. integracja z SDK do płatności czy logowanie przez OAuth/SSO. Do tej samej kategorii można zaliczyć również integracje z hardware’em lub backendami, które nie posiadają stabilnego i dobrze udokumentowanego API.

Tworząc aplikację mobilną, musimy mieć na uwadze skalowalność projektu. Z tego powodu dużą uwagę należy poświęcić szeroko pojętemu performance aplikacji, który można traktować jako kolejny czynnik zwiększający złożoność. Dlaczego? Ponieważ nie istnieje jedna uniwersalna metoda optymalizacji. Co dla użytkownika może być płynnym działaniem aplikacji, dla nas oznacza m.in.: optymalizację list, animacji w 60 FPS, zarządzanie pamięcią (np. cache obrazków, unikanie memory leaks), obsługę offline-first z optymistycznymi update’ami i synchronizacją danych, a także lazy loading i code splitting przy ciężkich ekranach.

Ale to nie wszystko. Żyjemy w 2025 roku, w dobie AI, gdzie wycieki danych i oszustwa zdarzają się coraz częściej. Dlatego kolejnym czynnikiem zwiększającym złożoność jest bezpieczeństwo danych. Wymaga ono szczególnej uwagi przy przechowywaniu tokenów, szyfrowaniu danych, ochronie komunikacji, obsłudze informacji wrażliwych oraz bezpiecznym przechowywaniu tokenów w plikach .env.

To wszystko sprawia, że zadanie, które na pierwszy rzut oka mogłoby być ocenione na 3 SP, może w rzeczywistości wymagać nawet 21 SP. Przykładem może być logowanie, które angażuje co najmniej trzy z wcześniej wymienionych czynników zwiększających złożoność.

6. Jak dekompozycja wpływa na ocenę? To samo zadanie w różnych skalach

Aby pokazać Ci jak podział wpływa na skalę i story pointy, przedstawię jeden przykład - “Lista zamówień” w dwóch podejściach.

Wersja 1 (bez dekompozycji)

Opis: Stwórz ekran listy zamówień z integracją z API, obsłuż paginację, możliwość zmiany statusu zamówienia, trybem offline-first i push notyfikacjami.

Biorąc pod uwagę przykłady wymienione wcześniej w tym artukule możemy oszacować czas tego zadania: - Skala: 5-6 (mamy integrację API, logikę offline, natywne moduły) - Story Points: 13+ (duże ryzyko, dużo zależności, jeden wielki moduł do dowiezenia)

Jakie są problemy z tym zadaniem? Trudno je oszacować. Zakres jest bardzo szeroki i zakrawa o trudne i wymagające czasu zagadnienia. Dodatkowo, istnieje duże ryzyko poślizgu spowodowane np. blokadą na API lub problemami z Firebase.

Wersja 2 (po dekompozycji)

Przeprowadźmy podstawową dekompozycję zadania na mniejsze taski.

Task 1 - Wyświetlanie listy zamówień

Skala: 2 SP: 2

Efekt: można klikać w UI, widać postęp

Task 2 - Integracja z API + paginacja

Skala: 3 SP: 5

Efekt: dostęp do realnych danych i działającej listy

Task 3 - Zmiana statusu zamówienia (optimistic updates)

Skala: 4 SP: 5-8

Efekt: interaktywność, zarządzanie zamówieniami, wstęp do offline-first

Task 4 - Offline first mode (persist + sync)

Skala: 5 SP: 8

Efekt: Lista zamówień działa bez internetu, pamięta co użytkownik miał w liście.

Task 5 - Push notifications

Skala: 5 SP: 8

Efekt: użytkownik dostaje informacje o zmianach w zamówieniach

Na tym przykładzie widać, że dekompozycja obniża ocenę poszczególnych elementów – zamiast jednego dużego zadania o wysokiej ocenie i dużym ryzyku, mamy kilka mniejszych zadań z mniejszym ryzykiem. Dzięki temu łatwiej planować sprinty, developer szybciej może pokazać efekty swojej pracy (np. wyświetlenie listy pobranej z API), a ryzyko blokad spada, ponieważ reszta zadań może być realizowana równolegle, np. oczekując na gotowość backendu.

7. Podsumowanie

Ten artykuł miał na celu pokazanie, czym są skale trudności i jak ich używać, korzystając z realnych przykładów. Przedstawione skale 1-6, Story Points oraz dekompozycja dużego zadania służą przede wszystkim technicznej ocenie zadań i planowaniu pracy zespołu. W komunikacji z biznesem lub osobami nietechnicznymi nie zawsze chodzi o wchodzenie w szczegóły implementacyjne. Ważne jest, aby podkreślić, że skala używana do estymaty nie przekłada się na godziny - wyceny czasowe to osobna kwestia. Z perspektywy developera nie ma sensu również tłumaczyć np.: „To zadanie ma 8 SP, bo musimy użyć TanStack Query, zrobić offline-first, persist, sync i optimistic updates.” Lepiej powiedzieć: „To zadanie jest duże, ponieważ wymaga integracji z kilkoma systemami i musi działać płynnie również bez internetu, dlatego traktujemy je jako większe zadanie, które zajmie więcej niż jeden sprint.” Dekompozycja zadań dodatkowo poprawia komunikację - zamiast jednego dużego „będzie za dwa miesiące”, możemy pokazywać kolejne kamienie milowe. Wszystko po to, aby w prosty sposób powiedzieć biznesowi, co dostanie, kiedy i z jakim ryzykiem.