Должны ли вы включать задачи не-разработки в ваш Scrum backlog?

Ответ 1

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

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

Не повторяющиеся события, такие как специальное собрание, R & D, исследование и т.д., на самом деле не принадлежат PB (как должно быть значение PO для них и определять их приоритетность?), и я предпочитаю включать их "стоимость", в оценке соответствующего PBI. И когда элемент выбирается, мы создаем соответствующую задачу в Sprint Backlog с временной оценкой.

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

Ответ 2

Задача не связана с отставанием продукта. Задача связана с отставанием от спринта. Действия, которые вы описали, не являются задачами.

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

Edit:

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

Добавление таких фиктивных задач (задач без добавленной стоимости) в ваш спринтерский backlog также повлияет на вашу скорость. Похоже, что каждый сюжетный пункт стоит больше, чем на самом деле, потому что время встречи будет включено в реальную работу.

Какие типы собраний вы хотите добавить в свой портфель спринта? SCRUM требуется только несколько встреч - ежедневная встреча, совещание по планированию, обзорная встреча, ретроспективное совещание и в более крупном проекте SCRUM SCRUM. Ежедневная встреча настолько коротка, что ее необязательно включать в планирование. Совещание по планированию, обзорное совещание и ретроспективное совещание не обязательно должны быть включены в спринт. SCRUM SCRUM является специфическим, и он не влияет на всю команду - может быть уменьшен от планируемой способности присутствующих участников. Больше встреч не требуется. Самое важное: Коммуникация, необходимая для выполнения задачи, является частью оценки задачи.

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

Ответ 3

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

Виды деятельности, которые мы включили, заключались в семинарах клиентов, мероприятиях по выпуску и т.д.

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

Если вы не включаете то, что люди должны делать в своем отставании, как бы вы предложили управлять ими?

Неразвивающиеся инициативы требуют времени, и они так же важны для предоставления качественного продукта, как dev и qa.

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

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

это действительно зависит от ситуации, но если отставание является центральным местом для захвата и управления работой, почему это только разработка и работа QA, к которой он привыкает?

Ответ 8

В Scrum нет формулы исправления для определения пользовательских историй. В моем проекте мы выбираем, какой рабочий элемент должен быть преобразован в Истории. Например. задачи, подобные сравнению 2-3 инструментов IDE dev, идут в Backlog, потому что они напрямую связаны с развитием. Но в остальном я планирую активность в течение 5 часов в день для каждого члена команды, чтобы они тратили оставшиеся часы на обучение, документацию, обмен знаниями, программирование сверстников и т.д. Это работает для меня в оправдании демо-версии и скорости спринта.

Ответ 9

Вы можете управлять задачами без разработки на плате Trello. Это могут быть такие вещи, как исследовательская деятельность или вытягивание данных, которые будут использоваться для разработки. Они не принадлежат JIRA или Rally, поскольку они не являются задачами разработки и не имеют оценки сюжетной точки.