Scrum - как перенести частично завершенную пользовательскую историю на следующий спринт, не искажая отставание

Мы используем Scrum и иногда обнаруживаем, что не можем полностью завершить историю пользователя в спринте, в котором она была запланирована. В истинном стиле Scrum мы все равно отправляем программное обеспечение и рассматриваем возможность включения пользовательской истории в следующий спринт во время следующего сеанса планирования спринта. Учитывая, что история пользователя, которую мы переносим, ​​частично завершена, как мы оценим ее правильно в следующем сеансе планирования спринта? Мы рассмотрели:

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

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

c) Не беспокойтесь о a или b и продолжайте гадать во время планирования спринта, говоря что-то вроде: «Хорошо, что история пользователя может быть X историческими очками, но я знаю, что она закончена на 95%, поэтому я уверена, что мы сможем соответствовать»

В моей нынешней команде мы делаем в).

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

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

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

Конечно, альтернативным вариантом (и моим предпочтением) было бы использовать исходное предполагаемое количество сюжетных моментов, что я и делал в прошлом. Это делает предположение, что ваша оценка была хорошей и обоснованной, но вы сняли слишком много работы для спринта (например, история на самом деле стоила 3 ​​балла, но проблема заключается в том, что вы сняли 15 баллов, когда Вы должны были только снести 13). Это потенциально опасное предположение, если вы не уверены в своей способности выполнить оценки, но оно может работать на основе вашей команды и процесса.

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

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

Вариант С

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

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

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

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

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

Учитывая, что история пользователя, которую мы переносим, ​​частично завершена, как мы оценим ее правильно в следующем сеансе планирования спринта?

Я не думаю, что варианты от A до C хороши, главным образом потому, что (я думаю) должно быть наиболее важным в отношении скорости команды, это ее средняя скорость, а не то, была ли скорость любого данного спринта повышена или понижена.

Когда пользовательская история определена, она должна иметь критерии приемлемости. Если что-либо в критериях принятия не сделано, то команда просто не зарабатывает ни одного из очков. Если история закончена (т.е. закодирована, протестирована и принята ПО), то команда получает все очки.

Это хорошо работает, когда команда сосредоточена на своей средней скорости, а не на заданной скорости спринта.

Как и М. Кон в своей книге, я предпочитаю сценарий «все или ничего». В конце концов, попытка оценить, набрали ли вы 5 баллов из 8-балльной истории, или, может быть, всего 6 или 7, просто окажется еще одной игрой в догадки ... и не забывайте, что вы уже получили начальную оценить путь. Вероятно, лучше просто использовать самый простой метод и получить все очки после того, как он действительно будет завершен.

Цитирую М. Кон из его книги¹ (мой акцент):

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

¹ Проворная оценка и планирование , переоценка частично завершенных историй, с.66

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

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

Объединенные оценки не должны были бы равняться исходной оценке ...

² То же, с.66

Лучшая рекомендация для команды - разбить истории на достаточно малые размеры, чтобы избежать подобных проблем3:

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

³ То же, с.67

Надеюсь это поможет.

Я удивлен, что, кажется, нет прямого ответа на это. Я ожидал хор "вариант D, дурачок"!

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

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

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

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

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

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

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

Первый вопрос, который нужно задать, - что означает сюжет? Если вы определите сюжетную точку как «Сколько работы проделано», тогда подойдет любой ответ. Однако, если вы определяете сюжетную точку как «Сколько ценности доставлено бизнесу», становится важным не давать кредит, пока история не будет на 100% завершена, принята и доставлена ​​на 100%. Изменение сюжетных моментов после спринта, основанного на том, что было выполнено, только скрывает реальную проблему: а) не было четкого понимания истории, б) история была слишком грубо определена, в) в истории отсутствовали измеримые критерии приемлемости, d ) недостаточно глубокое понимание задач или зависимостей, чтобы завершить рассказ, д) недооценил усилия, чтобы проверить историю, е) снял слишком много пунктов истории, или ж) ... укажите свою причину здесь ...

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