Ребята, материалов в интернете о том, как проводить ретроспективу масса, а каждый раз приходится составлять скрипт с нуля. Буквально каждый день запускается команды, назначаются скрам-мастера, а им в свою очередь нужен простой готовый формат «делай как я», чтобы потом можно было применить на практике.

По мере подготовки сценариев, они будут публиковаться в нашем блоге и ссылки в группе в Facebook.

Сценарий ретроспективы: Первая ретроспектива.

Этот сценарий рекомендуется тогда, когда у команды давно не было ретроспективы (месяц и более) и вам нужно вдохнуть в них свежий воздух перемен.

Ретроспектива — это встреча, которая позволяет команде выявить собственные зоны роста, разработать изменения, организовать решение текущих проблем и предотвратить текущие трудности.
Цель ретроспективы: совершенствование рабочих процессов.
Время проведения: около 2-х часов
Участники: вся команда
Цели этапов ретроспективы:

1. Открытие.: «разогреть» и познакомить участников
2. Сбор информации.: создание общего контекста для текущей ситуации
3. Проникновение в суть: проанализировать причины текущей ситуации
4. Генерация идей: поиск идей для решения текущей ситуации
5. Разработка плана: выбор идеи и составление плана ее реализации
6. Закрытие: подведение итогов церемонии и завершение групповой коммуникации на позитивной ноте.

Прежде чем начать, вам нужно убедиться, что у вас есть достаточное место для того, чтобы вся команда могла сидеть по кругу и между вами не было никаких столов. Т. е. чистая комната, стулья, флипчарт и на стены есть возможность клеить листы флипчарта на малярный-скотч. Обеспечьте возможность участникам видеть и разговаривать друг другом без каких-либо препятствий. Эта обстановка побуждает, естественным образом, отказываться от ноутбуков и мобильных телефонов. Запаситесь большим количеством стикеров, маркеров и малярным скотчем.

Имаджинариум (открытие)

Для проведения этого упражнения, вам понадобятся карточки с креативными картинками.

1. Каждый участник получает по 3 карты.
2. Фасилитатор спрашивает у группы за какой период будем проводить ретроспективу? (Это может быть спринт, календарный месяц, квартал или какая-то произвольная дата, но которая что-то значит для команды)
3. Дальше за 3 минуты участники придумывают, как с помощью имеющихся картинок рассказать о том, что было за прошедший период. Важно, чтобы участники делали это молча и самостоятельно. Это индивидуальное упражнение.
4. Каждый, по очереди, в произвольном порядке, выходит перед командой и рассказывает свою историю и показывая картинки.
5. Хлопаем каждому участнику, в конце выступления, — это позволяет создать доверительную атмосферу и снимает страх выступления для интровертов.

График эмоций (сбор информации)

Рисуем график с горизонтальной линией по середине. Размечаем на нем период за который мы делаем ретроспективу с указанием промежуточных точек. Это могут быть понедельники, дни или месяца в зависимости от продолжительности рассматриваемого периода. Цель, чтобы у команды было 3-5 опорных точек, к которым они смогут привязывать свои события и понимать масштаб одинаково.

Рисуем вертикальную шкалу — это эмоции. Точка — 0, это нейтральное положение, чем выше от нее, тем сильнее положительная эмоция, и чем ниже, тем сильнее негативная. Эмоции нужно называть, чтобы другие участники могли понять, что чувствовал в этот момент выступающий и, возможно, проявить к нему эмпатию.

Формат следующий:

1. 2 минуты на подумать — молча и самостоятельно
2. По одному выходить к графику и рисовать линию, как изменялась его эмоциональное состояние на протяжении указанного времени
3. В точках, где настроение стало расти, падать или идти ровно, нужно спрашивать, а что там было. Записывать факт (упал стенд, был в отпуске, остался без поддержки, выпустили релиз и т. д.) этого события и клеить стикер в место, когда он случился.
4. Группа при этом может задавать уточняющие вопросы. Дискуссия идет только между выступающим и одним из участников. Беседы между участниками, нужно пресекать. У них будет время это все обсудить.
5. По результатам у нас получается общая карта настроений команды и факты, которые имели место быть у команды. Этим мы собрали информацию из каждого, получили объективную картину команды на произошедшие события, помогли им вспомнить или узнать, что было.

Пять Почему. (проникновение в суть)

