Перемещение элементов невыполненной работы в Sprint

Кто в Agile отвечает за перемещение тикетов в Jira (например, перемещение элементов невыполненной работы в Sprint). Это обязанность скрам-мастера или владельца продукта?

Вы спрашиваете «в начале спринта» или «в середине текущего спринта»?
Мы в середине спринта. Спасибо.

Ответы (4)

Согласно Руководству по Scrum , событие планирования спринта — это когда создаются бэклог спринта и цель спринта, и вся скрам-команда (владелец продукта, команда разработчиков и скрам-мастер) сотрудничает для создания плана спринта.

Приступая к Планированию Спринта, Владелец Продукта должен иметь упорядоченный Бэклог Продукта. Элементы в верхней части Бэклога Продукта должны быть уточнены (путем Уточнения Бэклога Продукта) Владельцем Продукта и Командой Разработки, чтобы гарантировать, что Элементы Бэклога Продукта содержат достаточную информацию для работы и понимание требуемых усилий.

На Планировании Спринта Команда Разработки может проверить свои возможности и определить, какую работу целесообразно включить в Спринт, в сотрудничестве с Владельцем Продукта. Мероприятие может проводить скрам-мастер команды.

В ходе Спринта Бэклог Спринта полностью принадлежит и управляется Командой Разработки. Если Команда Разработки понимает, что они не смогут выполнить Элементы Бэклога Продукта в пределах временного интервала Спринта, они должны работать с Владельцем Продукта, чтобы гарантировать, что работа будет выполнена с наибольшей ценностью, а Цель Спринта может быть использована, чтобы помочь сфокусировать команду. Если Команда Разработки прорабатывает Бэклог Спринта до окончания временного интервала Спринта, они могут аналогичным образом работать с Владельцем Продукта, чтобы определить, как лучше всего использовать это время — возможно, принося какую-то работу раньше, тратя дополнительное время на доработку Бэклога Продукта, оплачивая снижение технического долга было бы хорошим вариантом для рассмотрения. Скрам-мастер может помочь облегчить обсуждение между командой разработчиков и владельцем продукта по мере необходимости.


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

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

TL;DR

Любой человек с достаточными правами доступа в JIRA может перемещать истории во время планирования спринта. На самом деле не имеет значения, кто на самом деле продвигает истории. Важно то, что истории вытягиваются командой разработчиков, а не продвигаются .

Ответственность за перемещение элементов невыполненной работы

В Руководстве по Скраму четко указано, что Команда Разработки несет ответственность за удаление элементов из Бэклога Продукта во время мероприятия Планирования Спринта . Гид говорит:

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

Другими словами, Владелец Продукта отвечает за Бэклог Продукта, а Команда Разработки несет ответственность за перемещение этих элементов в Бэклог Спринта . Тот факт, что вы используете JIRA для обоих, здесь не имеет большого значения, за исключением деталей реализации.

Делегирование разрешено

Любой, у кого есть соответствующие разрешения в JIRA, может перемещать элементы в текущий Sprint. Однако это следует делать только по запросу Команды Разработки. Итерации Scrum представляют собой очереди, основанные на вытягивании, а не на проталкивании, поэтому в спринте не должно быть ничего, что не было бы одобрено командой разработчиков для текущей итерации.

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

Бэклог Спринта делает видимой всю работу, которую Команда Разработки считает необходимой для достижения Цели Спринта. Команда Разработки модифицирует Бэклог Спринта на протяжении всего Спринта, и Бэклог Спринта появляется во время Спринта.

По мере того, как требуется новая работа, Команда Разработки добавляет ее в Бэклог Спринта. По мере выполнения или завершения работы оценка оставшейся работы обновляется. Когда элементы плана считаются ненужными, они удаляются. Только Команда Разработки может изменять свой Бэклог Спринта во время Спринта. Бэклог Спринта — это хорошо наглядная картина работы, которую Команда Разработки планирует выполнить в течение Спринта, в режиме реального времени, и она принадлежит исключительно Команде Разработки.

В середине спринта ответственность лежит на команде разработчиков. Они могут добавить/изменить объем после повторных переговоров с владельцем продукта. Скрам-мастер может помочь в этом.

Вот что говорит об этом Scrum Guide:

Во время спринта:

  • Не вносятся изменения, которые могли бы поставить под угрозу Цель спринта;
  • Цели в области качества не уменьшаются; и,
  • Область действия может быть уточнена и повторно согласована между Владельцем Продукта и Командой Разработки по мере получения дополнительной информации.

https://scrumguides.org/scrum-guide.html#events-sprint

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

Но руководство по Scrum предлагает отменить спринт, когда объем работы настолько велик, что это изменит цель спринта:

Спринт будет отменен, если цель спринта станет устаревшей.