Синтез sprint retrospective

Агент перетворює сирі нотатки з retrospective на структуровані insights і стежить за їхньою долею між спринтами. Працює як другий учасник зустрічі, який не забуває деталі обговорення і пов'язує поточний спринт з історією команди.

Що робить агент

1. Отримує джерело даних: транскрипт ретро, експорт з Miro або Mural, нотатки в Notion або Confluence, повідомлення з каналу Slack.
2. Розбирає обговорення на чотири категорії: wins (що спрацювало), pain points (що сповільнювало команду), action items (що вирішили робити), open questions (невирішені теми).
3. Дедуплікує формулювання з минулими ретро — якщо «повільний CI» обговорювався в sprint 4 і sprint 7, агент пов'язує записи, а не створює нові.
4. Створює завдання в issue tracker (Jira, Linear, YouTrack) для action items з контекстом з обговорення і посиланням на джерело.
5. Оновлює історичний лог у базі знань: одна сторінка на спринт плюс агрегований індекс тем.
6. Раз на 5-10 спринтів формує pattern report — список тем, які повертаються без resolution, і action items, які не зрушили зі статусу open.

Що отримує команда

• Історія ретроспектив доступна в пошуку, а не тільки в пам'яті учасників.
• Action items трекаються як звичайні завдання, не залишаються в нотатках зустрічі.
• Видно повторювані паттерни, які губляться при погляді на один спринт.

Що агент не робить

• Не проводить ретро замість фасилітатора і не замінює живе обговорення в команді.
• Не приймає рішення про організаційні зміни — рішення залишаються за PM, scrum-master і командою.
• Не інтерпретує емоції та міжособистісні конфлікти — лише фіксує те, що було сказано у структурованій формі.

Технічна схема зводить три шари: джерело нотаток з ретро, LLM-пайплайн для структурування та дві точки запису — issue tracker для action items і knowledge base для історії. Агент працює в push-моделі: запускається після завершення ретро, а не опитує системи постійно.

Потік даних

1. Тригер. Календарна подія Sprint Retrospective завершилась, або scrum-master вручну завантажив нотатки. У low-code варіанті тригер збирає workflow-рушій або Zapier.
2. Збір джерела. Агент отримує транскрипт із Fireflies або Otter, експорт з Miro або Mural або текст із Notion/Confluence — залежно від того, як команда веде ретро.
3. LLM-обробка. AI-модель розбирає текст за схемою: wins, pain points, action items, open questions. Кожен запис отримує owner (якщо згаданий), severity і посилання на першоджерело.
4. Перевірка дублів. Перед записом агент виконує семантичний пошук по історичному логу — якщо схожий pain point вже фіксувався, новий запис лінкується до попереднього, а не дублює його.
5. Запис. Action items надходять до issue tracker (Jira, Linear, YouTrack) зі статусом retro-open. Wins і pain points зберігаються в базу знань — одна сторінка на спринт плюс агрегований індекс тем.
6. Періодична агрегація. Раз на 5-10 спринтів запускається окремий job, який будує pattern report: теми без resolution, action items зі статусом open довше N спринтів, частота згадувань за категоріями.

Компоненти

Кроки впровадження

1. Вибрати джерело нотаток. Зафіксувати один формат: транскрипт із транскрайбера або шаблон у Notion/Confluence. Без єдиного формату агент буде ламатися на кожному ретро.
2. Підготувати сховище. Створити розділ у базі знань для sprint-ретро та завести в issue tracker окремий label або project для retro-action items.
3. Зібрати LLM-пайплайн. Описати схему вихідних даних (JSON), написати промпт, додати валідацію — агент повертає JSON з обов'язковими полями або нічого.
4. Підключити issue tracker. Налаштувати створення задач через API: title з короткого формулювання, description з контекстом, assignee якщо згаданий, label retro.
5. Увімкнути дедуплікацію. Перед записом pain point агент шукає схожі в логу за останні N спринтів і лінкує, а не дублює.
6. Запустити pattern report. Окремий job раз на 5-10 спринтів формує зведення і кладе його в knowledge base і канал команди.

Low-code реалізація на workflow-рушії плюс мовна модель закривається за 2-4 тижні силами одного розробника. Критичні частини — схема вхідних даних і дедуплікація; решта — стандартні інтеграції.

Автоматизація розрахована на команди зі стабільним sprint-ритмом і мінімальною цифровою інфраструктурою для колаборації. Основні вимоги розподіляються на дані, процес і команду.

Дані та доступи

• Формат ретроспективи з voice або text записом: транскрипт із Fireflies/Otter, експорт із Miro/Mural або шаблон у Notion/Confluence.
• API-доступ до issue tracker (Jira, Linear, YouTrack) з правами на створення задач і роботу з labels.
• API-доступ до knowledge base (Notion, Confluence) з правами на запис сторінок.
• API-ключ LLM-провайдера (Anthropic для LLM).

Процес команди

• Регулярна retrospective на спринт — мінімум 5-10 спринтів на рік, інакше pattern detection не накопичує дані.
• Домовленість про єдиний формат нотаток. Якщо половина команд веде ретро в Miro, а половина — у Slack-треді, агенту потрібно два пайплайни.
• Власник процесу: scrum-master або PM, який відповідає за завантаження і перевірку результату після кожного ретро.

Команда впровадження

• Розробник із досвідом low-code (workflow-рушій, Zapier) або Python для LLM-пайплайну.
• Scrum-master або PM як product owner автоматизації — відповідає за схему даних і валідацію insights.

Таймлайн

Впровадження займає 2-4 тижні для однієї команди: тиждень на схему і пайплайн, тиждень на інтеграції, один-два тижні на тестування на 2-3 ретро підряд. Розширення на кілька команд додає 1-2 тижні на уніфікацію формату нотаток.