Przepływy pracy Agile: Integracja Scrum i Kanban

Planowanie sprintu rozciąga się do czterdziestu pięciu minut, bo połowa z nich to zespół czytający razem mglistą historyjkę i zgadujący podzadania. A karty, które z tego wychodzą, lądują w “Do zrobienia” z jednoliniowym tytułem i bez kryteriów akceptacji, więc ktokolwiek je podejmie, traci pierwszą godzinę na odtwarzanie tego, co było zamierzone. Agenci AI są dobrzy dokładnie w tej tkance łącznej — rozbijaniu historyjki na zadania, rozwijaniu karty, kreśleniu changelogu z przeglądu — a z połączeniem MCP do Twojej tablicy mogą to robić bez kopiowania między narzędziami.

Ten przewodnik pokazuje, jak wpleść agenta AI w ceremonie Scrum i przepływ Kanban — konkretnymi promptami i prawdziwymi integracjami tablicy, nie frazesami w stylu “AI przyspiesza zespół”.

Co z tego wyniesiesz

Gotowe prompty do rozbicia w planowaniu sprintu, changelogów z przeglądu sprintu i zamiany cienkiej karty Kanban w plan techniczny.
Dwie integracje tablicy, które się liczą — zdalny MCP Linear oraz MCP Atlassian (Jira/Confluence) — z dokładnymi komendami instalacji.
Porównanie “przed/po” tego, jak wygląda karta, gdy agent ją rozwinie.
Podział na trzy narzędzia w automatyzacji tablicy: pobieranie zgłoszenia w IDE przez Cursor, headless’owy krok PR-i-komentarz w Claude Code oraz natywne automatyzacje Linear/GitHub/Slack w Codeksie.
Tryby porażki — nadmierne rozbijanie, dryfujące estymaty, nienadzorowane zapisy na tablicy — i jak utrzymać człowieka w pętli.

AI w przepływie pracy Scrum

Agent AI może wnieść wkład w każdą fazę sprintu, ale tylko wtedy, gdy dasz mu prawdziwe artefakty (historyjkę, ścieżki repo, zmergowane PR-y), a nie streszczenie.

Planowanie Sprintu

Przekaż agentowi historyjkę użytkownika plus odpowiednie ścieżki repo i każ mu zaproponować rozbicie na podzadania z grubymi estymatami i flagami ryzyka. Nie oddajesz estymaty na zewnątrz — zaczynasz rozmowę od konkretnego rozbicia, zamiast od pustej tablicy.

Sam Sprint

Programiści pobierają zadanie i implementują pętlami PRD → Plan → Todo i TDD. Integracja z tablicą zamyka pętlę, przesuwając zgłoszenie w miarę postępu prac.

Przegląd Sprintu

Wygeneruj changelog przeglądu z faktycznie zmergowanych PR-ów w sprincie. Agent czyta tytuły i opisy PR-ów i kreśli release notes dla użytkownika oraz skrypt do demo — minuty zamiast pół godziny przewijania.

Retrospektywa

Retro zostaje ludzkie, ale przynieś dane: poproś agenta o podsumowanie czasu cyklu per karta z tablicy, by “byliśmy wolni przy pracy nad API” stało się liczbą zamiast wrażeniem.

Rozbicie w planowaniu sprintu

Najwięcej dźwigni daje prompt, który zamienia historyjkę w estymowalny plan. Bądź konkretny co do swojego stacku, by podzadania były prawdziwe, nie generyczne.

Here is a user story:
"As a returning customer, I can reset my password via an emailed link
that expires after 30 minutes."

Our stack: Next.js (App Router) + Drizzle/Postgres, Resend for email,
auth in lib/auth/. Read lib/auth/ and app/(auth)/ before answering.

Break this into implementation subtasks. For each: a one-line title,
a rough estimate in story points (1/2/3/5), and a risk flag if it
touches security, email deliverability, or a migration. Call out any
acceptance criteria the story is missing. Do not write code yet.

Changelog przeglądu sprintu

These PRs merged into main during sprint 24:
#412 "Add password reset flow", #415 "Rate-limit reset endpoint",
#418 "Fix expired-token error copy".

For each, read the PR title and body. Produce:
1. A user-facing changelog grouped by Added / Changed / Fixed, in plain
   language a non-engineer stakeholder understands.
2. A 5-line demo script for the sprint review covering the happy path
   and the expired-link case.
Flag anything that needs a migration or env-var change before deploy.

Z podłączonym MCP Atlassian albo Linear (poniżej) agent może sam pobrać te zmergowane PR-y i powiązane z nimi zgłoszenia, zamiast byś wklejał numery.

AI w przepływie pracy Kanban

Kanban polega na przepływie i krótkim czasie cyklu. Zadaniem agenta jest usunięcie tarcia na krawędziach tablicy: niedoprecyzowanej karty na wejściu i ręcznego przepychania statusów na wyjściu.

Niedoprecyzowana karta

Karta zatytułowana “Implement social login” mówi wdrażającemu prawie nic. Przepuść ją przez agenta, zanim ją pobierzesz.

Kanban card title: "Implement social login".
Our stack: Next.js App Router, Auth.js (NextAuth) already wired for
email/password in lib/auth/. We want Google and GitHub providers.

Read lib/auth/ and produce, as Markdown I can paste back onto the card:
- A 2-sentence scope statement (what's in, what's out).
- A subtask checklist (provider config, callback routes, account-linking,
  UI buttons, env vars, tests).