1. Собираем все негативные факты, что удалось собрать на предыдущем этапе и клеим их в один вертикальный ряд
2. Делим участников на группы по 3 человека:
   • кол-во участников делим на 3.
   • Округляем до целого в меньшую сторону.
   • Просим по порядку рассчитаться от 1 до вычисленного числа.
   • Указываем группе места, где с каким номером нужно собраться людям с одинаковым номером
3. По каждому факту (сверху вниз), нам нужно понять корневую причину. Этим займутся группы. 3 минуты на написание одной корневой причины от группы на стикер.
4. Фасилитатор составляет таблицу со столбцами Номер, Факт, Корневая причина, Решение, Ответственный, Срок выполнения.
5. Представитель от каждой группы выходит к таблице и на группу рассказывает, какую они корневую причину возникновения данного факта нашли. После этого клеит стикер в строку соответствующего факта. Выслушиваем представителей от всех групп. Фасилитатор допускает дискуссию только между выступающим и один из представителей группы. Лучше придерживаться формата уточняющего вопроса.

1+1 = 1 (Генерация идей)

Прежде чем начать придумывать решения, нам нужно прогреть нейросеть участников в направлении креатива. Для этого предлагается использовать упражнение 1+1=1. Метафора такая: если мы соединим одну каплю с другой, то в результате у нас будет не две капли, а одна.

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

Brainstorm (разработка плана)

1. Проводим голосование группы за карточки с фактами. Каждый участник ставит не более 3-х точек за карточки, которые для него наиболее важные. Один человек может поставить только одну точку на одну карточку
2. Подсчитываем голоса и сортируем их по убыванию в нашей таблице.
3. Договариваемся с группой, сколько проблем мы хотим разобрать на сегодняшней ретроспективе с учетом оставшегося времени
4. По каждой проблеме, в тех же группа за 3 минуты придумываем, обсуждаем и записываем на стикеры решения, которые помогут решить соответствующую проблему. Фасилитатор помнит, что участники пишут одно решение на одном стикере и открывают стикеры в блок или вниз, чтобы не топорщились прикленными. Количество предлагаемых решений — ограничено здравым смыслом
5. Представитель каждой группы выходит и выклеивает все найденные решения, группа может задавать уточняющие вопросы
6. После того, как все выступят, фасилитатор задает вопрос группе: «Хочет ли кто-то взять на себя ответственность за какое-либо решение?»
   • Если доброволец найден, спрашиваем какое решение он/а готов на себя взять, рядом с этим решением записываем его Имя и Фамилию и срок, когда он это сделает
   • Если не найден, то спросить группу почему они не хотят брать на себя ответственность, возможно это, либо низкая зрелость группы и тут нужна помощь Лидера группы (это может быть скрам-мастер, владелец продукта, мастер потока и т. д.), либо решение лежит вне зоны контроля или влияния команды и ее нужно эскалировать наверх (договориться, кто это сделает)
   • Решение может быть коллективным и бессрочным. Какая-то хорошая практика (всегда читать полностью задачу, заносить все в Jira и т. д.). В этом случае применяем упражнение Римское голосование. Спрашиваем группу: все ли готовы выполнять новую практику. Палец вверх — я согласен, Палец горизонтально — я соглашусь с большинством, Палец вниз — я не согласен. Если несогласных нет — то решение принимается, а иначе нет и переходим к следующему пункту.
7. Смотрим на время, если до конца ретро осталось меньше 15 минут, то переходим к следующем этапу, если больше, то берем следующий по важности вопрос и прорабатываем уже его.

Ретро ретро (закрытие)

Ретро, как и любая другая активность нуждается в улучшении и подстройке под каждую конкретную команду. Фасилитатору это помогает подбирать соответствующие упражнения для группы. Кто-то отказывается от разминок, кто-то просит в следующий раз чего-нибудь новенького и т. д. Каждая команда уникальна.

Ну и конечно, это в каком-то виде обратная связь от группы к проведенному мероприятию

Спасибки (закрытие)

Открытие, как и закрытие ретроспективы должно проходить на сильных позитивных эмоциях, которые сплочали бы команду. На этом упражнении не должно быть дискуссии. Каждый по очереди говорит кому конкретно он хочет сказать спасибо и за что. Фразы: «всей команде», «всем спасибо» — не годятся.

После того, как все воспользовались возможностью сказать Спасибо, все хлопают в ладоши и расходятся в хорошем настроении.

——
Друзья, успехов вам, в фасилитации ваших ретроспектив!

