Бэклог продукта пример excel

Вот несколько полезных шаблонов для управления Скрам проектами в Excel.

Почему именно Excel? Все просто. Как мне кажется там все очень просто… Попробуйте и оцените.

Release Burndown Chart:

Sprint Burndown Chart:

Шаблоны для скачивания (вирусов нет!!!):

Product Backlog Excel Template

Sprint Backlog Excel Template

Вот архив с двумя файлами сразу — excel-shablony-dlya-scrum-product-i-sprint-backlogs

Похожее

Smartsheet Contributor

Joe Weller

August 2, 2022

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

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

Бэклог продукта (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 отличается от простого списка дел?

У бэклога продукта есть определенные свойства:

• Любая отметка в backlog продукта добавляет ценности для клиентов.
• Все записи в бэклоге продукта оцениваются.
• Все отметки получают свой приоритет и порядок.
• Уровень детализации зависит от позиции отметки в Scrum backlog.
• Бэклог продукта — это живой документ без каких-либо бездействий или задач низкого уровня приоритета.

Что делать, если бэклог неустанно растет?

Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?

Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:

• Структурирование бэклога на основе Kanban-досок, лейблов и горизонтальных Swimlanes.
• Оценка идей (с помощью удобных критериев Value and Effort).
• Визуализация и приоритезация важных идей на основе диаграммы Backlog Priority Chart.

Структурирование бэклога

В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:

• Collect Ideas — для сбора всех идей.
• Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
• Score Ideas — для оценивания идеи.
• Approval — для проверки идеи Scrum-мастером или менеджером проекта.
• Developing — для отправления идеи в разработку.
• Done — для реализованных идей. Это означает, что функция «залита» на продакшн.

Swimlanes в Hygger можно использовать для организации идей. Эти горизонтальные столбцы на Kanban-доске используются для разделения различных видов проблем, которыми заняты члены команды. Они помогают командам легче определить, над каким вопросом им работать дальше.

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

Оценка идей

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

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

Backlog Priority Chart

Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:

• Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
• Big Bets для идей, имеющих большие ценность и усилия.
• Maybes для идей с низкими ценностью и усилиями.
• Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.

Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.

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

Бэклог продукта (product backlog) – часть Скрама (SCRUM), то есть методологии управления проектами. Он представляет собой журнал пожеланий проекта по функциональности. Каждый пункт систематизируется по степени важности, от чего зависит порядок его реализации.

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

В составе product backlog разные элементы, которые доводятся командой до готовности. Задачи решаются и достигают нужной степень прозрачности после уточнения (груминга) бэклога. Отдельные пункты могут дополняться, меняться, актуализироваться, разбиваться на более мелкие компоненты и упорядочиваться.

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

Читайте здесь как выбрать ноутбук для бизнеса

Что такое Бэклог продукта

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

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

Основная цель ведения backlog заключается в упрощении работы команды разработчиков. Система планирования обеспечивает:

• Четкое выставление заданий с указанием сроков и описаний.
• Рациональное распределение времени работы.
• Классификацию задач в порядке важности.
• Формирование требований к готовому продукту.
• Систематизацию всех пожеланий заказчика.
• Эффективную связь между разработчиками и владельцем продукта.

Как составлять бэклог

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

Когда объем бэклога увеличивается, его компоненты необходимо группировать, выделяя краткосрочные и долгосрочные цели. Каждая задача имеет свой статус, который можно отслеживать через пользовательские истории. Отдельные задачи могут переходить в статус «Вне объема работ». Их можно изучить позднее.

Сложности при подготовке и исполнении backlog

Не всегда работа идет четко по плану. Часто внешние обстоятельства заставляют продлевать сроки реализации.

Среди ошибок, которые можно допустить при формировании бэклога:

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

Структура бэклога

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

Читайте здесь про отличия Scrum от Канбан

Для его составления рекомендуется:

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

Что входит в бэклог продукта

Элементы backlog:

• Items (запланированная работа). К items относят функции, требования, усовершенствования, данные по исправлению дефектов.
• User stories (пользовательские истории). Важный компонент стандартного бэклога, подразумевающий описание желаемых опций.

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

Часто план снабжается деталями в виде описаний и комментариев. Элементы бэклога оцениваются менеджером, который может вносить свои корректировки и дополнения.

Среди критериев качества backlog:

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

Читайте здесь что такое Agile

Груминг и рефаймент бэклога

Груминг бэклога – это регулярный пересмотр или уточнение проекта. С английского grooming переводится как причесывание. Он включает в себя анализ, систематизацию элементов, трансформацию приоритетов.

Рефаймент (refinement) предполагает оптимизацию, улучшение проекта. Означает действия, направленные на добавление новых деталей и оценок, упорядочение компонентов плана. Процедура занимает около 10% рабочего времени команды.

Вносить поправки в план могут следующие категории лиц:

• Участники команды разработчиков, которые создают программный продукт.
• Владелец продукта, играющий роль эксперта и органа контроля. Может задавать направление работы, менять значимость заданий.
• Скрам-мастер. Помогает повысить эффективность работы специалистов.
• Стейкхолдеры. Иные заинтересованные в проекте лица.

Процедура grooming может включать в себя:

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

Backlog refinement означает «чистку» плана от лишних компонентов. Актуализация бэклога позволяет сократить занятость исполнителей, избавляя их от лишних задач. Упрощается планирование действий разработчиков, уходит неопределенность в требованиях клиента.

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

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

Пример Бэклога продукта

Предлагаем пример backlog

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

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

• Download documents and help file — 85.7 KB

Introduction

This article describes two Excel documents that can be used as a Product Backlog and Sprint Backlog for the Scrum Framework.

Although there is software out there that does a better job in many areas, these are intended in any of the following circumstances:

• People who want to quickly get into using those artifacts, without needing to buy hardware or software. The only software needed is Excel, which is prevalent in most companies.
• Since it is free, it also avoids the issue of having a complex purchasing process hinder forward progress.
• It may also be one of the few choices for organizations that are Windows only as I have yet to see a good, free Scrum tool that runs on WindowsSQL Server.

Because each backlog is in one document, it also has a few other advantages:

• The entire document can be emailed out. This is useful for status reports to people who are not directly involved.
• If stored within a document management or source control system, you can get versions of the entire project. This can be useful if you want to see what items were in the backlog at a certain point in time.
• You can easily add or remove columns, rows or other information. Quite often, I’ve added columns to the backlogs that are only relevant to a specific project. For example: whether we have to discuss a requirement with an external development team, whether we need clarification on the requirement, etc.

Some disadvantages:

• It is not intuitive. There is a learning curve to using the documents, but once you gain some experience, they are easy to maintain. This is the area that software holds a huge advantage, because it can guide a user through entering the data. I have tried to compensate for this by writing a detailed help guide.
• Because it is a single document, you cannot have multiple people working concurrently on it.
• Not ideal for storing artifacts. Some software allows you to link and store documents with the tasks. In the case of Excel, you can embed links to the file system or embed the artifacts directly into the document, but it’s not ideal.
• You can’t reliably roll up data from multiple backlogs. Although it is still possible to reference data across Excel documents, it is not always dependable. This makes it hard to have «Scrums of Scrums»

I would like to point out that this article is not focused on educating readers on Agile methodologies or Scrum. It only covers how the artifacts I created should be used. There are a number of fantastic books and websites that should be used for research.

Background

While working at T4G, an eBook by Martin Fowler got me interested in Agile methodologies. The more I read, the more I admired them. Eventually, Scrum became my Framework of choice, because even though our development processes were top notch, I always felt there was a better way to manage projects than traditional predictive methodologies.

I just got off a massive project where our Gantt chart changed so frequently, it was almost a full time job just re-prioritizing, revising, re-estimating and reordering tasks. On the next project, people were hesitant to adopt Agile methodologies, so I needed a way to quickly and with minimal cost, start using Scrum and prove that it was a better way to manage a project. I wrote up the first version of a Product Backlog and Sprint Backlog one evening, thinking it would only take me a few hours. Although that was true, the version that is downloadable here has been improved during every project I use it on, to the point where I think all the kinks have been worked out. There were actually quite a few unexpected problems I did not foresee, especially with the charts.

Using the code

There are a few commonalities with both documents:

• They are both written in Excel 2003 and have been tested on Excel 2007.
• There are no macros. Too many organizations restrict macros and I don’t want to have any concern about my documents spreading VBA viruses.
• They both have a single sheet that has all the tasks for the team.
• There are one or more charts in different sheets.
• There is a «Lookup» sheet that contains data that some cells will use to provide a list of choices. This is done using the «Defined Name» and «Data Validation» functionality in Excel.

I highly recommend you store these documents in a centralized store, such as a document management system (e.g. LiveLink, SharePoint, Documentum, etc.) or in a source control system (e.g. CVS, Team System, SourceSafe, SourceGear Vault, etc.). That way, you can have multiple people (e.g. Product Owner, ScrumMaster, etc.) editing the documents, you get version tracking and you can see who made the change.

There is a set of instructions (called Help.doc) that describe common tasks that you would perform with both the Product Backlog and Sprint Backlog. Please see that for details on using the artifacts.

Reports

There are a set of reports based on the data found in the Backlogs:

• Product Backlog

  • Product Burn-down: This shows the velocity of the team at completing tasks per iteration. It shows how much effort was completed (burn-down), new scope that was completed, new scope that was not completed and how much work is remaining.
  • Effort By Iteration: A pie chart that shows the effort that has been allocated to each iteration. This can be used to try to balance out the requirements across the iterations.
  • Effort By Priority: A pie chart that shows the effort for each priority level. This can be used to make sure effort is balanced across the priorities.
  • Effort By Risk: A pie chart that shows the effort for each risk. This can give a visual idea of the risk of the project.

• Sprint Backlog

  • Sprint Burn-down: For a Sprint that is currently in progress, it gives an idea of the velocity of the team at completing tasks at a daily level. It tracks the current work remaining on a day to day basis. It also predicts the completion date of the Sprint based on a trend line.

Points of Interest

The concept of velocity caused quite a few issues. A spreadsheet is really only good at tracking the current state. Building a full history into it would take up a lot of space. So I had to come up with ways to track initial sets of effort, re-estimations, etc. in a way that still tracked the velocity, without requiring a day to day tracking of changes. I feel I found the right balance, but sometimes the lack of an accurate history has caused some confusion.

Conclusion

Whenever possible, I will always use software to track an Agile project. Although when we first started to explore Agile methodologies, these documents were a quick way to get up and running without any hardware or software. It takes some time to learn the documents, but once you get used to them, they are easy to maintain, sometimes even being faster than logging into a system and editing the tasks.

History

• August 3rd, 2007: First revision
• August 8th, 2007: Fixed some defects in the backlogs. Category was hidden in the Sprint Backlog and unassigned tasks were not being correctly added to the scope for the Product Backlog
• September 7th, 2007: Changed the way Burn-down was being calculated to better take into account dramatic changes in scope. Fixed an issue with weekdays. Removed min effort estimate for Product Backlog.