Przepływy pracy Agile: integracja Scruma i Kanbana

Scrum i Kanban nadal działają, gdy większość kodu piszą agenci, ale wąskie gardło przesuwa się z pisania na specyfikowanie i weryfikację. Refinement zamienia historyjki w kryteria akceptacji, względem których da się sprawdzić agenta, planowanie sprintu budżetuje przepustowość review zamiast godzin implementacji, limit WIP w Kanbanie obejmuje review dowodów, a przegląd sprintu powstaje ze zmergowanych pull requestów.

Ta strona jest dla tech leada lub Scrum Mastera, który prowadzi ceremonie, oraz dla programistów w zespole. Typowa sytuacja: zespół dwa sprinty temu wdrożył Claude Code, Codex albo Cursor. Implementacja kończy się teraz w środę, a mimo to burndown się wypłaszcza, bo dziewięć pull requestów czeka na review, dwie historyjki wróciły jako „zrobione, ale nie o to chodziło”, a przegląd sprintu to przewijanie logu merge’ów.

Co zyskasz, prowadząc Scrum i Kanban z agentami

• Mapę ceremonia po ceremonii: co przygotowuje agent, o czym decydują ludzie i jaki dowód zamyka każdy krok.
• Podłączenie Lineara i Jiry w Claude Code, Codex i Cursorze, z komendami sprawdzonymi na zainstalowanych CLI.
• Pięć gotowych promptów: doprecyzowanie historyjki, sprawdzenie pojemności sprintu, zamiana karty w plan, szkic przeglądu sprintu i dane o przepływie na retrospektywę.
• Definition of Done do przyjęcia bez zmian, dzięki której historyjkę odbiera się na podstawie dowodów, a nie czytania diffu.
• Typowe awarie Agile z agentami i sposób wyjścia z każdej z nich.

Co zmienia się w każdej ceremonii Scruma i Kanbana?

Ceremonie zostają. Zmienia się zasób, którego brakuje: gdy agent implementuje historyjkę w godzinę, ograniczeniem staje się to, jak szybko zespół potrafi precyzyjnie powiedzieć, czego chce, i udowodnić, że to dostał. Model AI Capabilities od DORA wymienia „working in small batches” jako jedną z siedmiu zdolności (Kevin M. Storer i Derek DeBellis, blog Google Cloud, 2025-09-23); jak ujmują to Nathen Harvey i Allison Park: „AI can easily generate massive blocks of code, which are hard to review and test” (blog Google Cloud, 2025-12-10).

Ceremonia lub krok przepływu	Agent przygotowuje	Ludzie decydują	Dowód, który ją zamyka
Refinement backlogu	Kryteria akceptacji, wycinki, otwarte pytania	Zakres, priorytet, które pytania blokują „ready”	Każde kryterium wskazuje sprawdzenie, które je potwierdza
Planowanie sprintu	Sprawdzenie pojemności, kolejność zależności	Cel sprintu i zobowiązanie	Godziny review mieszczą się w przepustowości review zespołu
Codzienna praca (przepływ Kanban)	Implementacja, testy, komentarze na tablicy	Kto co przegląda, kiedy zatrzymać przebieg	Zielone CI i pakiet dowodów dołączony do PR-a
Przegląd sprintu	Changelog i scenariusz demo ze zmergowanych PR-ów	Co pokazać, co odbiera product owner	Testy akceptacyjne przechodzą na gałęzi release
Retrospektywa	Dane o cycle time i zwrotach w każdym torze	Co zmienić w następnym sprincie	Liczba, nie wrażenie

To, które zgłoszenia agent w ogóle może wziąć i pod jakim nadzorem, jest osobną decyzją, opisaną w artykule jak przygotować backlog dla agentów. Ta strona zakłada, że taki triaż już istnieje, i skupia się na ceremoniach wokół niego.

Podłącz tablicę do agenta

Każdy prompt poniżej działa z wklejoną treścią zgłoszenia. Podłączenie trackera przez MCP usuwa kopiowanie i pozwala agentowi samodzielnie czytać powiązane zgłoszenia i dodawać komentarze. Linear i Atlassian udostępniają oficjalne zdalne serwery MCP po HTTP z OAuth: nie ma pakietu npm do instalacji, a adresy serwerów są takie same w każdym narzędziu. Atlassian zaleca https://mcp.atlassian.com/v2/mcp dla nowych konfiguracji; stary endpoint /v1/sse przestał być wspierany po 30 czerwca 2026.

Claude Code

