product backlog item что это
Шаблон процесса Scrum для Team Foundation Server
Среди многих команд занимающихся разработкой все большую популярность приобретает подход Scrum. Действительно, лаконичную, в 20 страниц текста методологию, легко понять и после некоторой практики начать использовать. Вот почему Microsoft выпустил дополнительный шаблон Scrum, который позволяет использовать эту методологию вместе с Team Foundation Server.
Шаблоны процессов
Те, кто уже использует TFS в работе, знают, что для организации работы команды можно использовать два шаблона процесса — MSF Agile и MSF CMMI. Технологически эти шаблоны представляют собой набор файлов, которые описывают рабочие элементы процесса, документы, отчеты, настройки безопасности и так далее. Более того, TFS позволяет настраивать эти шаблоны, дополняя их какими-то свойствами, которые специфичны именно для этой команды. Такие модификации удобно делать, используя Visual Studio Power Tools. На рынке представлено несколько дополнительных шаблонов процессов разработанных силами сообщества и коммерческими компаниями.
Шаблон процесса Scrum
Этот шаблон был разработан специалистами Microsoft при непосредственном участии экспертов из Scrum.Org. Как и стандартные MSF Agile и MSF CMMI он в первую очередь состоит из набора рабочих элементов которые призваны организовать работу команды:
Productuct Backlog Item (PBI): Отслеживание требований к всему программному продукту. 
Bug: Найденная в процессе разработки ошибка. Следует отметить что Product Backlog Item и Bug это практически равноценные элементы списка требований в контексте оценок затрат и планирования. Отсюда и практически идентичный набор полей. Небольшое замечание. В отличие от MSF Agile и MSF CMMI Шаблонов, TFS не создает Bug на основании ошибочной сборки (build).
Task: Задача. Этот элемент позволяет внести требуемый уровень детализации для Product Backlog Item. Естественно и сами задачи могут быть раздроблены на подзадачи.
Sprint: В этом рабочем элементе фиксируются даты спринта, цели и ретроспектива. Выделение Sprint в отдельный рабочий элемент отличает шаблон Scrum от шаблонов MSF Agile и MSF CMMI. В них спринт обозначается только с помощью механизма иерархий итераций, но к сожалению с помощью него не возможно обозначить даты начала и окончания спринта.
Impediment: Проблемы, риски и все то что может влиять на работу команды но не связано напрямую с свойствами разрабатываемого продукта.
Test Case: Описание теста для PBI. Обычно тесты напрямую привязываются к конкретному PBI. Этот рабочий элемент (как в прочем и Shared Steps) не определен напрямую в Scrum но он необходим для корректной работы инфраструктуры TFS.
Shared Steps: Разделяемые между несколькими Test Case шаги проверок.
Организация работы
Собственно сам процесс работы хорошо описан в руководстве по Scrum и ниже приведен очень краткий пример шагов:
1) Формируется команда проекта, и подготавливаются минимально необходимые документы (Vision, Scope)
2) Формируется первичный список PBI и там где возможно назначаются приоритеты. Этот этап аналитики, как правило, не долгий.
3) На основании первичного списка PBI проводится первая оценка (Поле Effort) с помощью Planning Poker. Не следует забывать что это абстрактные единицы, хотя можно планировать и в часах.
a. Те PBI которые не понятны (оценка уровня бесконечность или очень высокие стоимости) отправляются на дополнительную аналитику.
4) Формируется первый спринт на основе приоритетов и значимости PBI из полного набора Product Backlog, и которые уже понятно как реализовать.
5) PBI которые попали в Sprint детализуются разработчиками до уровня задач (Task) там где это необходимо. Тут можно вводить время. У Task есть поле Remaining Work.
a. После двух-трех Sprint уже можно ожидать однозначности в стоимостях и уточнить горизонт планирования.
6) Производится проверка PBI в состоянии Commited на основании заданных Test Case.
7) Неизбежно возникающие ошибки следует фиксировать с помощью Bug которые тоже попадают в Product Backlog.
8) Выполненные PBI закрываются с статусом Done
9) Планируется следующий Sprint, процесс повторяется с п.п. 5.
Манипуляции с списками PBI/Bugs/Task в рамках Product Backlog и Sprint осуществляются с помощью стандартных запросов которые уже определены в шаблоне для Sprint 1.
Соответственно после окончания первого спринта следует не забыть изменить запрос «Sprint Backlog» на текущее значение спринта:
Состояния рабочих элементов Scrum
В шаблонах MSF Agile и MSF CMMI используется уже устоявшийся в TFS подход ARC (Active->Resolved->Closed) который не совсем соответствует терминам Scrum.
Напомню, что более детально с Workflow всех рабочих элементов можно ознакомиться как на сайте MSDN, так и с помощью Team Foundation Server Web Acces и Process Editor.
Для примера приведу скриншот из редактора Wokflow для рабочего элемента Bug (он наиболее сложный) процесса Scrum:
Отчеты Scrum
Естественно, практически все поля, которые определены в рабочих элементах Scrum, попадают в системы аналитики Team Foundation Server и позволяют построить несколько важных отчетов, которые в последствии дают возможность понимать, как идут дела на проекте.
Sprint/Release Burndown – два отчета которые дают возможность оценить объемы оставшейся работы по проекту и спринту.
Release Burndown: От спринта к спринту общий объем задач, оценённый в единицах Effort должен уменьшаться. Косвенно через этот график так же можно оценить производительность команды.
Sprint Burndown: Каждый день команда закрывает некоторое количество PBI в рамках спринта. 
Отчет Velocity: Усилия которые были затрачены на каждом спринте. Этот отчет перекликается с Release Burndown. Так же на графике представлена средняя цифра (35) производительности команды в рамках спринта. В идеале (и неизменной команде) чем больше было спринтов тем точнее эта цифра, и тем точнее можно предсказать дату окончания проекта. 
Build Success Over Time, Build Summary отчеты: показывают состояние сборок проекта в разрезе платформ и пройденных тестов. Позволяют понимать прогресс, масштаб изменений и оценивать качество продукта. 
Отчеты по тестам призваны дать оценку общему состоянию качества продукта, а так же решить организационные вопросы связанные с самими тестами. Исходя из информации представленной в этих отчетах можно понять сколько тестов от даты к дате проходят с корректным результатом, сколько с ошибочным, сколько вообще пока не запускалось и сколько тестов заблокировано.
Организовать работу с тестами позволяет отчет Test Case Readiness показывающий сколько тестов уже готово к исполнению и сколько еще пока находится на стадии детализации. В идеале этот отчет должен нарисовать такую картинку:
Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?
Менеджеры продукта и его собственники не могут не уделять серьезного внимания продуктовому бэклогу. Не только для облегчения планирования релизов и итераций, но и для оптимизации всего жизненного цикла продукта, над которым намерена работать команда.
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.
Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.
Бэклог продукта vs бэклог спринта
Эти два компонента Scrum несут разный смысл, но их часто путают.
Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать.
Оба бэклога можно представить в обычной таблице Excel, однако сегодня для этих целей опытные менеджеры и собственники продуктов пользуются специальными инструментами для управления продуктом, позволяющими грамотно визуализировать состояние дел.
Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.
В чем смысл бэклога продукта?
Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.
Обычный бэклог продукта включает следующие пункты:
Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.
Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.
Для чего нужен backlog refinement?
Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.
Чем бэклог продукта в Agile отличается от простого списка дел?
У бэклога продукта есть определенные свойства:
Что делать, если бэклог неустанно растет?
Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?
Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:
Структурирование бэклога
В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:
Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.
Оценка идей
В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
Backlog Priority Chart
Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.
Бэклог Продукта (Product Backlog)
Бэклог Продукта – это упорядоченный и постоянно обновляемый список всего, что планируется сделать для
создания и улучшения продукта. Этот артефакт Скрама является единственным источником работы для Скрам-команды. Владелец Продукта несет ответственность за Бэклог Продукта, включая его содержимое, доступность и упорядочение.
Элементы Бэклога Продукта, которые могут быть доведены Скрам-командой до состояния готовности в течение одного Спринта, считаются готовыми к помещению в Бэклог Спринта (см. также Критерии Готовности к Разработке). Элементы достигают такого уровня прозрачности после активностей по Уточнению Бэклога Продукта, в ходе которого элементы снабжаются актуальной уточняющей информацией, разбиваются (декомпозируются) на более мелкие и конкретные, получают оценки размера, а также упорядочиваются.
Оценку размера элементов производят Разработчики, которые будут выполнять работу. Владелец продукта может влиять на Разработчиков, помогая им понять элементы и обсуждая компромиссы.
В Руководстве по Scrum 2020 появилась Цель Продукта, являющаяся commitment’ом для Бэклога Продукта.
См. также: Что такое продукт?
Практическое определение продукта от ScrumTrek.
Артефакты Скрама (Scrum Artifacts)
Материальное представление работы или ценности. В Скраме существует три артефакта: Бэклог Продукта, Бэклог Спринта, Инкремент.
Они спроектированы таким образом, чтобы обеспечить максимальную прозрачность ключевой информации, и чтобы все участники процесса имели единое понимание каждого из артефактов.
Бэклог – это упорядоченный по приоритету список работ, которые планируется выполнить с учетом знаний, имеющихся на данный момент.
Бэклог Спринта – это Цель Спринта, набор Элементов Бэклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Служит для наглядного представления работы, которую Команда определила для достижения Цели Спринта.
Инкремент объединяет реализацию Элементов Бэклога Продукта, сделанную во время текущего Спринта. Является одним из трех Артефактов Скрама и отражает шаг на пути к Цели Продукта. Каждый Спринт должен включать минимум один Инкремент, чтобы считаться завершенным успешно.
Элемент Бэклога Продукта (Product Backlog Item)
Элемент Бэклога представляет собой часть работы, которую планируется сделать с учетом знаний, имеющихся на данный момент.
Элемент Бэклога Продукта – изменение, которое планируется выполнить в следующих Инкрементах продукта (например, фичи, функции, требования, усовершенствования или информация по исправлению дефектов). Элементы, расположенные в верхней части Бэклога Продукта, обычно более понятны и содержат больше деталей, чем те, что расположены ниже.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Разделы
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
Элемент Бэклога Продукта (Product Backlog Item)
Элемент Бэклога представляет собой часть работы, которую планируется сделать с учетом знаний, имеющихся на данный момент.
Элемент Бэклога Продукта – изменение, которое планируется выполнить в следующих Инкрементах продукта (например, фичи, функции, требования, усовершенствования или информация по исправлению дефектов). Элементы, расположенные в верхней части Бэклога Продукта, обычно более понятны и содержат больше деталей, чем те, что расположены ниже.
Артефакты Скрама (Scrum Artifacts)
Материальное представление работы или ценности. В Скраме существует три артефакта: Бэклог Продукта, Бэклог Спринта, Инкремент.
Они спроектированы таким образом, чтобы обеспечить максимальную прозрачность ключевой информации, и чтобы все участники процесса имели единое понимание каждого из артефактов.
Бэклог – это упорядоченный по приоритету список работ, которые планируется выполнить с учетом знаний, имеющихся на данный момент.
Бэклог Продукта – это упорядоченный и постоянно обновляемый список всего, что планируется сделать для
создания и улучшения продукта. Он является единственным источником работы для Скрам-команды. Владелец Продукта несет ответственность за Бэклог Продукта, включая его содержимое, доступность и упорядочение.
Бэклог – это упорядоченный по приоритету список работ, которые планируется выполнить с учетом знаний, имеющихся на данный момент.
Бэклог Спринта – это Цель Спринта, набор Элементов Бэклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Служит для наглядного представления работы, которую Команда определила для достижения Цели Спринта.
Инкремент объединяет реализацию Элементов Бэклога Продукта, сделанную во время текущего Спринта. Является одним из трех Артефактов Скрама и отражает шаг на пути к Цели Продукта. Каждый Спринт должен включать минимум один Инкремент, чтобы считаться завершенным успешно.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми