„W Scrumie nie ma roli analityka biznesowego" - usłyszałem to zdanie od Scrum Mastera na pierwszym dniu projektu w MediFlow, sieci 12 przychodni budującej system rejestracji online. Miał rację co do litery: Scrum Guide faktycznie nie zna słowa „analityk". Ale mylił się co do sensu. Trzy sprinty później to właśnie analityk biznesowy uratował zespół, gdy okazało się, że „prosta" rezerwacja wizyty kryje 40 reguł biznesowych dotyczących refundacji NFZ, których nikt wcześniej nie spisał. Product Owner ich nie znał. Deweloperzy zgadywali. Analityk usiadł z rejestratorkami i przez tydzień wyciągnął każdą z nich.
Scrum nie definiuje roli analityka, bo Scrum to celowo minimalistyczny framework - opisuje tylko to, co absolutnie niezbędne. Reszta, w tym analiza biznesowa, to umiejętności, które zespół musi posiadać, niezależnie od tego, kto ma je na wizytówce. W tym artykule pokażę Ci, jak Scrum wygląda od środka według aktualnego Scrum Guide 2020, gdzie dokładnie wpasowuje się praca analityka i jakich pułapek unikać, gdy przechodzisz z waterfalla do zwinności.
Scrum Guide 2020: co się zmieniło i dlaczego to ważne
Wersja przewodnika z 2020 roku przyniosła kilka zmian, które bezpośrednio dotyczą analityka. Najważniejsza: twórcy odeszli od słowa „rola" na rzecz odpowiedzialności (accountabilities). To nie kosmetyka. „Rola" sugeruje etat i stanowisko. „Odpowiedzialność" mówi: oto za co dana część zespołu odpowiada - a kto fizycznie wykonuje pracę, to już sprawa zespołu.
Druga zmiana: zniknął podział na „zespół deweloperski" jako byt odrębny od reszty. Teraz mamy jeden Scrum Team, w którym są deweloperzy, Product Owner i Scrum Master - bez wewnętrznych podzespołów i hierarchii. Trzecia: do każdego artefaktu dopisano zobowiązanie (commitment), które nadaje mu kierunek. O tym za chwilę.
Dla analityka najważniejszy wniosek brzmi: skoro Scrum mówi o odpowiedzialnościach, a nie etatach, to analiza biznesowa jest pracą, którą ktoś w zespole musi wykonać - najczęściej osoba z kompetencjami BA, czasem Product Owner, czasem deweloper. Pytanie nie brzmi „czy jest miejsce dla analityka", tylko „kto u nas robi analizę".
Trzy odpowiedzialności w Scrum Team - i gdzie jest analityk
Product Owner - odpowiada za wartość
PO maksymalizuje wartość produktu i jest jedyną osobą odpowiedzialną za Product Backlog: jego zawartość, kolejność i przejrzystość. To on decyduje, co i w jakiej kolejności zespół buduje. W praktyce, zwłaszcza w większych organizacjach, jeden PO nie jest w stanie sam zgłębić każdej reguły biznesowej - i tu analityk staje się jego prawą ręką.
Developerzy - odpowiadają za inkrement
Developerzy (w rozumieniu Scruma - wszyscy, którzy tworzą produkt, niezależnie od specjalizacji) odpowiadają za stworzenie użytecznego inkrementu w każdym sprincie oraz za jakość poprzez przestrzeganie Definition of Done. Co istotne: analityk biznesowy w zespole scrumowym jest formalnie „developerem" w tym sensie - częścią zespołu tworzącego produkt, nie zewnętrznym dostawcą dokumentów.
Scrum Master - odpowiada za skuteczność
SM dba o to, by Scrum był rozumiany i stosowany, usuwa przeszkody i chroni zespół przed zakłóceniami. To rola służebna, nie kierownicza.
Gdzie w tym wszystkim jest analiza biznesowa? Rozlewa się po dwóch odpowiedzialnościach: wspiera Product Ownera w zarządzaniu backlogiem (badanie potrzeb, rozpisywanie historyjek, doprecyzowanie reguł) oraz działa jako developer, odpowiadając na pytania zespołu w trakcie sprintu i modelując procesy. Jak rozróżnić, gdzie kończy się BA, a zaczyna PO, opisuję szczegółowo w artykule analityk biznesowy vs Product Owner.
Pięć wydarzeń Scruma okiem analityka
Scrum ma jeden kontener - Sprint (zwykle 1-4 tygodnie) - i wewnątrz niego cztery wydarzenia. Dla każdego pokażę, co realnie robi analityk.
| Wydarzenie | Cel | Co robi analityk |
|---|---|---|
| Sprint Planning | Ustalenie celu sprintu i wyboru pozycji backlogu | Wyjaśnia szczegóły wybranych historyjek, doprecyzowuje kryteria akceptacji, sygnalizuje ukryte zależności i reguły biznesowe |
| Daily Scrum | 15-min synchronizacja developerów na kolejne 24h | Słucha, wyłapuje blokery wymagań, deklaruje dostępność na dopytanie - nie raportuje, lecz wspiera |
| Sprint Review | Inspekcja inkrementu z interesariuszami, dostrojenie backlogu | Zbiera feedback od użytkowników, tłumaczy reakcje biznesu na język zmian w backlogu |
| Sprint Retrospective | Inspekcja procesu, ustalenie usprawnień | Wnosi obserwacje o jakości wymagań - czy historyjki były wystarczająco jasne, gdzie powstawały nieporozumienia |
Uwaga, którą często gubią początkujący: Backlog Refinement (doprecyzowanie backlogu) nie jest piątym wydarzeniem. To ciągła aktywność, nie zaplanowane spotkanie w przewodniku. Scrum Guide wymienia ją jako bieżącą pracę nad backlogiem - i to właśnie tam analityk spędza najwięcej czasu. Jak prowadzić tę aktywność dobrze, rozpisuję w artykule o prowadzeniu backlogu.
Trzy artefakty i ich zobowiązania
To najbardziej niedoceniana część Scrum Guide 2020. Każdy z trzech artefaktów dostał przypisane zobowiązanie - element, który nadaje mu sens i pozwala mierzyć postęp.
- Product Backlog → Cel Produktu (Product Goal). Backlog to uporządkowana, ewoluująca lista wszystkiego, co może być potrzebne w produkcie. Jego zobowiązaniem jest długoterminowy cel, do którego zespół zmierza. Analityk pomaga rozbijać ten cel na konkretne, zrozumiałe pozycje.
- Sprint Backlog → Cel Sprintu (Sprint Goal). To plan na jeden sprint: wybrane pozycje plus sposób ich dostarczenia. Zobowiązaniem jest jeden spójny cel sprintu, który daje zespołowi fokus.
- Increment → Definicja Ukończenia (Definition of Done). Inkrement to działający, użyteczny kawałek produktu. Jego zobowiązaniem jest DoD - wspólny standard jakości, który mówi, kiedy praca jest naprawdę skończona. I tu uwaga dla analityka: wymagania niefunkcjonalne (wydajność, bezpieczeństwo, dostępność) najczęściej żyją właśnie w DoD.
Jak prowadzić analizę w Scrumie - źle vs dobrze
Największa pułapka osób przechodzących z waterfalla: traktowanie analizy jak osobnej fazy, która musi się skończyć, zanim zacznie się kodowanie. W Scrumie analiza jest iteracyjna i ciągła - robisz jej tyle, ile potrzeba na najbliższe 1-2 sprinty, nie więcej.
User story: źle → dobrze → jeszcze lepiej
Źle (specyfikacja waterfallowa): „System musi umożliwiać import danych pacjentów z pliku CSV zgodnie ze specyfikacją X w rozdziale 7.4."
Dobrze (user story): „Jako rejestratorka chcę zaimportować listę pacjentów z pliku CSV, aby nie wprowadzać ich ręcznie po jednym."
Jeszcze lepiej (story + kryteria akceptacji): ta sama historyjka plus: system akceptuje plik w formacie zgodnym z szablonem; przy błędnym formacie wyświetla, który wiersz jest wadliwy; import 500 rekordów trwa ≤ 10 s; każdy import zapisuje się w dzienniku audytowym.
Różnica jest fundamentalna: wersja waterfallowa odsyła do dokumentu, którego nikt nie otworzy. Wersja zwinna mówi kto, czego i po co potrzebuje, a kryteria akceptacji dają testowalną poprzeczkę. Jak pisać dobre historyjki, rozwijam w artykule o pisaniu user stories, a o samych kryteriach - w tekście o kryteriach akceptacji.
Mini-case MediFlow: jeden sprint z życia analityka
Sprint 4, dwutygodniowy. Cel sprintu: „Pacjent może zarezerwować wizytę refundowaną przez NFZ". Brzmi jak jedna historyjka - w rzeczywistości to gniazdo reguł.
- Refinement (na bieżąco w sprincie 3): analityk siada z rejestratorkami i kierownikiem ds. rozliczeń NFZ. Wyciąga reguły: skierowanie wymagane dla specjalisty, ale nie dla POZ; limit wizyt na kwartał; weryfikacja uprawnień w systemie eWUŚ. Rozbija „jedną" historyjkę na pięć mniejszych.
- Sprint Planning: zespół wybiera trzy z pięciu historyjek (reszta nie zmieści się w sprincie). Analityk wyjaśnia kryteria akceptacji, deweloperzy wyceniają, ujawnia się zależność od zewnętrznego API eWUŚ - Scrum Master notuje jako blokera do usunięcia.
- Daily Scrum: trzeciego dnia deweloper pyta, co zrobić, gdy eWUŚ nie odpowiada. Analityk dopytuje biznes i wraca z regułą: „przy braku odpowiedzi pozwól zarezerwować, oznacz wizytę jako wymagającą weryfikacji". To NFR niezawodnościowy ubrany w regułę biznesową.
- Sprint Review: kierownik rozliczeń testuje rezerwację na żywo, wyłapuje, że brakuje obsługi pacjenta bez numeru PESEL (obcokrajowca). Trafia to do backlogu jako nowa pozycja.
- Retrospective: zespół zauważa, że historyjki NFZ były zbyt grube na wejściu. Wniosek: analityk będzie rozbijał reguły regulacyjne wcześniej, jeszcze przed planningiem.
Zauważ, że analityk nie zniknął tylko dlatego, że Scrum Guide go nie wymienia. Był obecny w każdym wydarzeniu - nie jako autor 80-stronicowej specyfikacji, lecz jako żywy interfejs między biznesem a zespołem.
Częste pułapki analityka w Scrumie
- Analiza „na zapas". Rozpisywanie szczegółowych wymagań na pół roku do przodu. W Scrumie wymagania ewoluują - to, co dopracujesz dziś, za trzy miesiące będzie nieaktualne. Doprecyzowuj tylko najbliższe sprinty.
- Wcielanie się w „proxy Product Ownera". Gdy PO jest niedostępny, analityk kusi się, by przejąć decyzje o priorytetach. To prosta droga do rozmycia odpowiedzialności. Wspieraj PO informacją, ale nie podejmuj decyzji o wartości za niego.
- Dokumentowanie zamiast rozmowy. Scrum stawia na „działające oprogramowanie ponad obszerną dokumentację". To nie znaczy „zero dokumentacji" - znaczy „tyle, ile naprawdę potrzeba". Diagram procesu na tablicy często bije 10 stron tekstu.
- Brak udziału w Review i Retro. Analityk, który znika po przekazaniu historyjek, traci najcenniejsze źródło feedbacku. To na Review widać, czy wymagania trafiły w potrzebę. Co konkretnie analityk może na to spotkanie wnieść i z niego wynieść, opisuję w tekście o tym, co analityk wynosi z retrospektywy.
- Traktowanie Refinement jak formalnego spotkania. To ciągła aktywność. Najlepsi analitycy doprecyzowują backlog w krótkich, częstych sesjach, a nie raz na dwa tygodnie przez trzy godziny.
FAQ - Scrum dla analityka
Czy Scrum Guide 2020 przewiduje rolę analityka biznesowego?
Nie wprost. Scrum definiuje tylko trzy odpowiedzialności: Product Owner, Developerzy, Scrum Master. Analiza biznesowa to umiejętność, którą zespół musi posiadać - najczęściej wnosi ją osoba z kompetencjami BA, formalnie działająca jako „developer" w rozumieniu Scruma.
Czym jest „commitment" przy artefakcie w Scrum Guide 2020?
To element nadający artefaktowi kierunek i mierzalność: Product Goal dla Product Backlogu, Sprint Goal dla Sprint Backlogu, Definition of Done dla Inkrementu. Zobowiązania dodano w wersji 2020, by wzmocnić fokus i przejrzystość.
Ile jest wydarzeń w Scrumie?
Pięć: Sprint (kontener) oraz Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective wewnątrz niego. Backlog Refinement to ciągła aktywność, nie osobne wydarzenie.
Kto pisze user stories w Scrumie - PO czy analityk?
Formalnie odpowiada PO (właściciel backlogu), ale w praktyce historyjki często rozpisuje analityk, a PO zatwierdza i priorytetyzuje. To typowa synergia: analityk dostarcza głębię analizy, PO podejmuje decyzję o kolejności.
Czy w Scrumie potrzebna jest dokumentacja wymagań?
Tyle, ile naprawdę potrzeba. Scrum nie zakazuje dokumentacji - zakazuje dokumentacji dla samej dokumentacji. User stories z kryteriami akceptacji, diagramy procesów i rejestr reguł biznesowych zwykle wystarczają. Pełny SRS jest częściej domeną projektów waterfallowych.
Podsumowanie
Scrum nie usunął analityka - usunął etat analityka jako bytu odrębnego od zespołu. To dobra zmiana. Zamiast pisać specyfikację, którą deweloperzy odczytają trzy miesiące później, analityk staje się żywym mostem: doprecyzowuje backlog, wyjaśnia reguły w trakcie sprintu, zbiera feedback na Review i wnosi obserwacje na Retro.
Jeśli przechodzisz z waterfalla, zapamiętaj jedno: w Scrumie nie chodzi o to, żeby zrobić analizę szybciej. Chodzi o to, żeby robić jej tyle, ile trzeba, dokładnie wtedy, kiedy jest potrzebna. To zmiana nawyku, nie tylko procesu.
Chcesz zrozumieć, jak Scrum różni się od podejścia kaskadowego i co to znaczy dla Twojej codziennej pracy? Zacznij od artykułu Agile vs Waterfall - rola analityka, a potem przećwicz pisanie historyjek na realnych przykładach w testach na platformie Analify.