# Terminal, from the repository root (Claude Code 2.1.283)
claude mcp add --transport http linear https://mcp.linear.app/mcp
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Potem uruchom /mcp w sesji, żeby dokończyć logowanie OAuth. Domyślny zakres to local (ten projekt, tylko ty); dodaj --scope project, żeby udostępnić wpis zespołowi przez .mcp.json. Atlassian jest też dostępny jako plugin z gotowymi skillami, np. spec-to-backlog: claude plugin install atlassian@claude-plugins-official.

Codex

# Terminal (Codex CLI 0.157.1)
codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear
codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp
codex mcp login atlassian

Codex ma też natywną integrację z Linearem: możesz przypisać zgłoszenie do Codeksa albo wspomnieć @Codex w Linearze (sprawdzone 2026-10-12). Jego kuratorowany plugin atlassian-rovo wciąż wskazuje starszy endpoint /v1/mcp/authv2 (odczyt 2026-09-26), więc wybierz bezpośrednią linię z v2 powyżej.

Cursor

Dodaj oba serwery pod mcpServers w .cursor/mcp.json i zaloguj się, gdy Cursor o to poprosi:

{
  "mcpServers": {
    "linear": { "url": "https://mcp.linear.app/mcp" },
    "atlassian": { "url": "https://mcp.atlassian.com/v2/mcp" }
  }
}

Marketplace Cursora ma również plugin Atlassian. Zakresy dla każdego serwera i pełne listy narzędzi znajdziesz w artykułach integracja MCP z Jirą i Linearem oraz Atlassian MCP.

Doprecyzuj historyjki tak, żeby dało się sprawdzić agenta

Refinement decyduje o tym, czy Agile z agentami się uda. Historyjka, którą programista zinterpretowałby rozsądnie, nie wystarcza: agent wybierze jedną interpretację i sprawi, że przejdzie każde sprawdzenie, które widzi. Wynikiem refinementu są więc kryteria akceptacji, z których każde odpowiada jakiemuś sprawdzeniu, wycinki na tyle małe, że każdy da się udowodnić jednym sprawdzeniem, oraz lista pytań, na które odpowie tylko człowiek. Uruchom ten prompt przed spotkaniem, a nie w jego trakcie, żeby spotkanie poświęcić pytaniom.

Gotowy prompt: doprecyzuj historyjkę przed spotkaniem

Read Linear issue ENG-1423 and every issue linked to it. Then read
src/lib/auth/ and app/(auth)/ in this repository. Do not edit anything
and do not write to Linear.

Produce, as Markdown I can paste into the issue:
1. Acceptance criteria as Given/When/Then. For each criterion, name the
   test file or check that would prove it, or write "NO CHECK POSSIBLE"
   and say why.
2. Slices: at most 5, each shippable on its own and provable by one of
   the criteria above. Merge any slice under two hours of work.
3. Open questions a product owner must answer before this is ready.
   Mark each as BLOCKING or NOT BLOCKING.
4. Risk flags: anything touching auth, payments, a schema migration, or
   an external API contract.

Najważniejsze są dwa wyniki. Kryterium oznaczone „NO CHECK POSSIBLE” znaczy, że historyjka nie jest gotowa dla agenta, niezależnie od jej rozmiaru. Pytanie BLOCKING trafia do product ownera, a nie do najlepszego domysłu agenta. Jak zamienić kryteria w czerwone testy, których agent nie może edytować, opisuje artykuł wykonywalne kryteria akceptacji; szerszą dyscyplinę specyfikacji omawia spec-driven development.

Planuj sprint pod przepustowość review, nie szybkość pisania

Story pointy mierzyły, ile czasu człowiek potrzebuje na napisanie kodu. Z agentami kosztem, który nadal rośnie wraz z historyjką, jest jej wyspecyfikowanie i weryfikacja wyniku. Planuj względem tego.

1. Zmierz przepustowość review. Weź dwa ostatnie sprinty i policz, ile pull requestów od agentów każdy recenzent zatwierdzał dziennie. Ta liczba razy liczba dni recenzentów w sprincie to twoja przepustowość review.

2. Szacuj weryfikację, nie implementację. Dla każdego wycinka oszacuj czas, jakiego człowiek potrzebuje, żeby sprawdzić dowody, przejść ścieżkę demo i zatwierdzić. Wycinek z mocnymi automatycznymi sprawdzeniami kosztuje minuty; taki, przy którym człowiek musi przeklikać trzy ekrany, kosztuje godzinę.

