project team training and coaching programs, ScrumMaster certifications

2008/05/24

Unfinished work in sprints

Автор: Алексей Кривицкий.

Я когда-то написал об использовании user stories. До сих пор время от времени получаю отзывы и вопросы.

Вот к примеру вопрос, который я слышу довольно часто:
"Что делать с историями, которые не полностью сделаны за итерацию?"

На мой взгляд есть такие варианты:

1. История не полностью сделана, и сделанная часть НЕ несет выгоды для заказчика
= Business value not delivered

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

2. История не полностью сделана, но сделанная часть несёт выгоду для заказчика
= Business value delivered (but partially)

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

3. История сделана, но после найдены дефекты
= Business value delivered (but the quality/level of details is not acceptable)

В этом случае вопрос чаще стоит так - "как трекать баги, найденные после сдачи истории, и что делать с историей - переоткрывать ли или нет"?

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

Обсудить в группе дискуссий Agile Ukraine?