- Acceptance criteria as Given/When/Then.
- Open questions a human must answer before this is "ready".

Przed: Implement social login — bez zakresu, bez kryteriów, bez pojęcia, czy account-linking jest w zakresie.

Po: karta ze stwierdzeniem zakresu, ośmiopunktową listą kontrolną, trzema kryteriami Given/When/Then i dwoma oflagowanymi pytaniami (“łączyć z istniejącymi kontami e-mail, czy osobno?”). Wdrażający zaczyna kodować zamiast zgadywać, a czas cyklu spada, bo niejednoznaczność została rozwiązana, zanim karta weszła w “W toku”.

Podłączenie tablicy: MCP Linear i Atlassian

By agent mógł czytać i przesuwać zgłoszenia, podłącz serwer MCP tablicy. Oba to zdalne serwery MCP dodawane przez transport HTTP — nie ma paczki npm @linear/* ani @jira/* do instalacji.

Konfiguracja MCP ma identyczny kształt we wszystkich trzech narzędziach; różni się tylko komenda rejestracji. Dla Claude Code:

# Linear (first-party remote MCP)
claude mcp add --transport http linear https://mcp.linear.app/mcp

# Atlassian — Jira + Confluence (official remote MCP)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp

Oba używają OAuth przy pierwszym połączeniu — autoryzujesz w przeglądarce, żadnego tokena API w pliku konfiguracyjnym. W Cursorze i Codeksie rejestrujesz te same dwa adresy URL przez ich UI/plik konfiguracji MCP; endpointy i scope’y są takie same. Zajrzyj do przewodników MCP Atlassian i MCP do zarządzania projektami po konfigurację per narzędzie i pełną listę narzędzi, które wystawia każdy serwer.

Przed MCP: kopiujesz tekst zgłoszenia do agenta, wykonujesz pracę, potem przełączasz się na Jirę/Linear, by przesunąć kartę i wkleić podsumowanie.

Po MCP: “Move LIN-204 to In Review and comment with a 3-bullet summary of the change” dzieje się w tej samej sesji, na żywej tablicy.

Automatyzacja tablicy w trzech narzędziach

Tam, gdzie praca naprawdę się rozchodzi, chodzi o to, kto napędza ruch na tablicy — i to jest prawdziwa różnica między trzema narzędziami, nie przypadek “identyczny”.

Użyj trybu agenta z MCP tablicy, by wciągnąć zgłoszenie do IDE: “Read LIN-204 from Linear and scaffold the work.” Do przebiegów bez nadzoru agent w tle może wziąć zgłoszenie, zaimplementować wedle listy kontrolnej i zdać raport. Siłą Cursora jest pobieranie w IDE z człowiekiem w pętli — zostajesz w edytorze, a kontekst zgłoszenia przychodzi do Ciebie.

Claude Code błyszczy jako skryptowany/headless’owy krok w CI. Uruchom claude -p nieinteraktywnie z dostępnym MCP tablicy, by job po mergu skomentował changelog na zgłoszeniu i przesunął je do “In Review”. Ogranicz go ciasno przez --allowedTools (np. Bash, Edit), by zautomatyzowany krok mógł działać i łatać, ale nic więcej. To wzorzec “robot-członek zespołu, który aktualizuje tablicę”.

Kiedy to się psuje

Agent nadmiernie rozbija. Prosisz o podzadania i dostajesz czternaście, połowa z nich to drobiazgi “utwórz plik”. Ogranicz go (“nie więcej niż 6 podzadań; scal wszystko poniżej pół punktu”) i traktuj wynik jako szkic, który zespół przycina, a nie plan rekordu.
Estymaty dryfują w stronę kotwicy agenta. Story pointy, które agent wymyśla, stają się kotwicą zespołu, czy są trafne, czy nie. Używaj ich, by zacząć planning poker, nigdy by zastąpić liczbę zespołu — agent nie ma pamięci o velocity Twojego zespołu.
Nienadzorowane zapisy na tablicy są niebezpieczne. Automatyzacja, która przesuwa zgłoszenia albo dodaje komentarze, w końcu przesunie nie to. Wymagaj ludzkiego potwierdzenia dla zmian stanu w sesjach interaktywnych, a w przebiegach headless/CI trzymaj mutacje tablicy idempotentne i ograniczone do dokładnego klucza zgłoszenia, dla którego job został wyzwolony.
Rozrost narzędzi MCP myli agenta. Z podłączonymi naraz Jirą, Linear i GitHubem agent czasem sięga po niewłaściwą tablicę. Nazywaj system i klucz zgłoszenia wprost (“in Linear, issue LIN-204”) zamiast “to zgłoszenie”.
Tablica staje się źródłem prawdy dla niewłaściwej rzeczy. Rozwinięta karta to punkt wyjścia, nie kontrakt. Jeśli implementacja ujawni, że plan był zły, popraw kartę — nie pozwól, by wcześniejsza zgadywanka agenta nadpisała to, czego nauczyłeś się, pisząc kod.

Co dalej

PRD → Plan → Todo — pętla planowania, przez którą przechodzi każde zadanie sprintu, gdy opuści tablicę.
Test-Driven Development — wewnątrzsprintowa pętla red/green, która ścina czas cyklu.
Serwery MCP do zarządzania projektami oraz MCP Atlassian — pogłębienie podłączania i ograniczania integracji tablicy, do których odwołujemy się powyżej.