Как отличить Историю от Задачи.

И как правильно формулировать базовые Элементы Бэклога (PBI).

При подготовке к полевому PI Planning у команд часто бывают вопросы при разделении Бэклога на Истории и Задачи. Баги вызывают меньшие затруднения, но определённые разночтения всё-таки встречаются, что затрудняет процесс планирования. Также много вопросов возникает при формулировании самих элементов(PBI).

Итак, давайте разбираться.

История, Задача и Баг не одно и тоже.

В 3х рассматриваемых сущностях общее то, что они вместе располагаются на базовом уровне Бэклога команды и могут иметь Подзадачи.

Истории

История – Элемент ценности. То что непосредственно может быть использовано потребителями для реализации их целей.

Есть хорошая практика использовать INVEST критерии для создания Историй.

  • Критерии готовности являются обязательным атрибутом всех Историй
  • Потенциально исполнима за Спринт(Итерацию)
  • Как правило за Историю ответственна вся команда
  • Оценка Story Point обязательна
  • DoD обязателен к применению
Шпаргалка – формулирование Истории.

Задачи

Задача – элемент работы. Прямой ценности не несёт. Легко может быть больше Итерации. Обязательно должна быть конечна во времени. Не при каких обстоятельствах не может быть больше PI или квартала.

Как правило так фиксируются управленческие задачи – Например заключить договор с подрядчиком.

  • Как правило у задачи 1 ответственный.
  • Оценка Story Point желательна – на усмотрение команды.
Шпаргалка – Формулирование Задачи

Баги

Баг – описание технического несовершенства, недостатка, заметного пользователю.

  • Часто описание включает технический отчёт по проблеме.
  • Как правило ответственна вся команда
  • Необходимо оценивать в Story Point
  • DoD обязателен к применению
Шпаргалка – формулирование Бага.

Куда размещать рефакторинг?

Это тема отдельного будущего поста, так-то здесь буду краток.

Если нам для реализации PI целей команды нужно произвести значительные изменения, на прямую, или прямо сейчас не влияющие на работу пользователей – необходимо заводить Фичу Энейблер. Подтверждать формулировку и нужность Фичи на PI Planning. И уже её декомпозировать на Истории и Задачи.

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

Правила:

  • Добавляем необходимые пункты к Критериям приёмки (AC) Истории
  • Оценку сложности Истории (Story Point) увеличиваем пропорционально сложности (трудоёмкости) необходимых улучшений

Улучшения

  • Неплохо добавить примеры к каждому типу элементов.

RTE & Scrum Master from Nizhny Novgorod https://t.me/agile4dev

Love podcasts or audiobooks? Learn on the go with our new app.