Scrum - Когда вы оцениваете усилия для элементов отставания продукта?

Ответ 1

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

Оценка проекта/Дорожная карта (Уровень истории)

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

В настоящий момент оценка каждой истории выполняется с использованием не часов, дней или недели, а относительной единицы измерения (которая одновременно включает в себя усилие, сложность и риск), например, сюжетные точки. Для этой фазы мы используем шкалу Fibonnaci и Planning Poker. Важно, чтобы вся команда активно участвовала в этом процессе.

После этого команда должна угадать, сколько историй они могут выполнить в первом спринте, который будет их начальной оцененной скоростью (точки/итерация). Как правило, лучше не использовать однодневные спринты, а скорее 2-недельную или 1-недельную спринтерскую длину, чтобы улучшить точность оценки. Первое планирование обычно занимает целый день или даже 2 дня, в зависимости от размера отставания, размера команды и длины спринтов.

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

У вас должно получиться что-то вроде этого:

PROJECT ACME ROADMAP

SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)

SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)

SPRINT 3 (39 points)
--------
...

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

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

Оценка спринта (уровень задания)

Вторая часть фазы планирования для каждого спринта проводится, разбивая каждую историю на задачи. Здесь задачи должны носить весьма технический характер и оцениваться с использованием часов. У нас есть политика, которая, если задача оценивается дольше 8 часов, тогда ее нужно разбить на более подробные задачи независимо от того, что. Результатом будет отставание от спринта, с задачами, сгруппированными по сюжету, и диаграммой сжигания спринта, где ось X/Y должна быть днями спринта и часов соответственно.

Он должен выглядеть так:

Sprint 8
--------
Story 17
  Task 1: 8 hours
  Task 2: 6 hours
  Task 3: 2 hours

Story 18
  Task 1: 8 hours
  Task 2: 6 hours

Story 19
  Task 1: 6 hours
  Task 2: 3 hours
...

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

Ответ 2

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

Наше планирование спринтов, как правило, занимает время в 2 часа в начале нового спринта. Это когда мы встречаемся с владельцем (-ами) продукта и выбираем элементы из отставания, большинство из которых грубо оцениваются и правильно расставляются по приоритетам. Отсутствующие оценки выполняются на месте, а затем мы выполняем "мелкомасштабную" задачу рассказов в течение этого временного окна (обычно это довольно интенсивная работа), используя тот факт, что остальная часть компании знает об этом и PO и заинтересованные стороны могут разобраться в неучтенных деталях.

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

Сбой в задачах
Мы просто используем количество задач для нашей меры сжигания. Обычно вы делаете что-то вроде фактических часов или идеальных часов, но это было достаточно хорошо для нас и, по-видимому, достаточно интересно, чтобы получить какое-то разъяснение.

Мы не оцениваем время на эти задачи, все, что имеет значение, - это оценка сюжетной точки (приблизительная оценка) по истории, которую мы вставляем в идеальные человеческие дни.

Как эта история делится на задачи, это скорее распределение команд и общий индикатор прогресса, а не точная оценка часов для нас.

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

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

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

Ответ 3

В настоящий момент мы производим подробные разбивки задач и оценки до начала спринта. Это по двум причинам:

1) Наш бизнес хочет, чтобы оценки помогли им решить приоритет.

2) Команды разработчиков находятся под давлением, чтобы выполнить оценки и не отклоняться от естественного ожога.

По-моему, это неправильный подход, поскольку он устраняет способность быть подвижным. Я думаю, что этот процесс должен быть таким же...

1) Бизнес должен использовать номера фибоначчи, созданные во время совещания по планированию, чтобы помочь им определить приоритет. Или, по крайней мере, только ожидать оценки "пальцем в воздухе" от команды разработчиков.

2) График сжигания следует рассматривать как руководство к тому, как продвигается проект, чтобы указать, нужно ли добавлять больше PBI или снижать приоритеты, а не как "целевую" цель того, что будет завершено.

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

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