3. Zobowiąż się do tego, co się mieści. Dobieraj wycinki do sprintu, aż oszacowanie weryfikacji osiągnie około 80 procent przepustowości review. Pozostałe 20 procent pochłania poprawki i przebiegi odrzucone w review; dostrój tę wartość na podstawie danych z własnych retrospektyw.

4. Ustaw kolejność według zależności. Wycinki, które zmieniają wspólny kontrakt (schemat API, tabelę w bazie), idą pierwsze, żeby kolejne budowały na zmergowanym kodzie, a nie na gałęziach innych wycinków.

Gotowy prompt: sprawdź sprint względem przepustowości review

Read every issue in the Linear cycle "Sprint 24" for team ENG.
Do not write to Linear.

Our review capacity this sprint is 45 agent pull requests (3 reviewers,
9 days, about 5 approvals per day across the team).

For each issue, list: its slices, the number of pull requests it will
likely produce, and whether each slice's acceptance criteria name an
automated check. Then:
- Total the expected pull requests and compare with the capacity.
- List the issues to drop or defer first if we are over, starting with
  those whose criteria have no automated check.
- Show dependency order: which issues change a shared schema or API
  contract and must merge before others.
Output one table and a short recommendation. No estimates in story points.

Prompt celowo prosi o liczbę pull requestów zamiast story pointów. Agent, który wymyśla story pointy, zakotwicza zespół na liczbie bez żadnych podstaw; liczbę jednostek do review może natomiast wyprowadzić z wycinków.

Prowadź przepływ Kanban z limitem WIP na review dowodów

Na tablicy Kanban agent sprawia, że „W toku” mija szybko, a kolumna za nią się zapycha. Pokaż to wprost:

• Podziel „W toku” na Agent pracuje (Agent running) i Review dowodów (Evidence review). Pierwsza kolumna śledzi przebiegi, druga pull requesty, które człowiek musi zatwierdzić.
• Ustaw limit WIP na Review dowodów, a nie na „W toku”. Gdy kolumna jest pełna, nikt nie uruchamia nowego przebiegu; wszyscy robią review.
• Dodaj kolumnę Wymaga doprecyzowania (Needs clarification) przed „Gotowe do pracy”. Przebieg, który zatrzymał się na pytaniu lub brakującym sprawdzeniu, trafia tam, a nie z powrotem do „W toku”.

Raport Faros AI „AI Productivity Paradox” (2025) — według streszczenia na blogu samego Faros AI (faros.ai, 2025; odczytanego z wyciągu wyszukiwarki, nie z raportu) — podaje, że programiści w zespołach intensywnie korzystających z AI mergowali około 98 procent więcej pull requestów, a czas review pull requestów wzrósł o około 91 procent. To właśnie tę kolejkę chroni limit WIP.

Gdy mimo to cienka karta trafi do „Gotowe do pracy”, przepuść ją przez agenta, zanim ją weźmiesz:

Gotowy prompt: zamień cienką kartę Kanban w plan

Read Jira issue SHOP-311 ("Implement social login"). Our stack:
Next.js App Router with Auth.js already wired for email and password in
lib/auth/. We want Google and GitHub providers. Read lib/auth/ first.
Do not write to Jira yet.

Draft, as Markdown for the card:
- A two-sentence scope statement: what is in, what is out.
- A checklist of at most 8 items (provider config, callback routes,
  account linking, UI buttons, environment variables, tests).
- Acceptance criteria as Given/When/Then, each naming its test.
- Open questions, for example whether a Google login links to an
  existing email account.
Show me the draft. After I reply "apply", add it to SHOP-311 as a
comment and change nothing else on the issue.

Ostatnie dwie linie to wzorzec dla każdego zapisu na tablicy: agent przygotowuje szkic, człowiek odpowiada „apply”, a zapis dotyczy jednego, nazwanego zgłoszenia.

Kto aktualizuje tablicę: automatyzacja w Claude Code, Codex i Cursorze

Połączenie MCP ma ten sam kształt we wszystkich trzech narzędziach. Różni się to, kto aktualizuje tablicę po zakończeniu przebiegu i co ten przebieg uruchamia.

Claude Code

Od v2.1.283 (oba kanały wydań w dniu 2026-10-12) sesje interaktywne startują w trybie auto, chyba że model lub ustawienia wymuszają tryb Manual, więc sesje z tablicą uruchamiaj z --permission-mode manual: wtedy każde wywołanie MCP spoza reguł allow najpierw pyta o zgodę. Narzędzia odczytu Lineara i Atlassiana możesz dodać do reguł allow, ale narzędzia zapisu trzymaj poza nimi. Do pracy cyklicznej Routines (/schedule, research preview) mogą uruchamiać prompt na koniec sprintu jako sesję w chmurze; zobacz Routines w Claude Code. Skryptowy wzorzec, który nie potrzebuje żadnych poświadczeń do tablicy, to szkic w trybie -p i publikacja wyniku przez człowieka, jak w komendzie do przeglądu sprintu poniżej.

