| 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 продукт
- Не відображається для першого продукту в сесії
- Поточний продукт виключений зі списку
- Картки містять зображення, назву та ціну
- Клік на картку веде на сторінку продукту
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:
- Відображається зведення витрат за поточний тиждень
- Оновлюється в реальному часі при додаванні витрати
- Прогрес-бар показує % від бюджету
- Залишок бюджету виділений кольором
- Сповіщення при 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
Правила
- Перевірювані — QA може перевірити без читання коду
- 3-6 критеріїв — не більше (примушує до точності)
- Покриття: happy path + error case + edge case
- Мова: спостережувана поведінка, не технічна реалізація
Формат 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
- З діалогу: що PM згадав як "може пізніше", "nice to have", "не зараз" → Non-Goal
- Суміжна робота: очевидні речі, які хтось може вважати частиною задачі, але не є:
- Моніторинг/алертинг (якщо задача про функціонал)
- UI зміни (якщо задача суто бекенд)
- Міграція даних (якщо задача про нову фічу)
- Технічні рішення: що свідомо не змінюємо (протокол, фреймворк, архітектуру)
Формат
## Non-Goals
Що явно НЕ входить в scope:
- {Non-goal} — {причина або "можна додати як follow-up"}
- {Non-goal} — {причина}
Success Metrics Guide
2-3 вимірювані показники, що доведуть успіх задачі.
Як визначити
- З проблеми: якщо проблема "таймаути" → метрика "% таймаутів"
- З цілі: якщо ціль "швидше" → метрика "latency"
- З бізнес-впливу: якщо вплив "користувачі не отримують 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 (Залежності)
- "Чи залежить це від іншої задачі або функції, яка ще не готова?"
- "Чи потрібна інформація від іншої команди або зовнішнього сервісу?"
Правила діалогу
- Максимум 2-3 питання за раунд — не перевантажувати PM
- Максимум 3 раунди — потім синтезувати з наявним, gaps → Open Questions
- Завжди давати приклади/варіанти — "Наприклад: X, Y, або Z?"
- Підтверджувати розуміння — "Якщо я правильно зрозумів: [summary]. Вірно?"
- "Не знаю" — це нормально — записати як 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}