Представьте, что вы отвечаете за организацию цепочки поставок и продаж в продуктовом магазине. Давайте для определенности считать, что речь идет об вкусных йогуртах. У вас есть производитель, поставляющий определенный объем продукции, есть склад (ну очень бОООльшой) и обычная магазинная витрина, откуда покупатели разбирают упаковки к себе в сумки. Она имеет конечный размер и может разместить сравнительно небольшое число упаковок продуктов. Как бы вы договорились с поставщиком об объемах регулярных поставок?

В этой системе есть WIP лимит, определяемый размерами самой витрины. Больше, чем она может вместить, ничего выложить не получится (просто некуда). Если поставлять продуктов меньше, чем раскупается, то на полке периодически не будет ничего, а значит будет потеряна прибыль и клиенты (кому понравится магазин, где ничего нет). Если заранее заказать больше упаковок, чем можно продать, скажем, за день, то складские остатки начнут увеличиваться и, как минимум, «заморозят» свободные деньги или, как максимум, со временем продукты испортятся. Важно сделать так, чтобы скорость поставок была синхронизирована со скоростью потребления.

Конечно можно попытаться компенсировать рост поставок, выкладывая в торговый зал больше упаковок (например на пол, соседнюю витрину). Однако поднимать таким образом продажи это тоже самое, как добавлять в принтер больше бумаги, в надежде на увеличение скорости печати. У системы есть свойственная ей скорость (потребления, печати и др. ), которую нельзя бесконечно стимулировать «впихивая невпихуемое». Этот подход называется проталкиванием (PUSH) когда в систему сначала «закачивают» элементы работы, а потом думают, что с этим делать.

Альтернативным вариантом является «вытягивающася» система, которая в 50е годы была подсмотрена начальником механического цеха компании Тойота Тайити Оно во время его поездки в США. По его воспоминаниям идея вытягивания (PULL) в магазине как раз в момент осмотра подобной витрины. Этот человек (к слову создатель Toyota Production System) обратил внимание, что система работает в обратную сторону: вначале покупатели разбирают продукты на полке, а уже потом сотрудники магазина пополняют со склада ровно столько, сколько было куплено за день и на основании этих данных делают заказ на склад. По его возвращении на родину этот принцип лег в основу работы с Канбан доской: вначале проверяются те элементы работы, которые расположены как можно ближе к концу процесса и только после освобождения соответствующего WIP лимита переходим к предшествующим этапам (прямо как в игре в «пятнашки»). Другими словами перед тем как начать делать что-нибудь нужное, сначала завершить то, что вам казалось нужным нужным до этого.

Принцип вытягивания нашел свое отражение не только в Канбан. Его следы также видны и в SCRUM. Так в Планировании Спринта Команда разработки сама прогнозирует задачи, которые могут быть сделаны в предстоящем спринте (вытягивание), а не автоматически получает их от Владельца продукт согласно заранее предопределенному «нормативу» или текущей необходимости (проталкивание).

Вытягивание, в принципе настроено на поддержание командой её естественного ритма, когда нет авралов и переработок (состояние потока). Конечно иногда бывают моменты когда нужно «поднажать» и достигнуть краткосрочных целей. Но принцип вытягивания помогает соответствовать долгосрочной цели, которая лучше всего написана в тексте манифеста Agile разработки программного обеспечения: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно».

Когда вам необходимо оценить сколько времени потребуется на решение той или иной задачи, есть два разных подхода:

1. Аналитический. Разложить задачу на элементарные составляющие, оценки которых обычно не составляют труда, и сформировать из них интегральную оценку;
2. Эмпирический. Обратиться к предыдущему опыту и посмотреть сколько времени тратилось на подобные задачи в прошлом;

Использование аналитического подхода является популярным, но у него есть свои ограничения, снижающие возможности. При декомпозиции можно «забыть» какие-либо не очевидные на этапе оценивания задачи. Часто оценивающий становится «жертвой» со стороны манипуляций заказчика, желающего получить из него «приемлемую» для себя оценку. Бывает, что избыточная декомпозиция вместо улучшения оценки приводит, наоборот, к снижению точности оценивания и т. д.

Эмпирический подход подразумевает иной способ прогнозирования. Представьте себе, что вам на работе назначили встречу на 9 утра и вам «до зарезу» необходимо попасть на нее вовремя (не раньше и не позже). В итоге вы пытаетесь определить во сколько нужно выйти из дома. Можно поступить как в предыдущем случае и прикинуть количество остановок транспорта и среднее время его движения между ними. Кто-то еще вспомнит, что у транспорта есть свой интервал ожидания, кто-то добавит, что вообще-то до остановки и от нее тоже нужно время чтобы дойти. Но мы же обычно делаем по-другому: из своего ежедневного опыта мы знаем, сколько времени нам нужно, чтобы доехать до работы.