Codex

Natywna integracja z Linearem pozwala zespołowi przypisać zgłoszenie do Codeksa albo wspomnieć w nim @Codex (sprawdzone 2026-10-12). Przypisuj mu tylko zgłoszenia, które triaż oznaczył do pracy w tle, nigdy całej skrzynki. Konfigurację i ograniczenia opisuje artykuł Codex w Slacku i Linearze.

Cursor

Automations mogą uruchamiać Cloud Agents na zdarzenia z Lineara, a także według harmonogramu (sprawdzone 2026-08-28). Wyzwalacz z filtrem na status „Ready for agent” zamienia kolumnę tablicy w przełącznik uruchamiania, a automatyzacja zaplanowana na koniec sprintu to naturalny punkt zaczepienia dla szkicu przeglądu sprintu. Zobacz Cloud Agents i Automations w Cursorze.

Pełną automatyzację od zgłoszenia do pull requesta, łącznie z uprawnieniami, których potrzebuje przebieg bez nadzoru, opisuje pipeline od zgłoszenia do PR-a.

Przygotuj przegląd sprintu ze zmergowanych pull requestów

Najpierw zapisz zmergowane w sprincie pull requesty do pliku, a potem daj agentowi dostęp tylko do odczytu tego pliku. Agent nie potrzebuje wtedy tokena ani dostępu do sieci, a wejściem jest dokładnie to, co zostało wydane.

# Terminal, from the repository root, with the GitHub CLI signed in
gh pr list --state merged --search "merged:2026-09-14..2026-09-25" \
  --limit 200 --json number,title,body,labels,url > sprint-24-prs.json

Claude Code

# -p sessions do not start in auto mode; only Read is allowed here
claude -p "$(cat sprint-review-prompt.txt)" \
  --allowedTools "Read" --output-format text > sprint-24-review.md

Codex

# read-only sandbox; the final message is written to the file
codex exec -s read-only -o sprint-24-review.md "$(cat sprint-review-prompt.txt)"

Cursor

Wklej poniższy prompt do agenta z dołączonym sprint-24-prs.json albo uruchom go z automatyzacji uruchamianej według harmonogramu lub zdarzeniem z Lineara.

Zapisz ten prompt jako sprint-review-prompt.txt:

Gotowy prompt: changelog i scenariusz demo na przegląd sprintu

Read sprint-24-prs.json. It lists every pull request merged in Sprint 24.
Use only what is in that file.

Produce:
1. A changelog grouped as Added / Changed / Fixed, written for a product
   owner who does not read code. One line per user-visible change; cite
   the pull request number on each line.
2. A demo script of at most 8 steps covering the sprint goal's happy path
   and one failure path.
3. A "Before release" list: any pull request whose body mentions a
   migration, a new environment variable, or a feature flag.
4. A "Missing evidence" list: any pull request whose body has no test
   results or acceptance-criteria checklist.
Do not invent changes that are not in the file.

Na spotkaniu najbardziej przydaje się lista „Missing evidence”: pokazuje product ownerowi, które historyjki zmergowano bez dowodów, jakich wymaga Definition of Done.

Przynieś dane o przepływie na retrospektywę

Retrospektywa pozostaje rozmową ludzi, ale powinna zaczynać się od liczb. Poproś agenta, żeby wyliczył je z tablicy, a nie z pamięci.

Gotowy prompt: dane o przepływie na retrospektywę

Read every issue completed in the Linear cycle "Sprint 24" for team ENG,
with its status history. Do not write to Linear. If the tool cannot
return status history, say so and stop instead of estimating.

Compute, and show as one table per question:
1. Cycle time (In progress to Done) per issue, and the median for issues
   labelled lane:background versus lane:interactive.
2. Time each issue spent in "Evidence review".
3. Bounces: issues that moved back from "Evidence review" or "Done" to an
   earlier column, with the comment that explains why, if any.
4. Issues that entered "Needs clarification", and what question stopped
   them.
End with the three issues that waited longest in review, and nothing
else. No recommendations; the team will discuss them.

Etykiety lane:background i lane:interactive pochodzą z triażu opisanego w artykule jak przygotować backlog dla agentów; zastąp je własnymi, a nazwy kolumn w prompcie nazwami ze swojej tablicy. Definicje metryk, które sprawdzają się między sprintami, znajdziesz w artykule metryki cyklu życia.

