Что такое backlog в jira

Backlogs

Бэклог здорового продукта очень похож на здорового человека: ухожен, организован и живет в открытую.

Приоритетный Agile список необходимых требований (backlog) не только упрощает планирование выпуска релиза и итерации, но и транслирует все то, на что ваша команда собирается потратить время, включая внутреннюю работу, которую клиент никогда не заметит. Это помогает установить ожидания среди заинтересованных сторон и других групп, особенно когда они приносят вам дополнительную работу, и делает время разработки постоянным активом.

Что такое список необходимых требований (backlog) продукта?

Самые важные элементы отображаются в верхней части список необходимых требований (backlog) продукта, поэтому команда знает, что предоставить первым. Команда разработчиков не работает с списком необходимых требований (backlog) в темпе владельца продукта, и владелец продукта не подталкивает работу в команде разработчиков. Вместо этого команда разработчиков извлекает работу из списка необходимых требований (backlog) продукта, поскольку для этого есть возможность, либо непрерывно (kanban), либо итеративно (scrum).

PRO TIP:

Начните с двух «R»

Дорожная карта команды и требования обеспечивают основу для списка необходимых требований (backlog) продукта. Инициативы «Дорожная карта» разбиты на несколько эпиков, и у каждого эпика будет несколько требований и пользовательских историй. Давайте посмотрим на дорожную карту для вымышленного продукта под названием «Команды в космосе».

Поскольку веб-сайт «Команды в космосе» является первой инициативой в дорожной карте, мы хотим разбить эту инициативу на эпики (показаны здесь зеленым, синим и бирюзовым цветом) и пользовательские истории для каждого из этих эпиков.

Затем владелец продукта объединяет каждую пользовательскую историю в единый список для команды разработчиков. Владелец продукта может сначала поставить полный эпик (слева). Или, может быть, для программы важнее проверить бронирование авиабилетов со скидкой, для чего нужны истории из нескольких эпиков (справа). Посмотрите на оба примера ниже.

Что может повлиять на расстановку приоритетов владельца продукта?

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

Сохраняя список необходимых требований (backlog) здоровым

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

Регулярный обзор (ревью) списка необходимых требований (backlog) в сфере Agile часто называют «уходом за бэклогом» (некоторые используют термин «уточнение бэклога»).

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

PRO TIP:

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

Анти-паттерны (шаблоны), за которыми нужно следить

Как список необходимых требований (backlog) продукта поддерживает гибкость команды?

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

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

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

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

PRO TIP:

Владельцы продуктов определяют приоритет элементов работы в списке необходимых требований (backlog), а команда разработчиков определяет скорость через список необходимых требований (backlog). Это может быть непростое отношение для новых владельцев продуктов, которые хотят «подтолкнуть» работу в команде. Узнайте больше в нашей статье об лимитах незавершенного производства и ходе работ.

По материалам Agile Coach «Backlogs»

Источник

Как мы работаем над проектами в Jira

Для команд, которые разрабатывают ПО, Jira — идеальная среда контроля и постановки, особенно для удаленных команд. Расскажем, как мы работаем над проектами в системе.

Преимущества Jira

Jira — гибкий инструмент. Есть много разных таск-трекеров: Basecamp, Trello, Asana, но Jira — не просто программа, она позволяет настраивать и контролировать бизнес-процессы по разработке до мельчайших подробностей. Она может работать как тот же Basecamp или Trello, но на самом деле возможности намного шире.

Не важно, делаете ли вы плакаты или программы, — все равно должен быть стандартизированный производственный процесс. Так вот, если есть регламент, то Jira поможет оцифровать его и контролировать.

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

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

Однако кроме явных преимуществ у Jira есть один, на мой взгляд, серьезный недостаток — ее сложно настраивать. Система не подходит для работы в команде, у которой еще не построены бизнес-процессы. Да, можно скрыть большинство функций и оставить в Jira функции, аналогичные, например, Trello. Но это нерациональное использование системы с лишними расходами на ее использование.

Если вы только начинаете бизнес по разработке, лучше выберите что-то более простое, а потом, набив шишки и выстроив все процессы, смело переходите на Jira.

Постановка задач

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

В нашей команде мы используем 7 типов задач:

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

Задачи Story, Task, Bug, Easy-task появляются в бэклоге. Сразу после создания задачи Jira в отдельном окне предлагает переместить ее в текущий спринт. Для перемещения задачи между спринтами можно использовать поле Sprint в окне просмотра задачи.