Поскольку, мы повторяем этот опыт каждый день, то эти данные намного надежнее любых вычислений. И самое главное: они учитывают все «неизвестные» и/или «забытые» факторы, такие как необходимость спуститься на улицу из дома и подняться к себе на лифте в офисе (в некоторых организациях в час пик это, кстати, нетривиальная задача), раздеться, дойти до переговорной команды и т. д.

Значит ли это, что эмпирический подход всегда лучше? При всей его красоте, у него тоже есть свои ограничения. Пожалуй, наиболее заметное — это необходимость наличия опыта для сравнения. Если с подобной задачей вы еще не сталкивались ранее, и не можете её сопоставить ни с чем известным для вас, то такой подход конечно «не взлетит».

Использование обоих подходов требует применения подходящих инструментов. В аналитическом способе, мы применяем оценку во времени, но что делать в эмпирической парадигме?

Если посмотреть на любую зрелую организацию, то у нее есть одна или больше оптимизационных целей. Т. е. это такая цель, с оглядкой на которую строится дизайн организации — это, и организационная структура, и внутренние процессы, и конечно определенный профиль людей.

Так вот, часть трансформации, это смена такой оптимизационной цели, которая должна влечь за собой и изменение входящих в нее атрибутов.

В качестве примера часто приводят Карьерный грузовик, который собой представляет организацию или ее часть. Он большой и у него есть определенная задача работать на карьере и возить руду, как можно эффективнее. Т. е. для него наша оптимизационная цель состоит в том, что его время нам нужно утилизировать максимально эффективно. Некоторые параметры на которые мы смотрим: время его работы без поломок, стоимость затрат на одну тонну руды.

И вот мы загорелись идеей больших гонок, очень понравились проворные ребята на красивых болидах Формулы-1. Начинаем сравнивать время замены колес и видим, что в рекорд смены колес в Ф1 меньше 2 секунд (секунд Карл!). А наш грузовик поменяет колесо за два дня и это нормально, так как это не частая операция. А что с командой обслуживающих машину? Так они вообще почти все время просто стоят и ничего не делают! Какой вопиющий пример неэффективного использования ресурсов! А наши техники всегда при деле.

Теперь, мы видим что наша машина чем-то похожа на болид: 4 колеса, водитель который может гибко менять маршрут следования, значит мы можем устраивать гонки, но вот колеса меняем медленно. И мы хотим что-то наши техники научились менять наши колеса быстро.

Здесь становится очевидно, что если наша цель максимальная утилизация ресурсов, то достигнуть быстрой смены колеса мы не сможем. Соответственно, нужно менять весь подход работы начиная от новой организационной структуры до обучения новым навыкам людей.

Какие цели могут быть:

1. короткий T2M
2. больше денег
3. выжить
4. обогнать конкурентов
5. утилизировать работу сотрудников
6. сократить расходы
7. повысить предсказуемость
   и т. д.

Гонки, замена колес, победы — это все хорошо, но что делать если у нас поезд?....

UPD: Две цели были зачеркнуты по следующим причинам:

• Больше денег — это как гигиенический фактор коммерческой организации, без этого у нее нет шансов стать зрелой
• Сократить расход — это локальная бизнес цель, которая не может быть оптимизационной целью, так как в этом случае, лучший вариант ее достижения будет полное уничтожение компании. Нет компании — нет расходов.

Слово канбан стало широко распространено в мире и им стали называть все подряд. Давайте разберемся какие варианты есть:

1. кан-бан (с маленькой буквы) — это визуальная доска или сигнальная карточка, в переводе с японского
2. канбан — как доска, и называют ее канбан-доской ее еще используют как информационный радиатор
3. канбан — как виртуальная доска для управления интеллектуальной работой
4. Канбан (с большой буквы), как метод эволюционных изменений называемый Канбан-метод
5. канбан — как вытягивающая система, которая начала применяться еще на производстве Toyota внутри процесса Кайдзен (непрерывное улучшение)

Канбан метод был создан под впечатлением именно от сигнальных карточек, чем от визуальных досок. И собственно, именно сигнал основной движущий вытягивающий механизм элементов работы через канбан-систему.

