Что такое Бэклог(Backlog) по Scrum Guide 2020?

И что такое DEEP Backlog?

Michael Sokolov
5 min readFeb 19, 2021

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

Журналов — Бэклогов у запущенного проекта Два:

  • Product Backlog — Бэклог продукта
  • Sprint Backlog — Бэклог спринта

У каждого журнала есть своя цель.

Цель или приверженность предоставляет информацию для поддержания прозрачности и сфокусированности, и по которой оценивается прогресс.

  • Цели продукта (Product Goal) меняются в зависимости от внtшних условий.
  • Цель спринта (Sprint Goal) — единственная цель на Sprint. Она неизменна на всем протяжении спринта.

Product Owner несёт ответственность за эффективное управление Product Backlog

в том числе он:

  • разрабатывает и точно коммуницирует Product Goal;
  • создаёт и чётко объясняет элементы Product Backlog;
  • упорядочивает элементы Product Backlog; а также,
  • обеспечивает прозрачность, доступность и понимание Product Backlog.

Product Owner может выполнять это работу сам или делегировать её выполнение другим лицам. Тем не менее, Product Owner остаётся ответственным за неё.

Команда разработки ответсвенна за Sprint Backlog.

Product Owner ответственен за Sprint Goal.

Бэклог состоит из разнообразных элементов:

Мы не ограничены Scrum Guide в названиях и типах и дополнительных свойствах.

Иерархия элементов Бэклога

Элементы группировки \ иерархии — фактически это контейнеры для других элементов:

  • Epics — Эпики — наиболее часто встречающийся элемент. Представляет собой описание функционала который нельзя выполнить за один спринт, или 1 специалсистом или может быть декомпозирован на ряд независимых элементов беклога.
  • Features — Функции — Используется в Azure DevOps для уровня иерархии ниже Эпиков.
  • Initiatives — Инициативы— Вариация иерархии, обычно выше Эпиков.
  • Вехи — Вариация иерархии

Элементы бэклогоа — Backlog items

  • User Story — это краткое изложение требований или запросов, составленное с точки зрения конечного пользователя.
  • Task — Задача, Задание
  • Bugs — Баг
  • Issue — Проблема или пожелание

Требование к элементу бэклога — он должен нести ценность для конечного пользователя продукта.

Подзадачи — Sub tasks

  • Sub tasks — Подзадачи — Любая задача которую может взять на себя член Scrum команды.
  • Сторонние задачи — хорошей практикой может быть фиксация договорённостей с другими командами внутри своего бэклога.
Примеры добавления элемента

Часто можно видеть в конкретных реализациях бэклг трэкерах сущности расширяющие суть Беклога — например Зависимости или Варианты тестирования.

Время

Scrum команда может тратить до 10% времени спринта на уточнения Product Backlog и Sprint Backlog. Хорошей практикой может стать — оставаться всей командой или необходимой частью поле Дейли на уточнения Backlog.

Product Backlog

Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum Team. Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовности в течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning. Они достигают такого уровня прозрачности после активностей по уточнению. Уточнение Product Backlog — это процесс разбиения элементов Product Backlog на более мелкие и конкретные элементы, и их дальнейшего уточнения. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер. Атрибуты элементов зависят от предметной области выполняемой работы и могут быть очень разными. Оценку размера элементов производят Developers, которые будут выполнять работу. Product Owner может влиять на Developers, помогая им понять элементы и обсуждая компромиссы.

Приверженность: Product Goal

Product Goal описывает будущее состояние продукта, которое может выступать в качестве конечной цели, используемой Scrum Team при планировании работы. Product Goal входит в состав Product Backlog. Остальная часть Product Backlog появляется, чтобы определить, «что» будет способствовать достижению Product Goal.

Продукт — это средство доставки ценности. У него есть чёткие границы, известные заинтересованные лица, чётко определённые пользователи или клиенты. Продукт может быть услугой, физическим продуктом или чем-то более абстрактным.

Product Goal — это долгосрочный ожидаемый результат Scrum Team. Они должны достичь одной цели (или отказаться от нее), прежде чем приступить к следующей.

Sprint Backlog

Sprint Backlog состоит из Sprint Goal (почему), набора выбранных на Sprint элементов Product Backlog (что), а также осуществимого плана действий по поставке Increment (как). Sprint Backlog — это план, созданный силами Developers для самих Developers. Это наглядная и доступная в режиме реального времени картина работы, которую Developers планируют выполнить в ходе Sprint для достижения Sprint Goal. Поэтому Sprint Backlog обновляется на протяжении всего Sprint по мере появления новых знаний. В нем должно быть достаточно деталей, чтобы Developers могли инспектировать свой прогресс во время Daily Scrum.

Приверженность: Sprint Goal

Sprint Goal — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal, она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для ее достижения. Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum Team работать совместно, а не над отдельными инициативами. Sprint Goal создаётся во время Sprint Planning, а затем добавляется в Sprint Backlog. Developers помнят о Sprint Goal в ходе работы над задачами Sprint. Если работа не соответствует ожиданиям, они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal.

DEEP Backlog

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

Разработанный Романом Пихлером и Майком Коном, DEEP прост, легко запоминается и быстро может быть применён.

Акроним расшифровывается как :

  • D-etailed
  • E-stimated
  • E-mergent
  • P-rioritized

Как добиться DEEP ?

Роман Пихлер, соавтор подхода DEEP, даёт следующий совет:

Чтобы гарантировать, что бэклог продукта будет DEEP и останется таким, вы должны регулярно его улучшать. Обработка бэклога продукта — это непрерывный совместный процесс, в котором участвуют владелец продукта и команда.

Вот четыре ключевых фактора хорошего бэклога — DEEP :

D: Достаточно детализованный — Detailed appropriately

Достаточно детализованный (Detailed appropriately) беклог спринта и продукта.

Элементы бэклога должны содержать достаточно контекстной информации для понимания и обсуждения кросс-функциональной командой. Это похоже на айсберг или пирамиду: вверху — достаточно проработанные элементы, внизу — крупно-блочные сущности.

E: Оценённый — Estimated

Оценённый (Estimated) бэклог

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

E: Развивающийся во времени — Emergent

Развивающийся во времени ( Emergent) бэклог

Живой. Поскольку портфель продукции постоянно развивается, легко добавлять новые истории и элементы — или удалять их — по мере появления новой информации. Ничто не вечно.

P: Приоризованный — Prioritized

Приоризованный (Prioritized) бэклог

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

Используемые материалы

Что будет улучшено

  • Добавлен блок — Хорошие практики в больших компаниях
  • Добавлен блок — Маркеры

--

--