Skąd wiesz, że praca agentów w sprincie jest poprawna?

Nikt w zespole nie czyta każdej linii napisanej przez agentów, więc odbiór opiera się na dowodach, które produkują maszyny, a sprawdza konkretna osoba. Przyjmij tę Definition of Done dla każdej historyjki zaimplementowanej przez agenta:

• Każde kryterium akceptacji odpowiada nazwanemu testowi, a testy napisano i zatwierdzono przed implementacją. Leżą w ścieżkach, których przebieg implementujący nie może edytować (ochrona wyroczni).
• CI jest zielone: sprawdzenie typów, lint, testy jednostkowe i akceptacyjne na commicie merge.
• Pull request zawiera pakiet dowodów: listę kryteriów z wynikiem przy każdej pozycji, wynik testów oraz zrzut ekranu lub nagranie dla wszystkiego, co widzi użytkownik.
• Uruchomiono agenta do review, a człowiek przejrzał jego ustalenia i dowody. Zmiany w uwierzytelnianiu, płatnościach, migracjach lub publicznych kontraktach API przechodzą eskalację do czytania kodu przez człowieka (dowody zamiast diffów).
• Product owner odbiera historyjkę na przeglądzie sprintu na podstawie testów akceptacyjnych przechodzących na gałęzi release, a nie samego demo.

Odpowiedzialność jest podzielona. Programista, który jest właścicielem zgłoszenia, zatwierdza dowody i merguje. Product owner odbiera przyrost. Tech lead jest właścicielem limitu WIP i decyduje, kiedy klasa zadań przechodzi między torami.

Co się psuje, gdy agenci dołączają do zespołu scrumowego lub kanbanowego?

Typowe awarie i jak z nich wyjść

• Review staje się ukrytą kolejką sprintu. Implementacja kończy się wcześnie, a burndown stoi. Naprawa: przenieś limit WIP na Review dowodów i nie uruchamiaj nowych przebiegów, dopóki kolumna jest pełna; następny sprint zaplanuj pod zmierzoną przepustowość review.
• Estymaty agenta stają się kotwicą zespołu. Story pointy wymyślone przez agenta kształtują dyskusję na planowaniu. Naprawa: nigdy nie proś agenta o punkty; proś o wycinki i liczbę pull requestów, a nakład weryfikacji niech oszacuje zespół.
• Nadmierne rozbijanie. Historyjka wraca jako 14 podzadań, z których połowa to „utwórz plik”. Naprawa: ogranicz liczbę wycinków w prompcie (prompty powyżej używają 5 i 8) i wymagaj, żeby każdy wycinek odpowiadał jakiemuś sprawdzeniu.
• Przesuwa się niewłaściwe zgłoszenie. Przy podłączonych Linearze, Jirze i GitHubie polecenie „przesuń zgłoszenie” trafia w złą tablicę lub zgłoszenie. Naprawa: w każdym prompcie nazywaj system i klucz („Linear issue ENG-1423”), stosuj wzorzec szkic-potem-apply i przywróć status z historii zgłoszenia.
• Treść zgłoszenia steruje agentem. Każdy, kto może edytować zgłoszenie, może w nim podłożyć instrukcje. Naprawa: uruchamiaj tylko zgłoszenia oznaczone przez zaufanego członka zespołu, traktuj treść zgłoszenia jako dane i nie dawaj przebiegom poświadczeń produkcyjnych. Zobacz bezpieczeństwo MCP.
• Karta rozjeżdża się z kodem. Implementacja pokazuje, że doprecyzowany plan był błędny, a karta wciąż mówi swoje. Naprawa: aktualizuj kryteria akceptacji i kartę w tym samym pull requeście, który zmienia zachowanie, a rozbieżność wykrytą na przeglądzie sprintu traktuj jako zwrot.

Dokąd dalej z Agile i agentami

• Łańcuch artefaktów: sekwencja intencja, specyfikacja, plan i zadania, przez którą przechodzi każda historyjka po zejściu z tablicy.
• Wykonywalne kryteria akceptacji: zamień wynik refinementu w czerwone testy, zanim agent zacznie.
• Jak przygotować backlog dla agentów: kwalifikowalność, tory i szablon zgłoszenia dla pracy agentów.
• Behavior-Driven Development: scenariusze Given/When/Then jako wykonywalne specyfikacje.
• Metoda BMAD: role agile prowadzone przez agentów i moment, w którym ten narzut ceremonii się opłaca.