Бэклог спринта 📑 — изменение и приоритизация Sprint Backlog в ходе спринта

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

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

Из Бэклога продукта в Бэклог спринта попадает несколько важных требований. По сути, Бэклог спринта – это взаимодействие команды и обещание, которое будет добавлено в обновление продукта.

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

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

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

Задача команды — определить, за какой период времени они смогут воплотить замысел собственника продукта в реальность.

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

Зачастую Бэклог спринта ведут в виде таблицы или доски со стикерами, но допускается и иная форма работы с информаций.

Задача команды – приложить максимум усилий, чтобы за один Спринт было реализовано максимальное количество работы. Нередко случается, что во время такого планирования появляется недостаток задач, либо – наоборот, избыток. Команда в таких случаях сокращает количество времени на нее, либо добавляет.

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

Бэклог может быть как всего продукта, так и спринта или релиза.

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

Несколько историй команда объединяет в так называемый Epic, что помогает сделать Бэклог более структурированным.

Таким образом определяются функции, которыми необходимо наделить продукт.

Например:

• как пользователь приложения, я хочу получить аккаунт с самыми инновационными методами защиты;

• как посетитель, я хочу получить удобный поиск на сайте, чтобы тратить минимум времени на поиск необходимого товара или услуги;

• как оператор технической поддержки, я хочу легко получать заявки пользователей сайта.

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

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

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

Бэклог продукт включает в себя:

Ценность для конечных пользователей

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

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

Пример: пользователями интернет–магазина могут быть как обычные покупатели, так и оптовые, менеджеры по продажам, операторы, владельцы бизнеса, аналитики.

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

Задачи высокого уровня

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

Возможность оценки и проверки

Для реализации проекта от разработчиков необходимо большое количество усилий.

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

Независимость

Гораздо удобнее, когда элементы Бэклога не зависят от работы друг друга.

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

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

Приоритет истории учитывают, исходя из двух важных показателей:

• важность истории для бизнеса;

• сколько усилий необходимо приложить для ее разработки.

Важность истории определяет Владелец Продукта, а оценку дает команда на этапе планирования.

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

По сути, Бэклог спринта – это взаимодействие команды и обещание, которое будет добавлено в обновление продукта.

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

К началу спринта обязательно должен быть составлен список того, что требуется сделать.

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

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

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

Определенного формата — нет. Бэклог можно вести в форме таблицы, специальной программы, либо на доске в кабинете.

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

Вести Бэклог можно одновременно в двух вариантах: на доске и в таблице, либо другом документе.

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

Классический Бэклог спринта включает в себя:

• Особенности продукта (его задачи, требования, несколько пользовательских историй).

• Различные баги.

• Получение дополнительных знаний (например, расширение рабочего персонала).

• Работы технического характера.

Главными элементами Бэклога являются пользовательские истории.

Для чего необходимо улучшение Бэклога?

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

По сути – это взаимодействие разработчиков и собственника для улучшения и модификации проекта.

Бэклог продукта имеет такие свойства:

• каждая запись в Бэклоге продукта получает свою оценку

• все отметки добавляют продукту ценность

• все записи получают свой порядок и приоритет

• в зависимости от отметки повышается уровень детализации

Задача менеджера продукта (или Владельца Продукта) – сфокусироваться на ключевых элементах проекта.

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

Если Бэклог постоянно растет, контролировать его становится все сложнее и сложнее.

Решение этого вопроса можно найти на инновационных платформах.

На платформе Hygger можно быстро оценить все свои идеи, используя лишь 2 основных критерия — Value и Efforts.

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

Независимо от того, каким является продукт, сервис, либо услуга, совершенствование Бэклога – это важная составляющая его управления.

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

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

Бэклог спринта — это элементы Бэклога продукта, которые Scrum команда будет реализовывать в ближайший спринт.

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

Бэклог спринта, как и Бэклог продукта, ведет Владелец Продукта или менеджер продукта. Тем не менее, Scrum команда может делиться своим опытом и мнением относительно того, какие элементы Бэклога стоит взять в текущий спринт.