Можно ли корректировать оценку истории во время исполнения?

Во время исполнения

Это не идеально, но в реальном мире такое случается. И какая альтернатива? Не сообщить, что это может занять больше времени? Это не вариант. Так что да, оценка истории может измениться во время исполнения. Если это случается часто, возможно, стоит ретроспективно понять, почему это происходит.

Когда история закончена

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

Переоценка в отсутствие владельца продукта (PO)

нет . Весь смысл пользовательской истории — это общение между PO и командой разработчиков. Делать это общение в отсутствие одной части просто неправильно.

Как только спринт заблокирован, оценки заблокированы, поэтому нельзя изменять оценку после завершения планирования спринта и блокировки спринта. Есть несколько целей оценок:

1. На основе исторических тенденций - позвольте планированию спринта набрать желаемое количество очков / часов.
2. Отслеживание точности оценщиков и постоянное предоставление отзывов об их оценках с целью улучшения оценок

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

Вся работа по развитию включает в себя элемент открытия. Хорошая Scrum-команда выделит для этого некоторую резервную мощность, а не заполнит спринт настолько, чтобы не было непредвиденных обстоятельств.

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

Если команда обнаруживает, что какая-то работа выполняется дольше (или меньше), чем ожидалось, обычно есть два способа отреагировать:

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

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

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

Вы , вероятно , не захотите менять его после того, как история будет завершена. Это все равно, что сказать: «Ну, я думаю, эта задача займет 100 часов». Затем, если выясняется, что задача занимает 200 часов, вы не возвращаетесь и не говорите: «О, смотрите, мы догадались, что задача заняла 200 часов… и она заняла 200 часов! Мы идеальны!». Нет, вы предполагали, что это займет 100 часов, а на самом деле это заняло вдвое больше времени. Учитесь на этой ошибке, не притворяйтесь, что ее никогда не было. Ваши оценки никогда не станут лучше, если вы всегда будете выдумывать их как «идеальные» оценки.

Быстрые ответы:

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

2. Я бы сказал да, если применим сценарий, который я описываю ниже. Иначе нет смысла.

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

Действительный сценарий повторного указания

В наших инженерных командах мы используем приложение Agile Poker Jira. Это фантастическое решение для синхронных или асинхронных сеансов наведения.

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

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

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

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

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

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

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

Я предлагаю вам некоторые действия, когда оценка изменилась. Например:

• Достижима ли цель спринта?
• Должна ли команда сосредоточиться на других задачах, учитывая, что текущий поток работы зависит от этой?
• Сообщите всем, кого это касается (например, не только внутренней команде, если это было частью результата для заинтересованных сторон, должен быть способ сообщить им об этих изменениях).
• Если это имеет смысл: запишите детали того, почему вам нужно было изменить оценку, чтобы ее можно было использовать для получения более качественных оценок в будущем.

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

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

В конце спринта вы должны проверить точность оценки на уровне спринта и учиться. А недооценивать так же плохо, как и переоценивать.