А что вы имеете ввиду, когда произносите слово «канбан»?

В прошлый раз ( http://kanban.club/all/wip-limit/ ) мы говорили о применении WIP лимита в качестве инструмента для управления производительностью отдельного этапа конвейера. Теперь поговорим о том, как WIP лимит можно использовать для настройки всей производственной цепочки.

Представьте, что ваша производственная система похожа на конвейер, чей технологический процесс содержит несколько этапов. Допустим, что каждый из его участков работает в соответствии с WIP лимитами, настроенными так, чтобы каждый из них находился на максимуме своей пропускной способности. Означает ли это, что теперь конвейер работает как надо? Не совсем.

В любой реальной системе пропускная способность отдельных этапов различается и сама по себе является переменной величиной. Практически наверняка в такой системе перед местами с наименьшей пропускной способностью начнут формироваться очереди. Это обстоятельство имеет сразу несколько негативных сторон:

1. рост времени обработки. В соответствии с законом Литтла, который мы обсудили в первой части, время нахождения элемента работы в системе прямо пропорционально числу таких элементов. Например, чем больше статей одновременно вы пишите в kanban.club, тем дольше будет писаться каждая из них по отдельности:)
2. потеря актуальности/порча элементов работы/хранение из-за долгого нахождения в очереди. Это может быть что угодно: от бизнес требований заказчика до парного молока.
3. снижение оборачиваемости капитала. Любое незавершенное производство означает, что потраченные на него деньги еще не скоро вернутся в компанию. При этом не стоит забывать, что деньги сами по себе тоже имеют стоимость в виде процентной ставки по банковским кредитам.
4. скрытые проблемы производства. Наличие внутренних очередей затрудняет диагностику проблем. Например, если в ней есть элемент работы, содержащий дефект, то выявить их удастся только тогда, когда до такого элемента работы дойдет очередь обработки. Все это время ожидания проблема будет находиться без решения.
5. отложенная прибыль. Чем позже мы получим продукт, который можно продать на рынке, тем меньше мы получим прибыли, не так ли?

Но можно ли избежать таких «узких мест»? Они есть в любом реальном конвейере и их наличие говорит о том, что конвейер скорее жив, чем мертв. Вопрос не в том, как их избежать, а как научиться с ними работать.

Пропускная способность всей системы ограничивается самым узким местом этой системы (см рисунок). Попытка выжать максимум на каждом этапе конвейера приведет только к потерям из за формирования ненужных очередей. Как это ни парадоксально, но работа на 100% загрузки вне узкого места может приносить вред, а не пользу.

Делать ей было совершенно нечего, а сидеть без дела, сами знаете, дело нелегкое. Алиса в стране чудес (Льюис Кэрролл)

Такое случается, когда каждый этап конвейера сфокусирован на оптимизации своей работы без оглядки на вопрос «как это выглядит с точки зрения всей системы?». Это носит название «локальная оптимизация» и является распространенным примером, когда «добрыми намерениями, дорога в ад выстроена». Каждый элемент производственной системы должен производить скорее не «столько, сколько может», а «столько, сколько нужно». Идеальная система должна уметь перераспределять избыток мощности на те участки, где она необходима. Вот где концепцию T-shaped people сложно переоценить.

Алгоритм «настройки» такой системы может проиллюстрировать на примере Пяти Направляющих Шагов Теории Ограничений Элияху Голдратта (см. Eliyahu M. Goldratt, Jeff Cox. The Goal: A Process of Ongoing Improvement):

1. Найти ограничение системы. Узкое место, перед которым формируются наибольшие очереди нашего конвейера и будет тем самым ограничением системы, с которого мы начнем настройку.
2. Решить, как максимально использовать ограничение системы. Помните сколько стоит простой системы в узком месте? Следовательно именно здесь нам важно вывести участок на «пик формы». Механизм нам уже известен из предыдущей статьи — нужно подобрать значение WIP лимита при котором этот этап конвейера обладает максимальной пропускной способностью, но при этом сохраняет приемлемое значение времени обработки. По сути узкое место будет единственным участком, где мы сознательно добиваемся максимума утилизации ресурсов. Безусловно использование WIP лимита не отменят использования любых других доступных и приемлемых для вас средств оптимизации в этом месте.
3. Подчинить все остальное этому решению.
   В отличие от предыдущего этапа все участки конвейера до узкого места должны производить только то количество работы, которое может быть обработано узким местом. Для этого WIP лимиты на эти участках должны быть «зажаты», чтобы не формировались запасы незавершенного производства. Обратите внимание, что на этих этапах окажутся недоиспользованные ресурсы (ведь там раньше был избыток мощности, верно?). Не беспокойтесь, мы подумаем и об этом :)
   Помните мы говорили, что пропускная способность это переменная величина? Узкое место — не исключение. Для компенсации таких колебаний перед ним можно предусмотреть небольшую очередь, которая будет буфером, обеспечивающим узкое место работой если в нем появится избыток мощности.
   А что будет на участках после узкого места? Их пропускная способность заведомо выше и следовательно наша цель здесь уменьшить WIP лимиты, обеспечив быстрое время обработки и высвободив «лишние» ресурсы