Процесс работы над задачами

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

Наш Воркфлоу.

Тот, кто ответственен за задачу, перемещает её по всему Воркфлоу. Вот такой путь проходят задачи в наших проектах в Jira:

Все задачи перемещаются по четкому Воркфлоу без пропуска этапов, за исключением специальных задач Quick-subtask и Easy-task. Для них используется упрощенный Воркфлоу.

Упрощенный Воркфлоу.

Структура задачи

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

Пример задачи проекта в Jira.

Обязательные поля

Необязательные поля

Оценка задач

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

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

Поработал над задачей — запиши затраченное время.
Поработал над задачей — запиши в комментариях, что было сделано.

Показатели здоровья проекта

Ещё одна причина, по которой мы ведём проекты в Jira — прозрачность процессов. Руководитель проекта и участники всегда видят, что и на каком этапе находится.

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

Главная причина работы в Jira

Если у вас есть вопросы по Jira, напишите нам.

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей!

Источник

Backlog in Jira

Introduction to Backlog in JIRA

The Backlog in JIRA is nothing but simply a list of requirements or features of that given software application, where the features of the application are not described in detail in the backlog. It is mainly described the list of tasks in the form of user stories with specific priority status i.e. brief description on each functionality of the software application from the user perspective.

How to Create a Backlog in JIRA?

The Backlog in JIRA is a set of issues or activities that can be handled by the team to resolve it within the time period. The steps to create a backlog in JIRA are:

Web development, programming languages, Software testing & others

Step 1: Click on the “+” sign at the JIRA dashboard and click on “Backlog” Icon.

Step 2: Fill the details in the create issue page i.e. select the name of the project, select Issue/task Type(It may Bug or Epic or Story), Write down Summary for Issue/task(Overall description), Description about it, Priority level(Low or Medium or High), Labels, Environment, Attachment related task, Linked Issues, Assigned To, Epic Link, Sprint, etc.

Step 3: Click on the “Create” button to create a new Backlog.

Activities Performed by Backlog in JIRA

There are multiple activities are performed by the backlog in JIRA tools. Such as adding of tasks or issues to the backlog, description of the task, to prioritize the task, create the task of the task (subtask), workflow status of backlog, finding of task or issue or deleting of task or issue and split of the task, mode of the transition of backlog and status of team workflow.

Advantages of Using Backlog in JIRA

Conclusion

In this article, we briefly discuss the backlog in the JIRA tool with its activities and creation procedure. We can filter the tasks or issues by using the Assignee name or by epic name or by specific labels used in the project or by the type of issues or tasks. In the JIRA tool, the product backlogs are used to create the sprint backlogs with proper priority level and if any bug finds, then we create a new backlog with a priority level for that team will work on it to resolve it.

Recommended Articles

This is a guide to Backlog in Jira. Here we discuss How to Create a Backlog in JIRA along with the activities and advantages. You may also have a look at the following articles to learn more –

All in One Software Development Bundle (600+ Courses, 50+ projects)

Источник

Jira Software Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Core

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Community

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

Versions

Creating your backlog

Getting started as a Jira Software manager

On this page

Related content

Still need help?

The Atlassian Community is here for you.

Your backlog is a list of tasks that represents outstanding work in a project. Usually, a project would have issues in the backlog, and you can add these issues to a sprint so your team can work on them. Since Teams in Space is a new project, you won’t have issues on your backlog. Let’s create some work for your team.

How do I get to my board?

If you navigate away from your board, you can easily return to it by selecting Boards from the top navigation menu, and selecting your board «Teams in Space» from the list of recent boards.

Backlog

The Backlog gives you a place to organize your sprints. You can create new issues or sub-tasks, organize your backlog, create versions, organize via epics, and start sprints.

Create issues

By default, any team member can create issues. In this tutorial, however, you will create all of the backlog issues.

On the Teams in Space board, choose Create at the top of the screen.

Fill in the fields using the data shown below. Only the fields with * are mandatory.

Tip! If you select the Create another checkbox, Jira Software will create your issue and automatically pre-populate a new ‘Create Issue’ dialog box with your previous issue details.

Add more issues

One issue isn’t enough to get your team working! Let’s add more issues so you can create and run a complete sprint. Create the following issues using the same steps as above.

Great! Your backlog’s all set! Now, let’s plan some work for your developers to do!

Источник

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

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

Бэклог продукта (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 может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.

Источник