task-refinement

name	task-refinement
description	PM frameworks for task refinement — story formats (User Story, Job Story, WWA), INVEST criteria, T-shirt sizing, clarifying question patterns, risk flags. Used by Task Refiner agent during /refine.
version	1.0.0

Task Refinement Frameworks

PM-фреймворки для уточнення задач. Використовується Task Refiner агентом під час /refine.

Story Formats

User Story (3 C's + INVEST)

Коли: чітка роль користувача + конкретна дія.

Формат:

As a [role], I want to [action], so that [benefit].

3 C's Framework:

• Card — короткий заголовок + одне речення
• Conversation — детальне обговорення наміру (Description)
• Confirmation — acceptance criteria (перевірювані)

INVEST Criteria:

Критерій	Що перевірити
Independent	Чи можна реалізувати окремо від інших stories?
Negotiable	Чи є простір для обговорення з командою?
Valuable	Чи дає цінність кінцевому користувачу або бізнесу?
Estimable	Чи можна оцінити обсяг роботи?
Small	Чи вміщується в один спринт?
Testable	Чи можна перевірити без читання коду?

Приклад:

Title: Recently Viewed Section

Description: As an Online Shopper, I want to see a 'Recently viewed' section on the product page to easily revisit items I considered.

Acceptance Criteria:

1. Секція відображається внизу сторінки продукту для користувачів, які переглянули мінімум 1 продукт
2. Не відображається для першого продукту в сесії
3. Поточний продукт виключений зі списку
4. Картки містять зображення, назву та ціну
5. Клік на картку веде на сторінку продукту

---

Job Story (JTBD)

Коли: ситуація/тригер важливіший за роль; роль незрозуміла або не має значення.

Формат:

When [situation], I want to [motivation], so I can [outcome].

Фокус: контекст користувача, а не його роль. Що відбувається → що хочеться → який результат.

Приклад:

Title: Track Weekly Spending

Description: When I'm preparing my weekly budget (situation), I want to quickly see how much I've spent (motivation), so I can make sure I don't overspend before the weekend (outcome).

Acceptance Criteria:

1. Відображається зведення витрат за поточний тиждень
2. Оновлюється в реальному часі при додаванні витрати
3. Прогрес-бар показує % від бюджету
4. Залишок бюджету виділений кольором
5. Сповіщення при 80% бюджету

---

WWA (Why-What-Acceptance)

Коли: стратегічна ініціатива з бізнес-контекстом; потрібно пояснити "навіщо" команді.

Формат:

Why: [1-2 речення — зв'язок зі стратегією]
What: [опис + посилання на дизайн]
Acceptance: [перевірювані результати]

Приклад:

Title: Real-Time Spending Tracker

Why: Користувачі потребують миттєвого зворотного зв'язку щодо витрат для свідомих бюджетних рішень. Це підтримує ціль покращення фінансової обізнаності.

What: Додати трекер витрат у реальному часі, що оновлюється при логуванні витрат.

Acceptance:

• Суми оновлюються протягом 2 секунд після логування
• Прогрес бюджету візуалізований прогрес-баром
• Залишок бюджету видно одразу

---

Format Selection Guide

Сигнал у задачі	Формат	Чому
Чітка роль + конкретна дія	User Story	Роль визначає контекст
Ситуація/тригер ключовий, роль неважлива	Job Story	JTBD фокус на контексті
Стратегічна ініціатива з бізнес-"навіщо"	WWA	Потрібен стратегічний контекст
Баг-фікс	Bug Description	Окремий формат (observed vs expected)
Технічний debt / рефакторинг	WWA	Потрібне обґрунтування "навіщо"

---

Acceptance Criteria Patterns

Правила

1. Перевірювані — QA може перевірити без читання коду
2. 3-6 критеріїв — не більше (примушує до точності)
3. Покриття: happy path + error case + edge case
4. Мова: спостережувана поведінка, не технічна реалізація

Формат Given/When/Then

Given [передумова/контекст],
When [дія користувача],
Then [очікуваний результат].

Приклади хороших vs поганих AC

Добре	Погано
"Користувач бачить повідомлення про помилку при невірному паролі"	"Система кидає ValidationException"
"Експорт завершується менш ніж за 30 секунд для 1000 записів"	"Використати batch processing"
"Після оплати користувач отримує email з підтвердженням"	"Відправити event в RabbitMQ"

---

T-Shirt Sizing

Таблиця розмірів

Розмір	Індикатори	Типовий scope	Приклади
S	1-3 файли, 1 компонент, без нових API, без DB змін	Зміна конфігу, UI tweak, copy update	Змінити текст помилки, додати поле в existing form
M	4-10 файлів, 2-3 компоненти, minor API change	Новий endpoint, нове поле, проста фіча	Додати фільтр до списку, нове поле в профілі
L	10-20 файлів, 3-5 компонентів, нова інтеграція або DB migration	Фіча з кількома stories	Експорт в PDF, інтеграція з Stripe
XL	20+ файлів, cross-domain, external deps, migration	Epic — потрібна декомпозиція	Система нотифікацій, нова авторизація

Індикатори для визначення

Питання	S	M	L	XL
Скільки компонентів зачіпає?	1	2-3	3-5	5+
Потрібні зміни в БД?	Ні	Додати поле	Нові таблиці	Міграція даних
Нові API endpoints?	Ні	1	2-3	4+
Зовнішні залежності?	Ні	Ні	1	2+
Потрібен новий UI screen?	Ні	Ні	Частково	Так

Hour Estimation

Крім T-shirt, завжди давати оцінку в годинах — development + testing окремо.

Розмір	Development	Testing	Total
S	1-4h	0.5-2h	1.5-6h
M	4-12h	2-4h	6-16h
L	12-30h	4-10h	16-40h
XL	30-60h+	10-20h+	40-80h+

Ці діапазони — стартова точка. Уточнювати на основі:

• Чи є аналогічний патерн в проєкті (зменшує час)
• Чи є зовнішня інтеграція без документації (збільшує час)
• Чи потрібна міграція даних (збільшує тестування)

Confidence Level

Рівень	Коли
High	Зрозумілий scope, знайомий домен, чіткі AC
Medium	Scope зрозумілий, але є невідомі (зовнішній API, performance)
Low	Нечіткий scope, багато Open Questions, незнайома інтеграція

---

Non-Goals Guide

Non-Goals — явний перелік того, що НЕ входить в scope. Критично для PM — без цього scope повзе.

Як визначити Non-Goals

1. З діалогу: що PM згадав як "може пізніше", "nice to have", "не зараз" → Non-Goal
2. Суміжна робота: очевидні речі, які хтось може вважати частиною задачі, але не є:
   • Моніторинг/алертинг (якщо задача про функціонал)
   • UI зміни (якщо задача суто бекенд)
   • Міграція даних (якщо задача про нову фічу)
3. Технічні рішення: що свідомо не змінюємо (протокол, фреймворк, архітектуру)

Формат

## Non-Goals

Що явно НЕ входить в scope:
- {Non-goal} — {причина або "можна додати як follow-up"}
- {Non-goal} — {причина}

---

Success Metrics Guide

2-3 вимірювані показники, що доведуть успіх задачі.

Як визначити

1. З проблеми: якщо проблема "таймаути" → метрика "% таймаутів"
2. З цілі: якщо ціль "швидше" → метрика "latency"
3. З бізнес-впливу: якщо вплив "користувачі не отримують X" → метрика "conversion rate X"

Приклади

Тип задачі	Метрики
Performance	Latency (p50, p99), error rate, throughput
Caching	Cache hit ratio, TTL effectiveness
Bug fix	Reproduction rate → 0%, affected users count
New feature	Adoption rate, completion rate
Integration	Success rate, retry rate, fallback rate

Формат

| Metric | Current | Target | How to Measure |
|--------|---------|--------|----------------|
| {what} | {now}   | {goal} | {tool/method}  |

---

Requirements Prioritization

Замість плоского списку AC — групувати requirements за пріоритетом.

Must-Have (P0)

Без цього задача не вважається виконаною. Зазвичай 2-4 requirements.

Nice-to-Have (P1)

Покращення, що додають цінності, але можуть бути follow-up PR. Зазвичай 1-3 requirements.

Формат кожного requirement

**R{N}. {Title}**
- {1-2 речення опис}
- Acceptance criteria:
  - [ ] {Testable, observable criterion}
  - [ ] {Testable, observable criterion}

---

Clarifying Question Templates

Категорії та приклади

Питання формулюються PM-friendly мовою — без технічного жаргону.

Who (Хто)

• "Хто буде використовувати цю функцію? Наприклад: кінцеві користувачі, адміністратори, або обидва?"
• "Чи є різні рівні доступу? Наприклад: безкоштовні vs преміум користувачі?"

Trigger (Тригер)

• "Що спонукає потребу в цьому? Яка ситуація у користувача?"
• "Як часто це буде використовуватись? Щодня, раз на тиждень, рідко?"

Behavior (Поведінка)

• "Як саме це має працювати з точки зору користувача? Крок за кроком."
• "Чи є приклад з іншого продукту, де це працює так, як ви уявляєте?"

Edge Cases (Граничні випадки)

• "Що має відбутися, якщо щось пішло не так? Наприклад: немає інтернету, невірні дані."
• "Чи є обмеження? Наприклад: максимальна кількість, розмір файлу."

Priority (Пріоритет)

• "Наскільки це терміново? Чи є дедлайн?"
• "Що станеться, якщо це не зробити найближчим часом?"

Dependencies (Залежності)

• "Чи залежить це від іншої задачі або функції, яка ще не готова?"
• "Чи потрібна інформація від іншої команди або зовнішнього сервісу?"

Правила діалогу

1. Максимум 2-3 питання за раунд — не перевантажувати PM
2. Максимум 3 раунди — потім синтезувати з наявним, gaps → Open Questions
3. Завжди давати приклади/варіанти — "Наприклад: X, Y, або Z?"
4. Підтверджувати розуміння — "Якщо я правильно зрозумів: [summary]. Вірно?"
5. "Не знаю" — це нормально — записати як Open Question, не тиснути

---

Risk Flag Patterns

Патерн у задачі	Risk Flag	Severity
"оплата", "billing", "підписка", "subscription"	SECURITY: обробка платіжних даних	high
"експорт", "імпорт", "міграція даних"	DATA: великі об'єми даних, performance	medium
"зовнішній API", "інтеграція", "webhook"	DEPENDENCY: доступність зовнішнього сервісу	medium
"авторизація", "auth", "permissions"	SECURITY: контроль доступу	high
"health data", "медичні дані", "PHI"	COMPLIANCE: захист персональних даних	high
Зачіпає спільний компонент	COORDINATION: інші команди можуть бути задіяні	medium
Немає чітких AC після діалогу	SCOPE: вимоги досі неоднозначні	high
"performance", "швидкість", "навантаження"	PERFORMANCE: потрібен benchmark/profiling	medium

---

Bug Description Format

Для баг-фіксів замість story format:

## Bug: {Title}

**Observed:** {Що відбувається зараз}
**Expected:** {Що має відбуватись}
**Steps to Reproduce:** {Як відтворити}
**Frequency:** {Завжди / Іноді / Рідко}
**Impact:** {Хто страждає і як}

**Acceptance Criteria:**
1. {Проблема більше не відтворюється при steps above}
2. {Існуючий функціонал не зламаний}
3. {Edge case handled}