Epik (epic) to w zwinnym zarządzaniu backlogiem duża porcja pracy - zbyt duża, by zmieścić się w jednym sprincie - którą dzieli się na mniejsze historyjki użytkownika (user stories). Epik opisuje cel i kierunek; szczegóły powstają dopiero przy cięciu na historyjki, często już w trakcie projektu.
Analityk pracuje epikami przy strukturyzowaniu backlogu: epiki nadają mapie produktu czytelność (kilkanaście epików zamiast trzystu historyjek), a ich kolejne dekompozycje to naturalny rytm pracy analitycznej - refinement to w dużej części właśnie cięcie epików.
W MediFlow epik „Rezerwacja wizyty online" rozpadł się docelowo na 14 historyjek: wybór przychodni, wybór lekarza i terminu, weryfikacja ubezpieczenia, rezerwacja dla dziecka, płatność za wizytę komercyjną, potwierdzenie SMS i tak dalej. Na starcie projektu istniały tylko cztery pierwsze - reszta dopisywała się falami, w miarę jak zespół uczył się domeny. I to jest w porządku: epik z kompletem historyjek rozpisanym na rok do przodu to fikcja planistyczna.
Częsta pomyłka: traktowanie epika jak „dużej historyjki" z pełnymi kryteriami akceptacji. Epik celowo jest niedospecyfikowany - szczegóły dodaje się tuż przed realizacją, kiedy wiedza jest największa. Druga, częstsza: cięcie epików warstwami technicznymi („backend rezerwacji", „frontend rezerwacji"). Historyjka po takim cięciu nie dostarcza nic działającego. Tnie się wartością dla użytkownika: najpierw najprostsza działająca rezerwacja end-to-end, potem warianty.
Epik, epika czy epic - trzy formy tego samego słowa
Najpierw formy, bo w polskich zespołach krążą trzy naraz i każda jest w użyciu.
| Forma | Gdzie ją usłyszysz | Uwaga |
|---|---|---|
| epik (ten epik) | mowa potoczna zespołów, "potnij tego epika" | najczęstsza w rozmowie, odmienia się jak rzeczownik męski |
| epika (ta epika) | dokumentacja, materiały szkoleniowe, tłumaczenia | poprawna i szeroko używana, my sami mamy ją w kursie |
| epic | Jira, narzędzia, dokumentacja anglojęzyczna | typ zgłoszenia nazywa się "Epic" i tego w narzędziu nie przetłumaczysz |
Żadna z tych form nie jest błędem i nie warto o to kruszyć kopii na refinemencie. Warto natomiast wiedzieć, że w jednym projekcie ktoś powie "epik", a drugi napisze "epika", i to nadal ta sama rzecz.
Przy okazji ciekawostka, która tłumaczy, czemu wyniki wyszukiwania na to hasło bywają dziwne: "epik" żyje w polszczyźnie też poza IT, bo tak nazywa się twórcę epiki, gatunku literackiego. Google miesza więc backlog z literaturą, a my siedzimy w tych wynikach obok Homera.
Gdzie epik siedzi w hierarchii backlogu
Najkrótsza odpowiedź: epik jest o piętro wyżej niż historyjka, a często o dwa. Klasyczny układ w większym produkcie ma trzy poziomy abstrakcji.
| Poziom | Co to jest | Kto o tym rozmawia | Horyzont |
|---|---|---|---|
| Epik | duży cel obejmujący wiele funkcji | zarząd, sponsor, product management | kwartały |
| Feature | konkretna funkcjonalność realizująca epik | product owner, zespół | kolejne iteracje |
| Historyjka użytkownika | najmniejsza jednostka z perspektywy użytkownika | zespół, na refinemencie | sprint |
W naszym kursie wprowadzającym pokazujemy to na zespole EduNest, który buduje moduł quizów dla szkół. Epik brzmi "Pełny moduł raportowania dla nauczyciela". Feature pod nim to "Raport postępów ucznia w czasie". A historyjka to już "Jako nauczyciel chcę zobaczyć wykres wyników jednego ucznia z ostatniego miesiąca, aby ocenić jego postęp".
Zwróć uwagę, co ta hierarchia naprawdę robi. Nie porządkuje pracy dla samego porządku. Ona daje ci trzy różne języki do trzech różnych rozmów. Z dyrektorem EduNest rozmawiasz o epiku, bo jego interesuje, czy w ogóle będzie raportowanie. Z zespołem rozmawiasz o historyjce, bo zespół pyta, co wchodzi do sprintu. Jeśli spróbujesz odwrotnie, jedna strona się znudzi, a druga zgłupieje.
Poziom "feature" bywa pomijany i w małych produktach to normalne. Wtedy pod epikiem wiszą od razu historyjki i nikomu nic złego się nie dzieje.
Epik w Jirze i epik w SAFe to dwa różne zwierzęta
Tu wpada najwięcej ludzi, więc rozgraniczmy to twardo.
W Jirze "Epic" to typ zgłoszenia. Technicznie: pojemnik, do którego podpinasz inne zgłoszenia, żeby dało się je filtrować i pokazywać na tablicy razem. Nic więcej za tym nie stoi. Jeśli twój zespół nazwie epikiem dowolny worek na osiem historyjek, Jira się nie obrazi.
W SAFe epik to konstrukcja z konkretnego frameworku, osadzona w czterostopniowej drabinie: epiki, capabilities, features, stories. Epik na poziomie portfela ma tam swój formularz, uzasadnienie biznesowe i przechodzi przez decyzję inwestycyjną. To znacznie cięższy obiekt niż etykieta w narzędziu.
Praktyczny wniosek dla analityka wchodzącego do nowego projektu: zanim zaczniesz "ciąć epiki", zapytaj, czy w tej firmie epik to worek w Jirze, czy pozycja w portfelu z uzasadnieniem inwestycyjnym. Odpowiedź zmienia twoją robotę o sto osiemdziesiąt stopni. W pierwszym przypadku wystarczy zdrowy rozsądek. W drugim będziesz pisać uzasadnienie i bronić go przed ludźmi, którzy dysponują budżetem.
Scrum Guide nie zna słowa "epik"
Sprawdziłem to dzisiaj w źródle, bo pochodzenie terminu ma tu znaczenie praktyczne. W Scrum Guide z listopada 2020 słowo "epic" nie pada ani razu. Scrum zna wyłącznie "Product Backlog item", czyli element backlogu produktu, bez podziału na wielkości i piętra.
Epik nie jest więc pojęciem Scruma. Przyszedł z praktyki zespołów i z narzędzi, przyjął się, bo jest wygodny, i dziś funkcjonuje szerzej niż niejeden termin z oficjalnych przewodników. Ale kiedy ktoś na spotkaniu mówi "przecież Scrum wymaga epików", to po prostu nieprawda. Scrum nie wymaga, Jira sugeruje, a SAFe faktycznie definiuje.
Znajomość tej różnicy przydaje się na rozmowach o pracę i w sporach o proces. Zwłaszcza w sporach.
Skąd wiadomo, że coś jest epikiem, a nie dużą historyjką
Trzy pytania, które załatwiają sprawę w trzydzieści sekund.
- Czy da się to dowieźć w jednym sprincie? Nie da się to sygnał, ale sam w sobie za słaby. Historyjka też potrafi nie zmieścić się w sprincie, jeśli jest źle napisana.
- Czy da się z tego wyciąć kilka niezależnych kawałków, z których każdy daje użytkownikowi coś działającego? Da się to epik. Nie da się to prawdopodobnie po prostu duża historyjka do przepisania.
- Czy potrafisz dziś napisać do tego komplet kryteriów akceptacji? Jeśli tak, to nie epik. Epik z natury jest niedospecyfikowany.
Punkt drugi jest najważniejszy i to on odróżnia epik od bałaganu. "Rezerwacja wizyty online" to epik, bo można z niej wyciąć samo umówienie terminu, potem rezerwację dla dziecka, potem płatność za wizytę komercyjną, i po każdym cięciu pacjent może czegoś użyć. "Poprawić rejestrację" to nie epik, tylko notatka po korytarzowej rozmowie.
Trzynaście story pointów nie robi z historyjki epika
W naszej tabeli story pointów przy trzynastce stoi etykieta epika do podziału i tak mówi pół branży. To skrót myślowy, który w jednym miejscu się rozjeżdża.
Estymata mówi o nakładzie, ryzyku i niepewności. Epik mówi o zakresie i strukturze. To dwie różne osie. Historyjka może dostać trzynaście punktów, bo zespół pierwszy raz dotyka nieznanej biblioteki, a nie dlatego, że kryje w sobie pięć osobnych funkcji. Po spike'u ta sama historyjka spadnie do trójki i żaden epik z niej nie wyjdzie.
Odwrotnie też się zdarza. Epik "Powiadomienia dla pacjentów" po rozbiciu dał w MediFlow trzy historyjki, żadna z nich duża: SMS przypominający dobę przed wizytą, mail z potwierdzeniem rezerwacji i odwołanie wizyty linkiem z SMS-a. Na tej samej sesji doszła czwarta, bo ktoś zapytał, co z pacjentami, którzy nie mają numeru telefonu w bazie, a jest ich osiem procent. Estymat tych historyjek nie podaję, bo nie o nie tu chodzi: epik był prawdziwy nie dlatego, że coś wyszło na trzynaście punktów, tylko dlatego, że kryły się w nim trzy osobne kawałki wartości dla pacjenta i czwarty, który je umożliwiał.
Praktycznie: wysoka estymata to sygnał "porozmawiajmy o tym", nie automatyczna etykieta.
Jak ciąć epik, żeby historyjki miały sens
Tnie się wartością dla użytkownika, nie warstwą techniczną. To jedno zdanie odpowiada za większość różnicy między backlogiem, który działa, a backlogiem, który tylko wygląda.
Cięcie warstwami wygląda kusząco, bo pasuje do podziału pracy w zespole: backend rezerwacji, frontend rezerwacji, integracja rezerwacji. Problem w tym, że po dowiezieniu pierwszej z tych trzech pozycji użytkownik nie może zrobić nic. Nie da się tego pokazać na demie, nie da się z tego niczego nauczyć, a "gotowe" oznacza wyłącznie, że komuś przybyło kodu.
Cięcie wartością daje najpierw najprostszą działającą ścieżkę od początku do końca, a potem warianty. Dla MediFlow było to: najpierw najzwyklejsza rezerwacja terminu u wybranego lekarza, potem weryfikacja ubezpieczenia, potem rezerwacja dla dziecka, potem płatność za wizytę komercyjną. Po pierwszym cięciu pacjent już się umawia, choć jeszcze bez udogodnień.
Sam epik "Rezerwacja wizyty online" rozpadł się docelowo na czternaście historyjek, ale na starcie projektu istniały tylko cztery. Reszta dopisywała się falami, w miarę jak zespół uczył się domeny. To nie jest niedbalstwo, to właściwy sposób pracy: refinement jest po to, żeby dokładać szczegóły tuż przed realizacją, kiedy wiadomo najwięcej.
Najprostsze osie, po których to cięcie idzie: kolejne kroki ścieżki użytkownika oraz warianty tej samej operacji, od domyślnego do brzegowego. Pełny katalog wzorców cięcia, z przykładami "źle" i "dobrze", rozbieramy we wpisie o pisaniu historyjek użytkownika - tutaj chodzi o samo pojęcie, nie o poradnik.
Ile epików powinno być w backlogu
Tyle, żeby dało się je ogarnąć jednym spojrzeniem. W praktyce oznacza to kilka do kilkunastu na produkt, nie kilkadziesiąt.
W MediFlow backlog rejestracji online żył w Jirze i miał epiki per obszar: rezerwacja, grafiki, powiadomienia, płatności, integracja z systemem medycznym placówki (HIS). Pięć pojemników, pod nimi kilkaset zgłoszeń. Dzięki temu na pytanie "co zostało do końca roku" dało się odpowiedzieć w jednym zdaniu, a nie przewijaniem listy.
Kontrprzykład z tego samego projektu opisaliśmy szerzej we wpisie o prowadzeniu backlogu: w trzecim miesiącu prac backlog urósł do trzystu dwunastu pozycji, w tym czternastu z priorytetem "Krytyczny". Kiedy wszystko jest krytyczne, nic nie jest. Epiki nie naprawiają takiego stanu same z siebie, ale bez nich nie da się go nawet zobaczyć.
Sygnał, że epików jest za dużo: nikt nie pamięta, jak się nazywają, a na tablicy pojawiają się epiki z jedną historyjką w środku. Sygnał, że za mało: jeden epik zbiera połowę backlogu i nazywa się "System".
Czy epik potrzebuje kryteriów akceptacji
Nie w tym sensie, w jakim potrzebuje ich historyjka. Kryteria akceptacji sprawdzają, czy konkretna rzecz działa, a epika nikt nie odbiera jako jednej rzeczy.
Epik potrzebuje czegoś innego: warunku zamknięcia. Zdania, które mówi, kiedy uznajemy go za skończony. "Epik zamykamy, gdy pacjent może umówić, przełożyć i odwołać wizytę bez telefonu do rejestracji." Takie zdanie ma sens, bo da się je sprawdzić bez rozbierania na czynniki pierwsze.
Nie myl tego z Definition of Done, które jest wspólne dla wszystkich elementów i mówi o jakości wykonania, nie o zakresie.
Częsty antywzorzec: analityk pisze do epika komplet kryteriów akceptacji na trzy strony, żeby "było dokładnie". Efekt jest odwrotny od zamierzonego. Powstaje dokument, który zestarzeje się przed pierwszym sprintem, bo połowa decyzji jeszcze nie zapadła, a druga połowa zmieni się po pierwszym demie.
Epik a poziomy wymagań z BABOK-a
Tu robi się ciekawie, bo dwa światy nazywają rzeczy inaczej, a analityk musi żyć w obu.
BABOK porządkuje wymagania na poziomy: biznesowe mówią, dlaczego organizacja potrzebuje zmiany; wymagania interesariuszy mówią, co musi być spełnione z ich punktu widzenia; wymagania rozwiązania mówią, jak rozwiązanie ma to zrealizować. To podział według rodzaju treści.
Backlog agile'owy dzieli inaczej, według wielkości kawałka pracy: epik, feature, historyjka. Te dwa podziały się nie pokrywają i nie da się ich zmapować jeden do jednego, choć wielu próbuje.
Na naszym forum wywiązała się kiedyś na ten temat porządna dyskusja. Analityk z ponad dwudziestoletnim stażem, który przez całą karierę pisał przypadki użycia zamiast historyjek, postawił tezę, że historyjka użytkownika nie jest wymaganiem rozwiązania, bo nie mówi, jak system ma działać, za to świetnie plasuje się na poziomie wymagań interesariuszy. Na poparcie przywołał opinię Jarosława Żelińskiego, że przekazywanie takiej historyjki wprost programiście jest ryzykowne, bo programista zaczyna się domyślać.
Nie musisz się z tym zgadzać, żeby wyciągnąć praktyczny wniosek. Brzmi on tak: epik i historyjka to jednostki organizacji pracy, a nie kompletny opis wymagania. Jeśli w twoim projekcie cała wiedza o systemie mieszka wyłącznie w opisach zgłoszeń, to za pół roku nikt nie odtworzy, dlaczego coś działa tak, a nie inaczej. Reguły biznesowe, decyzje i model domeny potrzebują miejsca poza backlogiem, choćby podlinkowanego ze zgłoszenia.
Kiedy epik jest zbędny
Nie w każdym projekcie epiki mają sens i warto to powiedzieć wprost, bo narzędzia sugerują inaczej.
Zbędne są, gdy produkt jest mały i backlog mieści się na jednym ekranie. Wtedy epik dokłada tylko klikanie. Zbędne są też w Kanbanie nastawionym na strumień drobnych zgłoszeń serwisowych, gdzie nie ma czego grupować w kwartalne cele.
Osobny przypadek to zespół, który dopiero uczy się ciąć pracę. Tam epiki bywają wymówką: duży pojemnik pozwala odkładać trudne rozmowy o zakresie, bo "przecież to jest w epiku". Lepiej najpierw nauczyć się pisać małe historyjki, potem dokładać piętra.
Czy "epik" pojawia się w ogłoszeniach o pracę
Sprawdziłem dzisiaj w bazie naszego job boardu. W dwustu sześćdziesięciu jeden aktywnych ofertach dla analityków, wliczając analityków danych, słowo "epik" ani "epic" nie pada ani razu w tytule, zajawce i wykrytych tagach wymagań. "Backlog" pojawia się w dwóch ofertach, "user stories" w dwóch, "Jira" w szesnastu. Bieżące agregaty z tych samych ogłoszeń, w tym sekcję "Czego wymagają pracodawcy", pokazujemy publicznie na Barometrze rynku pracy BA.
Zastrzeżenie do tej liczby: przechowujemy podgląd oferty, nie jej pełną treść, więc liczę wystąpienia w tytule, zajawce i tagach, a nie w całym ogłoszeniu. Wniosek zostaje jednak czytelny. Rekruterzy nie wpisują nazw jednostek backlogu do wymagań. Wpisują narzędzie, w którym te jednostki żyją.
Praktycznie: do CV nie wpisuj "znajomość epików". Wpisz, co potrafisz z nimi zrobić, na przykład że rozbiłeś epik na historyjki i zaplanowałeś kolejność wydań.
Najczęstsze pytania o epiki
Kto tworzy epiki, analityk czy product owner? Formalnie za backlog odpowiada product owner i to on decyduje o zawartości i kolejności. W praktyce, zwłaszcza w złożonych domenach, najwięcej pracy nad opisem i rozbiciem wykonuje analityk. Granicę ról rozbieramy we wpisie analityk kontra product owner.
Czy epik może trwać dłużej niż kwartał? Może, ale to sygnał ostrzegawczy. Epik ciągnący się rok zwykle nie jest epikiem, tylko nazwą modułu. Rozważ podział na kilka mniejszych z osobnymi celami.
Czy epik ma estymatę? Zwykle nie na starcie i to jest w porządku. Jeśli potrzebujesz liczby do rozmowy o budżecie, podaj przedział albo licz sumę z historyjek, które już są rozpisane, jasno zaznaczając, ile procent epiku pokrywają.
Czy epik może zawierać błędy i dług techniczny? Tak, jeśli dotyczą tego samego obszaru. Backlog produktu mieści historyjki, błędy, dług techniczny i spike'y, a epik jest tylko sposobem ich pogrupowania.
Jak priorytetyzować epiki między sobą? Tak samo jak resztę backlogu, tylko na grubszym poziomie. MoSCoW sprawdza się przy ustalaniu zakresu wydania z interesariuszami, WSJF przy kolejności wewnątrz tego, co i tak trzeba zrobić. Obie techniki zestawiamy we wpisie o priorytetyzacji wymagań.
Czy epik to to samo co inicjatywa albo temat? Zależy od narzędzia i firmy. Niektóre konfiguracje dokładają nad epikiem jeszcze jedno piętro i nazywają je inicjatywą. To nie jest standard, tylko lokalna konwencja, więc przy wejściu do projektu zapytaj, ile pięter tu obowiązuje i jak się nazywają.
Sprawdź, czy umiesz to zastosować
Wiedza o epikach jest tania. Sprawdza się dopiero na konkretnym backlogu, kiedy trzeba zdecydować, czy coś ciąć, czy zostawić. Najbliżej tego stoi u nas test wiedzy o historyjkach użytkownika i kryteriach akceptacji - piętnaście pytań o to, co odróżnia dobrze pociętą pracę od źle pociętej. Rozwiążesz go bez zakładania konta.
Jeśli chcesz, żeby wynik gdzieś został i żeby dało się wrócić do błędnych odpowiedzi, ten sam test masz na platformie po założeniu darmowego konta - konto bez subskrypcji ma trzy podejścia do testów w miesiącu.
Gdzie iść dalej
- Historyjka użytkownika - jednostka, na którą tniesz epik
- Feature - poziom pomiędzy epikiem a historyjką, gdy pod epikiem robi się tłoczno
- INVEST - sześć testów, które przechodzi dobrze pocięta historyjka
- Backlog refinement - moment, w którym epiki się tnie
- Backlog produktu - miejsce, w którym epiki żyją
- Kryteria akceptacji - co dopisujesz do historyjki, nie do epiku
- SAFe - framework, w którym epik ma formalną definicję
- Jira - narzędzie, w którym epik to typ zgłoszenia
- Jak pisać dobre historyjki użytkownika - format, przykłady i katalog wzorców cięcia
- Jak prowadzić backlog - porządek, refinement i priorytety w praktyce
Hierarchia epik, feature i historyjka oraz przykład EduNest pochodzą z naszego kursu wprowadzającego do analizy biznesowej. Przykłady MediFlow to nasz przewijający się przez materiały case systemu rejestracji dla sieci przychodni. Brak słowa "epic" w Scrum Guide sprawdzony w wydaniu z listopada 2020, odczyt 17 sierpnia 2026. Liczby z job boardu policzone 17 sierpnia 2026 na dwustu sześćdziesięciu jeden aktywnych ofertach.