Скрам переоценка историй

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

Это то, как мы это делаем:

Рассказ Оценка: 24 часа (8 часов в день - мы используем «идеальные дни» в качестве меры)

• День N: разработчик начинает работать над историей А утром (8 часов работы завершены к концу дня)
• День N + 1: переоценка Истории А = 16 часов (один рабочий день вынут из Истории А, со дня N)
• День N + 2: переоценка Истории A = 8 часов (один рабочий день вынут из Истории A, со дня N + 1)
• День N + 3: Рассказ А должен быть уже сделан. Но это не так. Разработчик считает, что это займет еще 3 часа, чтобы закончить. Мы обновляем историю на доске и Burndown соответственно.
• День N + 4: История А заняла весь день, а не только 3 часа! Теперь это сделано. Разница в 5 часов совершенно не учитывается при планировании.

Как мы должны ежедневно переоценивать наши истории?

Разница в 5 часов совершенно не учтена в нашем планировании.

Да, это учитывается косвенно, потому что следующие задачи откладываются. Если бы для этого разработчика существовал график выкатов, вы бы заметили, что кривая осталась «плоской» в течение одного дня, а затем пошла бы вниз, если бы разработчик закончил ее достаточно рано, чтобы выполнить другую задачу.

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

Вопрос, который вы должны задать: мы должны переоценивать наши истории?

Я бы сказал, что вы должны позволить Agile-«магии» уравновесить ваши заниженные и завышенные оценки за одну итерацию при расчете вашей скорости для следующей (что является единственной причиной для корректировки значения). См. Проворную Оценку и Планирование Майка Кона для получения дополнительной информации.

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

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

То, что я нашел наиболее эффективным, это:

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

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

Как вы описали в своем вопросе, ежедневные переоценки того, что осталось, как правило, являются полностью поддельными. Завершенная / оставшаяся работа - это поддельное число, созданное для того, чтобы выглядело так, будто вы работаете «достаточно усердно». Гораздо лучше спросить: «Как вы думаете, когда вы закончите?» И дать понять, что если в истории есть проблемы, то команда поможет вам.

Я думаю, что это не проблема. Скорее это может быть недостаток опыта. Чем больше вы следите за схватками, тем больше разработчики привыкли предоставлять более точные оценки. Это наш опыт внедрения scrum через 5 месяцев.

При планировании покерных сессий наши разработчики предлагали очень разные оценки для каждого PBI и каждой задачи в первом спринте. Однако сейчас мы практически равны по времени и оценке. Как долго вы используете скрам? Если не так много, дайте ему немного времени. Но если это долго, то, как предложил @pdr, рассмотрите возможность добавления дополнительной маржи для задач с более высоким риском . Например, каждый раз, когда наша команда хочет создать кросс-браузерную часть пользовательского интерфейса, мы передаем нашу оценку. Таким образом, мы всегда умножаем оценку кросс-браузерных задач на коэффициент, чтобы быть уверенным, что сможем его охватить.

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

Другая ситуация с пользовательскими историями, которые не привязаны к текущему спринту. Время от времени полезно проводить переоценку (не более одного раза за спринт до планирования). Ситуации, которые могут быть разумными для переоценки, могут быть:

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

Вам не нужно обязательно переоценивать каждую историю пользователя, но вы можете. Для полной переоценки вам обычно нужен быстрый метод. Планирование покера может быть чертовски медленным, неэффективным, скучным, а иногда и неточным, если вы оцените более 10-20 историй. Альтернативой может быть оценка Магии .