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

Question

Мы возникли проблемы, включающий определенные типы задач в нашей продукции и спринтерских отставаний:

• Встречи с клиентами
• Обучение и обмен знаниями
• Административные задачи

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

Некоторые задачи, однако (обычно встречи с клиентами) повторяются или очень часто. Как они должны быть обработаны? Они обычно не связаны напрямую с какой-либо конкретной историей пользователя, но они жизненно важны для проекта.

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Edit:

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

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

Answer 8

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

Answer 9

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