История 📜
В 2017 году я впервые стал тимлидом, а в 2019-2022 годах я вёл курсы по тимлидству, параллельно сам проходя нелёгкую трансформацию из инженера в менеджеры. Всего провёл 3 потока. В первую очередь, курсы были нужны мне самому, чтобы структуризировать свои знания, которые я получал в основном из личного опыта и из очень разрозненных источников, так как tlroadmap тогда только формировался. Оказалось, что этот курс был полезен и для других людей.
Один из фундаментальных вопросов, которые меня тогда беспокоили, касался сторипоинтов. Я видел много материалов про то, что сторипоинты должны оценивать сложность, и много материалов про то, что они должны оценивать эффорт, который смешивает сложность и время в одну кучу.
На практике же я наблюдал, что практически всегда сторипоинты приравнивались ко времени, что, по сути, убивало их главную идею: абстрагирование от времени.
Вместе с тем, я до конца так и не мог понять, как можно оценивать сложность задач. Я понимал, как оценивать риски. Но сложность - нет.
Так было пока я не наткнулся на пример в скрам гайде (про мальчика и нейрохирурга, см. дальше). Это дало довольно серьёзную подсказку.
Тем не менее, я ещё несколько лет не мог понять, как можно наглядно синхронизировать сторипоинты между всеми членами команды. Мне довольно быстро пришла идея использования грейдов, но у меня стало появляться много вопросов касательно того, почему тогда в принципе не используются грейды вместо абстрактных чисел.
Наконец, вся картинка сложилась, когда я стал опираться на цель спринта и интересы бизнеса.
ДИСКЛЕЙМЕР
Всё, что описано ниже, относится к миру розовых пони и молочных рек. Я понимаю, что мы все живём в реальном мире, и сферический скрам в вакууме - это удел небожителей. Тем не менее, я решил опубликовать эту статью, поскольку она, как мне кажется, позволяет глубже разобраться в том, что скрам гайд на самом деле подразумевал под сторипоинтами, и почему они вообще были введены. А это понимание, в свою очередь, позволит более честно взглянуть на ваш SDLC, особенно на ту точку, где разработка соприкасается с бизнесом, и, возможно, как-то улучшить свои процессы.
Строго не рекомендуется показывать эту статью вашему бизнесу, если хотите и дальше иметь возможность осуществлять партизанский рефакторинг и прочие закрытые практики.
Неискоренимая проблема
Многие команды до сих пор путают сторипоинты с временем.
"Я сделую эту задачу примерно за 5 сторипоинтов" — часто можно услышать на груминге. И в этой фразе уже слышно, что человек оценивает время, и приравнивает сторипоинты к человеко-дням (или часам).
На самом же деле, задача на 5 дней может быть оценена в абсолютно любое количество сторипоинтов. Всё зависит от того, насколько она сложная.
Каноничный пример 🧠
Представьте команду из мальчика 7-8 лет и нейрохирурга.
У нас есть две задачи:
- Сделать несложную операцию на мозг
- Облизать 1000 марок
Обе задачи займут примерно час, но их сложность радикально отличается.
Мальчик справится со второй задачей, но не с первой. Нейрохирург справится с обеими, но первая для него — ежедневная рутина, а вторая — неприятная, но простая работа.
Очевидно, что в этом случае, несмотря на одинаковое время для обеих задач, они будут оценены в разные сторипоинты, поскольку сложность у них разная.
Важный вывод: сторипоинты измеряют не время, а уровень компетенции, необходимый для решения задачи.
Примеры из разработки 💻
Задача 1: Скопировать готовый компонент из другого проекта со схожей архитектурой
- Время: 4 часа
- Сторипоинты: 1 sp (рутинная работа, известное решение)
Задача 2: Придумать архитектуру для нового типа компонентов
- Время: 4 часа
- Сторипоинты: 13 sp (творческая работа, множество неизвестных)
Задача 3: Написать простой SQL-запрос для отчета
- Время: 2 часа
- Сторипоинты: 2 sp (стандартная задача)
Задача 4: Оптимизировать медленный SQL-запрос в продакшене
- Время: 2 часа
- Сторипоинты: 8 sp (требует анализа планов выполнения, индексов, производительности)
Задача 5: Изменить цвет кнопки в интерфейсе
- Время: 30 минут
- Сторипоинты: 1 sp (простое изменение CSS)
Задача 6: Сделать чтобы нажатие на кнопку не фризило страницу
- Время: 30 минут
- Сторипоинты: 5 sp (требует понимания асинхронности и работы с DOM)
Видите парадокс? Задачи с одинаковым временем могут отличаться в сложности в 5-13 раз. Время выполнения не определяет сложность.
Шкала компетенций 📊
- 1 sp = интерн (тривиальные задачи, которые могут сделать все)
- 2 sp = джун
- 3 sp = джун+
- 5 sp = миддл
- 8 sp = миддл+
- 13 sp = сеньор
- 20 sp = лид/архитектор
Важно: сторипоинты ≠ грейды ⚠️
Шкала компетенций показывает сложность задачи, а не требования к исполнителю. Если вам так психологически комфортнее, то говорите "это джун-задача" вместо "это задача для джуна".
Почему это важно:
- В скраме команда работает как единое целое, а не как набор отдельных специалистов; если вы работаете по большей части независимо, то и синхронизация эстимаций вам по большому счёту не нужна
- Задача на 13 sp не означает, что её должен делать только сеньор
- Джуниоры могут выполнять сложные задачи при должном инвестировании в декомпозицию и дизайн со стороны команды
- Сеньоры могут брать простые задачи для помощи команде
Неправильно: "Это задача на 13 sp, значит её должен делать сеньор"
Правильно: "Это сложная задача, давайте обсудим, как мы будем её решать"
Важный принцип: Чем более конкретно расписан план реализации задачи, тем проще она становится. Детальная проработка снижает неопределённость и превращает сложную задачу в набор простых подзадач. Даже без декомпозиции очень сложную задачу можно превратить в простую, если написать детальный план имплементации.
Время в скраме ⏰
В скраме время регулируется только одним показателем: длительность спринта (как правило, две недели).
Это ключевой принцип — мы не оцениваем время выполнения отдельных задач. Время уже задано. Мы пытаемся втиснуть в известное время реалистичный объём работ, необходимый для достижения цели за это время.
То есть... Зачем нам тогда сторипоинты, если они не помогают оценивать время?
Сторипоинты нужны для:
- Сравнения сложности задач между собой и правильного распределения усилий
- Выбора оптимального подхода к решению проблемы
- Декомпозиции слишком сложных задач
- Прогнозирования того, каковы шансы успешно закончить спринт
Они помогают оценивать не время, а объём работ, который команда сможет выполнить за спринт.
Но для этого нам нужно понимать, что именно мы планируем достичь за спринт.
Цель 🎯
У каждого спринта обязательно должна быть цель. Этот момент упускают практически все. Команды, которые правильно ставят цели спринта, встречаются крайне редко.
Цель — это то, что команда планирует достичь за спринт.
И у нас получается следующая картина:
- Мы знаем, что нужно сделать
- Мы знаем, сколько времени у нас есть
Получается, что во время планирования мы должны выяснить, как мы можем достичь цели за фиксированное время. Вопрос только в том, каким именно путём мы его достигнем.
Именно в этом и заключается основная функция сторипоинтов — они помогают команде найти оптимальный способ достижения цели в рамках ограничений спринта.
Как это работает на практике:
- Команда видит цель спринта и доступное время
- Оценивает сложность разных подходов к решению в сторипоинтах
- Выбирает тот подход, который максимизирует шансы достижения цели при минимальном ущербе качеству
- При необходимости декомпозирует сложные задачи на более простые
Главная цель сторипоинтов: декомпозиция 🎯
Сторипоинты нужны в первую очередь для декомпозиции задач.
Как сторипоинты помогают принимать решения о декомпозиции:
- 20+ sp = задача слишком сложная, требует декомпозиции
- 13 sp = можно попробовать декомпозировать для снижения рисков
- 8 sp = оптимальная сложность для большинства задач
- 5 sp и меньше = задачи готовы к выполнению
Практический пример:
Задача "Переписать систему аутентификации" оценивается в 20 sp. Команда понимает, что это слишком сложно, и разбивает на:
- "Спроектировать новую архитектуру" (8 sp)
- "Создать базовые компоненты" (5 sp)
- "Настроить миграцию данных" (5 sp)
- "Протестировать интеграцию" (3 sp)
Цель этого процесса — разобрать на части сложные задачи и получить набор достаточно простых задач, в которых будет меньше рисков.
В общем, сторипоинты решают задачу относительной оценки задач по сложности. Зачем это делать? Чтобы сфокусировать усилия по дизайну на тех задачах, которые остаются наиболее непонятными. И, на самом деле, сторипоинты - это не единственный инструмент, который позволяет это сделать.
Процесс оценки ⚡
Сторипоинты нужны для поиска оптимального решения в строго заданных рамках.
Когда и как происходит оценка
Оценка происходит на груминге и незначительно корректируется во время планнинга. Или, если в грумингах нет нужды, осуществляется на планнинге. В обоих случаях в процессе участвует вся команда, что очень сильно помогает с декомпозицией и дизайном. Единственная цель этого процесса - поиск оптимального решения, которое позволит команде достичь цели за спринт с минимальной потерей в качестве.
Коллективное обсуждение и декомпозиция
Коллективное обсуждение позволяет увидеть задачу с разных сторон, выявить скрытые сложности и найти способы разбить её на более простые части.
Чем проще задача, тем меньше в ней рисков. Чем меньше рисков, тем больше шансов, что цель спринта будет достигнута.
Поиск локального оптимума
Сторипоинты, в которые мы оцениваем задачи, позволяют нам сразу высказать, насколько придуманное нами решение сложное. После этого мы можем обсудить разные варианты решения и произвести корректировку с учётом новой информации. То есть, при помощи сторипоинтов мы совместно ищем локальный оптимум и записываем согласованное решение, тем самым уменьшая сложность задачи для исполнителя. Интересы бизнеса при этом не страдают, поскольку время, отведённое на спринт, не меняется, и не меняется цель. Меняется только способ имплементации.
Фокус на бизнес-интересах
Вся инженерная смекалка в рамках скрама направляется не на идеальное решение, которое может занять бесконечное время, а на то, как достичь цели за фиксированное и довольно короткое время - за одну итерацию.
Управление техническим долгом в этом случае переносится на уровень бизнеса. Хотите больше технических задач? Объясните бизнесу, какую ценность они принесут.
Скрам всегда ставит во главу угла интересы бизнеса, и это правильно. Делайте как скрам.
Практические выводы ✅
Правильное понимание сторипоинтов помогает:
- Ставить реалистичные цели спринта
- Находить оптимальные решения в рамках фиксированного времени
- Снижать риски за счёт декомпозиции сложных задач
- Фокусироваться на интересах бизнеса, а не на идеальных технических решениях
От сторипоинтов к времени 📈
Задачи переводятся во время с использованием статистических методов по историческим данным команды (метод монте-карло).
Команда на планнинге, по сути, делает ставку, что определённый объём работ (в сторипоинтах) будет завершён за итерацию. Это позволяет планировать спринты более реалистично, так как со временем команда учится делать реалистичные ставки.
Справка: На практике команды используют velocity (среднее количество сторипоинтов за спринт) и burn-down charts для отслеживания прогресса. Бизнес перестаёт полагаться на оценки разработчиков в часах, и оперирует масштабами спринтов. Роудмаппинг становится более простым и значительно более гибким, так как роудмап можно менять хоть каждую итерацию.
Сторипоинты — это инструмент для поиска локального оптимума в рамках ограничений бизнеса, а не калькулятор человеко-дней.
Что делать дальше? 🚀
На следующем груминге спросите команду: "Насколько сложная эта задача?" вместо "Сколько времени займет?"
При планировании спринта фокусируйтесь на цели, а не на заполнении времени задачами
Если задача больше 8 sp — подумайте, можно ли её декомпозировать
Отслеживайте velocity команды, чтобы понимать реальную производительность
Обсуждайте риски и способы их минимизировать при оценке сложных задач, а не пытайтесь угадать время
Сторипоинты в эпоху ИИ 🤖
В эпоху ИИ-ассистентов сторипоинты становятся идеальным инструментом для измерения "силы" ИИ-агента: мы оцениваем, насколько сложные задачи они могут решить.
Как это работает:
- ИИ-агент может решать задачи до определенного уровня сложности (например, до 5 sp)
- Задачи выше этого уровня требуют человеческого участия
- Понимая способности ИИ, мы знаем, до какой степени детализировать задачи для них
Практический пример:
- Задача "Написать простой SQL-запрос" (2 sp) - ИИ справится
- Задача "Оптимизировать медленный запрос в продакшене" (8 sp) - нужен человек
- Задача "Спроектировать архитектуру БД" (13 sp) - только человек
Сторипоинты становятся ватерлинией, ниже которой человек может не напрягаться.
Навык декомпозиции сложных задач на простые обретает новую ценность, так как он отличает того, кто может заставить агентов сделать сложную задачу от тех, кто не может.
Заключение
Напоминаю, что эта статья - всего лишь рассуждение о том, как и почему сторипоинты появились. Время возвращаться из мира розовых пони в суровую реальность с плохо налаженными процессами. Надеюсь, что это путешествие поможет тебе, клубчанин, если и не изменить свои процессы к лучшему, то хотя бы лежать в правильную сторону.
P. S.: Для желающих углубиться в тему - вот хорошая статья про сложность и способы её оценки.
сторипойнты это фикция придуманная масонами
Изначально скрам позиционировался как что-то молодежное, для стартапов, но сейчас это про корпорации и все застойное.
Глобально, существует 2 вида компаний:
В процессно-ориентированных думают в основном про процессы, а не про то, что получается в итоге. "Мы работаем по аджайлу", "наши разработчики обязаны использовать ИИ в работе" — это все про процессы, не про результат. В результато-ориентированных думают про результат, и обычно не так важно, какие метрики были в процессе. "Наша задача — построить ракету, которая доставит человека на Марс", "мы хотим создать первый компьютер с цветным экраном". Со вторым обычно тем сложнее, чем больше компания, но есть исключения типа Маска и его компаний.
Проблема со вторым вариантом в том, что он упирается по сути в наличие одного человека, у которого есть Видение. А Видение мало у кого есть, это редкое явление. Без Видения возникает диктатура менеджмента, построенная на метриках (в лучшем случае), т.е. процессно-ориентированная, когда все старательно имитируют движение к каким-то целям, но никогда их по-настоящему не достигают. Те самые bullshit jobs.
Вся тема со сторипоинтами в своей основе — процессно-ориентированная. Она про то, как максимально равномерно из года в год грести, разгребать какой-то бэклог, а не как достигать больших целей. Это про то, как добиться *максимального отчуждения" разработчиков от результатов своего труда, как унифицировать их, как сделать их взаимозаменяемыми и устранить всякое подобие индивидуальности в командах (ведь иначе невозможно ввести единую метрику сложности для всех). Именно поэтому менеджмент так любит SP.
Хм, то есть при velocity == 10
в спринт одна команда напихает 10 задач номер 1, а другая 2 задачи номер 6.
После чего команда номер 1 всю неделю копирует компоненты, а вторая уже через час идет бухать.
Кажется количество статей с названием "А как же блин правильно использовать стори поинты" в интернете много говорит о самих стори поинтах.
Мой совет на эту тему - не парьтесь используйте оценки в часах и если не путать календарное время с трудозатратами то хуже стори поинтов не будет.
Давайте еще про "полезность" планнинг покера поговорим, где все в итоге ставят свои оценки чуточку позже эксперта, который глубоко в контексте задачи. Оценки, конечно, удивительным образом с оценкой эксперта совпадают. В результате вся команда тратит кучу времени, когда могли бы или сами инженеры асинхронно проставить примерно сроки или, на крайняк, лид.
Лучшие инженерные команды, где я работал, не ходили на дейлики, не вели джир и канбанов, а трекали общие дедлайны в спредшитах, созванивались раз в неделю и писали дизайн документы для синка.
Создатель идеи сторипоинтов многократно раскаялся в содеянном. Особенно сильно он сожалел о выборе именно чисел для выражения сложности.
Мы люди простые - видим число и сразу хотим к нему применять всё то, что мы знаем о числах: сложение, вычитание, умножение.
А его идеей было просто каким-то образом выразить сложность так, чтобы можно было сравнивать единицы работы между собой, и не более того. Сравнивать не как "эта задача в 2.5 раза сложнее" просто, задача A сложнее чем задача B и проще чем задача C.
Это, собственно, главное и единственное свойство сторипоинтов.
Но мы, отталкиваясь от того что это числа, начали к этому применять кучу разных других штук - "а давайте теперь считать статистику", а "а давайте оценивать и прогнозировать производительность" и вот это всё.
Три бэклога: в одном 32 задачи по одному сторипоинту, в другом - две по 16, в третьем - одна на 32. Численно это три одинаковых бэклога. На практике - три совершенно разных, несравнимых между собой.
Где первый команда может отщёлкать на изи.
Второй - может напрячься и сделать, но может оказаться что всё не так сложно.
А третий окажется проектом на полгода.
В посте хорошо описано что такое абстрактные sp, но не очень понятно зачем они нужны – есть неувязки, про которые уже написали: про две короткие но очень сложные сеньерские задачи.
На моем опыте при оценке задач в чем-то оторванном от времени, в данном случае — в story points, как будто специально пытаются отделить задачу от текущего положения дел в команде. То есть происходит попытка ответить на вопрос:
«Насколько сложно было бы выполнить эту задачу для какого-то среднего мидла?»,
и мы всеми силами стараемся абстрагироваться от конкретных людей.
Но в реальности ситуация почти всегда конкретная:
Кроме того, есть задачи, которые сложны сами по себе, и их нельзя адекватно декомпозировать — их можно только отдать конкретному человеку, способному с ними справиться.
После этого происходит обратный процесс — мы натягиваем наших реальных членов команды на числа «для среднего мидла», и всё это выглядит как непонятная дополнительная работа.
Предлагается убрать эту дополнительную работу.
Если руководитель или члены команды понимают, кто на что способен, процесс оценки в числах можно опустить и действовать проще:
Вместо того чтобы каждый раз собираться всей командой, придумывать числа ради того, чтобы «что-то сошлось», а затем ещё и на основе этих чисел «принимать решения», мы:
Еще дополню, что за пределами команды нужен только ответ на вопрос когда это будет сделано, соответственно логично и внутри задавать этот вопрос и всем учиться наиболее четко на него отвечать.
Сторипоинты - это скам, чтобы продать побольше времени под видом меньшей сложности там где надо и vice versa.
На пространстве СНГ кроме как для основания занижения/завышения оценки на перформанс ревью не используются.
Есть даже упоротые компании сливающие на отдел фиксированное количество сторипоинтов, которое должно быть "сожжено".
В целом, когда при попытке объяснить стороннему человеку какие-то вещи, вы чувствуете себя обманутым - то сторипоинты должны быть как раз таким кейсом.
Время - понятное и прозрачное для всех участников измерение.
о, мы недавно в команде эту войну воевали. мне нравится, с каким упорством инженеры хотят избежать оценки в сроках и забывают, что бизнесу начхать на все кроме сроков и денег.
-- привет, я из соседнего отдела, когда будет релиз новой фичи чтобы мы могли ее (рекламировать, внедрять, продавать, обучать)?
-- она оценена в тридевятом спринте на 10 сторипоинтов в майке S
-- 🗿🗿🗿
Немного похоливарю.
Очень нравится когда мы от меры сложности, приходим к velocity в которой эта мера сложности не учитывается. Т.е. если конечному пользователю нужна velocity, то становятся совершенно не важны все эти приседания с оценкой и можно использовать те же часы)
Если главная задача SP декомпозиция, то не понял причем тут SP. Можно же ввести бинарную оценку - декомпозируем или нет, зачем усложнять?)
мир разработки изменится кардинально (в лучшу сторону) когда менеджеры научатся объяснять стейкхолдерам бесполезность привязки к любым оценкам, и стейкхолдеры направят все силы которые тратятся на то чтобы собирать статусы и ебать мозг о том что "опять не успели, ведь вы же обещали" в другое русло.
Спасибо за пост, но чот со "сложностью" вообще мимо, по моим личным ощущениям.
В сегодняшней команде (и в командах до этого) мы с удовольствием используем сторипоинты. Это мера количества работы, что-то вроде человеко-часов, но в игровой форме и с защитой от внешнего воздействия:
Ну и главное — знакомство с другими культурами, если повезло работать в мультикультурной команде. Где еще ты сможешь узнать, что люди с китайскими корнями могут одной рукой показывать числа до 10? А люди, выросшие в индийской культуре, считают одной рукой до 12. Кайф же, как бы я это узнал, если бы не сторипоинты.
А потом всю теорию надо подогнать под запланированные даты релизов, PO вынесет мозг, пересчитывая sp под выделенные fte, а под конец квартального планирования закинут пару фичей которые надо срочно сделать
Нужное делать, а ненужное — не делать. Хорошо делать, а плохо — не делать. Срочное и маленькое делать сейчас, никому не нужное и большое — не делать никогда.
А все попытки упихнуть всё в параллельно-перпендикулярные процессы, и потом пытаться складывать нескладываемое — это всё от лукавого.
Прочитал внимательно пост и комменты.
Пару лет поработал в команде, где это вроде бы используется.
Так нихрена и не понял.
С моей точки зрения, получилась какая-та шляпа для того, чтобы где хочется (перед релизом, например) оправдывать овертаймы и костыли заниженной оценкой, а где не надо (перед рождеством) - дружно оценивать командой элементарные задачи в пять сорри поинтов, чтобы создать для менеджмента видимость того, что мы тут делом заняты.
Хотя я и программист не настоящий. Мне все кабаны и эджайлы кажутся примерно так же оторванными от реальной жизни, как книжка про Теорию Игр. Ознакомиться интересно, но применимость на практике спорная, ибо люди нерациональны.
А ещё мне кажется, что это могло бы работать, если бы задачи нормально ставили. Но вместо того, чтобы учиться описывать задачи менеджеры в покер играют.
Вообще до момента планирования спринта все неплохо, сама идея оценивать сложность в чем-то даже изящная.
Но как обычно есть нюанс.
Сложность задачи это мера неопределенности. Чем меньше я понимаю про задачу, тем сложнее она мне кажется. И мы должны взять эту неопределенность и получить из нее время?
Отдельно хочется заметить что ни к какому фокусу на бизнес интересах стори поинты отношения не имеют, не надо их туда приплетать.
Насколько я понял идею из поста:
Сторипойнты оценивают и сложность, и время в тех случаях, когда у нас плюс-минус равномерное распределение скиллов в команде, т.е. нет большой разницы между уровнем разработчиков. Если одна задача оценена в один сторипойнт (она «простая»), а другая — в пять (она «сложная»), то вторая задача займёт условно ×5 времени у команды. Не важно, будет делать эту задачу Петя или Вася.
Если же у нас есть разнородная команда джунов, миддлов и сеньоров, и есть необходимость как-то это всё сводить к общему знаменателю — появляется необходимость забить на время и ориентироваться только на абстрактную «сложность». Если дадим сложную задачу джуну Васе — он будет занят с ней три месяца, а если более опытному Пете — он справится за неделю. Сторипойнты позволяют нам сказать «у нас есть Вася, он делает 1 сторипойнт в неделю, а есть Петя — он делает 5 за то же время. Значит в этом месяце мы можем взять задач на 24 сторипойнта, и скорее всего они будут сделаны к концу месяца, если мы будем их грамотно распределять».
Что я при этом не понял — почему «сторипойнты не измеряют время». Ну измеряют же! Не для конкретного человека, а для команды в целом. Количество сторипойнтов чётко коррелирует с затраченным временем. Если бы это было не так — их было бы бесполезно использовать.
У меня команда из случая 1 —поэтому сторипойнты нам использовать легко и приятно. Обсуждая и оценивая задачи на планнинге, мы готовим список требований, обсуждаем различные подходы к реализации, и в конце концов приходим к консолидированному мнению «эта задача займёт у любого из нас неделю» или «чёт получается много, давайте попробуем разделить на несколько задач поменьше».
Не понимаю некоторых комментаторов, которые не заинтересованы в планировании своих же собственных задач, либо сидят на бесполезных для себя планированиях чужих задач. Я получаю пользу от планнинга, потому что могу взять любую из оцененных задач и уже буду знать какие там примерно подводные камни. Если вы такой пользы не получаете — нафиг вы на планнинги ходите то?
Только в статьях про стори поинты все четко, прозрачно и понятно. Как не придешь в команду со стори поинтами: кровь, кишки, берндаун никогда не сходится, а иногда расходится)
А значит нужно в очередной раз вызвать скрам-мастеров и аджайл-коучей. А ребята и не против!
Это база. (комменты не читал и не буду)
Ну то есть сторипоинты "как надо" - еще одно определение грейда сложности задачи. С вытекающими, преимущественно в штаны. Опять же, классика словарей, difficult и hard имеют более явное разделение определений, нежели "сложная" и "тяжелая", как минимум для меня и таким же доходягам. Если мне кто-то не объяснит зачем сторипоинты даже после этого текста и моего комментария, я буду их избегать и не играть в это jira-балатро, если решение будет за мной чтобы не путать себя, заказчиков и потенциальных напарников с подчиненными.
Спасибо огромное за статью!
Очень структурированная и удобная для чтения.
Пойду считать наши спринтов по методу Монте Карло :)