4. Расширить ограничение (ограничения) системы. Теперь, когда система функционирует без внутренних запасов, дополнительный рост пропускной способности можно сделать либо улучшив технологию обработки в узком месте, либо перераспределив «избыточные» ресурсы, освободившиеся в предыдущем этапе в узкое место. Лучше делать и то и другое.
5. Вернитесь к шагу 1. Поздравляю, теперь Вы получили настроенную систему, но так ли это на самом деле? В результате наших действий система поменялась. Теперь узкое место может переместиться, а значит процесс улучшения будет циклическим.

Вы можете не изменяться. Выживание не является обязанностью. Э.Деминг

Канбан — это сосредоточение на организации интеллектуальной работы, для удовлетворения потребностей клиентов, путем эволюции сервисов с применением простых практик. Позволяет большим группам людей достигать общей цели. Имеет низкие координационные издержки, даже для распределенных команд.

Scrum — это организационный дизайн компании, оптимизационные цели которого низкий T2M, обучение и работа над самым важным в каждой итерации в небольших кроссфункциональных командах (бизнес и технические специалисты сидят вместе)

Так как story points представляет собой размер усилия, которое необходимо приложить, чтобы сделать User Story.

Соответственно, командная оценка необходимого усилия может включать в себя все что угодно. Например, это может быть:

1. Объем работы
2. Сложность
3. Риск или неопределенность

Когда даете оценку в story points убедитесь, что учли влияние всех указанные факторов.

Обратите внимание, что это именно командная оценка, на всю User Story, которая несет ценность для клиента и удовлетворяет DoD (Definition of Done — прозрачному определению, что значит «Готово»)

Давайте разберемся, какие оценки бывают: абсолютные и относительные.

Для чего мы их делаем? Чтобы сделать прогноз на поставку, какой-то ценности. Так? Но, сама эта работа, для точной оценки интеллектуальной работы, требует больших усилий в том, чтобы её подсчитать, а потом и управлять ей.

Очевидно, что такая работа не приносит ценности нашим заказчикам и является потерями, от которых надо избавляться.

Почему не надо делать оценок?

Давайте рассмотрим случай, когда разработка у нас не самое узкое место в нашей системе, тогда нам нет смысла оценивать, потому что все что попадает на вход — будет сделано.

Другой вариант, что разработка узкое место, тогда нагружая его работой по оценке, мы только еще больше уменьшаем его производительность, что негативно сказывается на всей системе в целом.

А как же анализ?

А вот анализ задачи участвует в цепочке создания ценности. Это помогает нам сделать декомпозицию задачи и сделать стратегию по интеграции декомпозированных компонентов в один ценностный рабочий элемент на выходе.

При этом, если нам нужно дать прогноз на поставку, то здесь нам помогут относительные оценки. Эту оценку можно называть как угодно, лишь бы не часы, минуты, дни и т. д. Обычно это стори-поинты, но могут быть хоть попугаи.

> Напомним, что прижились несколько видов числовых ряды для оценок:
> На основе мутировавшегося ряда Фибоначчи: 1, 2, 3, 5, 8, 13, 20, 40, 100
> Так и степень двойки: 1, 2, 4, 8, 16, 32, 64, 128

Относительные оценки, служат для выработки договоренности внутри команды о размере того или иного рабочего элемента (как частный случай, это может быть user story). Причем, размерность дана таким образом, что разница между числами от 50 до 100%, и основной фокус обсуждения идет не о том, что это 7 или 8 стори-поинтов, а о том, что мы сравниваем задачи относительно друг друга (новую с набором уже сделанных задач нашей командой) и много говорим, для того чтобы совместно выявить максимум рисков и сделать прогноз, когда мы можем это сделать.