Можно ли предсказать, когда скрам-команда завершит бэклог продукта?

Если вы можете получить 2-3 спринта на скорость, как рекомендует Дрю Джордан, это лучший способ. При этом реальность часто застает нас перед руководством, которое спрашивает: «Когда вы можете закончить», еще до того, как работа началась. На этот случай есть хорошо работающий метод, которому я научился в Agile Learning Labs.

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

Шаг 1: Выберите разумные сроки выпуска. Если вы занимаетесь agile, то вам следует выпускать релизы максимум каждые три месяца. Если нет, вы теряете большую часть ценности agile, а также вам будет трудно применять agile, когда нет реальной обратной связи. Это также напрямую решает проблему предостережения, перечисленного выше.

Шаг 2: Оцените отставание. Как упоминалось в Предостережении, это должно произойти, чтобы иметь возможность прогнозировать дату выпуска.

Шаг 3: Спланируйте теоретический первый спринт. Теперь это не управление, назначающее истории спринту. Это честная команда самоорганизованного планирования. Возьмите первую историю из бэклога, и команда спросит себя: «Думаем, мы сможем сделать это за спринт (он длится две недели, верно? :) ). Затем повторите это. Продолжайте делать это, пока команда не справится». Они даже близко не чувствуют себя комфортно от того, что могут завершить историю. Это КЛЮЧ. Если хотя бы один человек считает, что это невозможно сделать, тогда остановитесь и не добавляйте историю. На этом этапе лучше недооценить, чем переоценить. .

Шаг 4: Проекция. Сложите баллы за планирование спринта. Теперь разделите общее количество очков истории в выпуске (помните, что ваша цель — не более трех месяцев). На данный момент у вас есть, сколько спринтов потребуется для завершения работы. Если это более трех месяцев работы, релиз, вероятно, слишком большой, и вам следует посмотреть, что действительно необходимо.

Шаг 5 Подкрепите это ПРОГНОЗОМ. Когда вы даете оценку времени, укажите это как «У нас есть 60% уверенности в этом графике». Затем добавьте к этому следующее: «После нашего первого спринта этот показатель должен вырасти до 70%, а после нашего второго спринта — до 80%. К третьему спринту у нас должна быть 90% уверенность в том, какой будет наша окончательная дата отгрузки или что мы сделали. если дата отгрузки должна быть привязана к определенному календарному моменту».

У вас никогда не будет уверенности более 90%, не пытайтесь. Мать-природа и Мерфи обожают связываться со всеми, кто говорит: «Я на 100% уверен».

Вы можете оценить дату завершения, диапазон дат, завершенный спринт и т. д., разделив текущий размер невыполненной работы (в SP) на текущую скорость команды, но...

1. Обязательно напомните всем, кто просматривает ваш прогноз, что это оценка.
2. Быстро проверьте, насколько изменчива ваша скорость. Какова скорость последних 3 итераций команды? Текущая итерация? Общая продолжительность проекта? Сильно изменчивая скорость должна побудить вас снизить уверенность в любых результатах долгосрочного прогнозирования.
3. Перечислите все свои предположения и метод, который вы использовали для получения прогноза, прежде чем представить свои цифры. Убедитесь, что ваша аудитория понимает влияние предположений, которые вы должны были сделать.
4. Будьте честны в своей уверенности в предоставлении прогноза
5. Попробуйте указать диапазон дат, а не конкретную дату с лучшими, средними и худшими числами. Вы можете придумать что угодно с симуляциями Монте-Карло и такими инструментами, как Crystall Ball, если хотите.
6. Используйте свои сценарии как возможность повысить риски
7. НЕ берите на себя никаких долгосрочных обязательств по срокам, основываясь на ваших прогнозах. Прогноз следует использовать в первую очередь как инструмент для обсуждения и выявления рисков/недостатков, которые необходимо устранить для удовлетворения потребностей клиента на высоком уровне.

Стоит помнить, что Scrum — это agile-фреймворк, а agile — это реакция на изменения.

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

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

Да, это именно то, что вы должны сделать. Я бы рекомендовал использовать как минимум 2 спринта, а лучше 3, чтобы определить среднюю скорость.

Также важно сформулировать это с точки зрения вероятности: если ваша скорость равна 5, а есть 20 баллов, то вы, вероятно, закончите после 4 спринтов. Если только объем не изменится, не произойдет что-то непредвиденное, материализуется риск и т. д.

Что бы я сделал, так это то, что элементы, которые не полностью определены, делают все возможное. Обеспечить диапазон прогноза (например, 4-6 итераций). Это дает вам некоторое пространство для изменения масштаба или чего-то еще, что может произойти, а ваши заинтересованные стороны дают оценку завершения. Укрепляйте идею о том, что они могут изменить дату завершения в любом направлении в зависимости от меняющихся требований или объема работ, если они почувствуют в этом необходимость.

Если вам нужно что-то более научное, вы можете взглянуть на формулы PERT . Это может дать вам статистическое представление о том, когда проект будет завершен, и насколько вероятна эта оценка. Это полезно, когда ваши руководители требуют больше конкретики, чем «4-6 спринтов», но также позволяет вам постоянно напоминать им, что это вероятность, а не данность.

Вы можете сопоставить скорость вашей команды с невыполненной работой и получить оптимистичные и пессимистичные даты выпуска.

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

У меня есть хороший опыт оценки Agile Monte Carlo, например https://agilemontecarlo.com . Простого учета средней скорости недостаточно, чтобы получить профиль риска проекта. Особенно полезно знать смоделированные даты доставки 25% и 75% для общения с заинтересованными сторонами.