Візія Сергія:
оцінювання ефективніше проводити не в story points, а в “півднях” (half-days). Таски при цьому мають бути нарізані від півдня до максимум двох днів. Якщо більше - дробити. Якщо менше - об’єднувати.
Як навчитись оцінювати? У людини один мозок — і для роботи, і для побуту. Тож оцінку часу можна (і варто) тренувати завжди. Йдеш у магазин — прикинь, скільки це займе, і порівняй реальний результат із прогнозом. Це вже практика.
Моє бачення питання Estimations:
1️⃣ Самі творці Scrum відмовились від оцінок у їхньому класичному вигляді.
Estimating tasks will slow you down. Don’t do it… No estimation at all will improve team performance over hour estimation.
Jeff Sutherland, співзасновник Scrum і автор Agile Manifesto
2️⃣Відсутність процесу оцінювання ≠ відсутність обговорення задач і усунення невизначеностей.
3️⃣Бізнесу потрібні не оцінки, а предиктабельність (predictability).
Вона досягається тоді, коли задачі дрібні, зрозумілі, і їх регулярно доставляють у продакшн.
Детальніше у книжці NoEstimates.
4️⃣Інженер може дати адекватну оцінку тільки при фіксованому бізнес-скоупі та стабільному технічному стеку. Але заморожувати скоуп і стек - це гальмувати бізнес. І майже ніхто на це не піде.
5️⃣Бізнесу справді потрібні оцінки лише тоді, коли є кілька варіантів реалізації фічі, і вибір залежить від ресурсів. Але практика показує, що краще зробити A/B тест і подивитись на реакцію користувачів, а не гадати.
Ще раз – дрібні задачі, швидкий фідбек від команди та бізнесу ось наш реальний delivery framework.
📌 До речі, практика нарізки бізнес-фіч на дрібні delivery-орієнтовані задачі існує ще з 2016 року
А з появою AI вона почала допомагати не лише бізнесу, але й інженерам, які можуть у AI tools.
👉 Резюме
Згоден із Сергієм у тому, що задачі мають бути правильно нарізані.
А от витрачати час на оцінювання — особливо в динамічному середовищі — мені здається зайвим.