Должны ли продукты и задачи продукта отставать от разных путей итераций?

Question

Используя шаблон процесса Scrum 2.1, я заметил, что запрос Sprinter Backlog в TFS возвращает список элементов и задач для отставания продукта для спринта, но список выглядел довольно редко, когда я просмотрел его. Немного поразмыслив в определении запроса, я понял, что он сначала сопоставляет дочерние ссылки и фильтрует детей на основе итерации. Это имело значение из-за того, что нескольким задачам не была назначена итерация, и поэтому они сидели в отставании.

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

Answer 1

Когда вы дойдете до конца Sprint и 3/4 PBI были выполнены и приняты, а окончательный PBI имеет 2/3 задачи, которые были полностью реализованы, вы должны принять некоторые трудные решения. Вы:

a) попытаться сорвать код этого последнего PBI?

b) вызвать весь Спринт сбой и начать все заново?

c) переместить незавершенную дочернюю задачу на следующий спринт?

Это поддержка опции (c). Вероятно, это не то, что рекомендовал Scrum.org, но это тот сценарий, который он поддерживает.

Answer 2

Это зависит от того, как вы используете TFS для планирования своих спринтов. Если вы намерены использовать всю полноту функций TFS 2012 Agile Planning, вам необходимо поддерживать итерации рабочих элементов. Особенность платы Scrum не зависит от накопившихся запроса Sprint (или любые другие вопросы, если на то пошло), она находится под контролем scheduling and areas settings в администрации команды (доступны в Home команды):

Итерация зависит от размера PBI: если PBI, включая все его дочерние задачи, может входить в один спринт, итерация должна быть установлена ​​на спринт (например: \Release 1\Sprint 4\).

Если PBI достаточно большой, чтобы выполнить несколько спринтов для завершения, сохраните свою итерацию на уровне выпуска (например: \Release 1\) и его дочерние задачи до уровня спринта.

Answer 3

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

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

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

Если вы часто сталкиваетесь с этой ситуацией, подумайте о том, чтобы разложить ваш PBI на более мелкие блоки работы. Помните, что идеальный размер PBI находится в течение 3-5 дней (3 Story Points в моем масштабе) или меньше диапазона к тому времени, когда вы доберетесь до точки PBI до спринта.

Вот хороший блог, описывающий размер: http://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/

Тема, которая обсуждается размер и включает в себя ссылку на 3-5 дней: When to create PBI's from a feature request and where to draw the line into splitting them up?