Burn down chart что это
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Узнайте, как использовать диаграммы Burndown в Jira Software
Руководство по использованию диаграмм Burndown в Jira Software
Просмотр тем
Обучающее руководство по использованию диаграмм Burndown в Jira
Из этого учебного руководства вы узнаете, как можно отслеживать спринты и эпики с помощью диаграмм Burndown в Jira Software.
10 минут на прочтение.
Вы работаете над проектом в Jira Software и хотите отслеживать выполнение спринта или эпика.
Вы знакомы с основами Scrum и эпиков.
На диаграмме Burndown показан объем выполненной и оставшейся в эпике или спринте работы. С помощью таких диаграмм можно спрогнозировать, выполнит ли команда работу в срок. Они также отлично подходят для того, чтобы сообщить команде о расширении области проекта.
Диаграммы Burndown полезны, так как с их помощью можно проанализировать работу команды. Например:
Если команда постоянно заканчивает работу раньше срока, возможно, она берет недостаточно работы во время планирования спринта.
Если команда постоянно не выполняет работу в срок, возможно, она берет на себя слишком много задач.
Если на диаграмме Burndown наблюдается резкий спад во время спринта, возможно, работу неверно оценили по сложности или поделили на части.
Шаг 1. Определите принцип оценки работы в команде
Принцип оценки — это единица измерения, с помощью которой команда будет оценивать сложность работы. В Jira Software сложность работы можно оценивать в очках за пользовательскую историю, часах или придумать собственный принцип.
Принцип оценки важен, так как с его помощью определяется скорость команды. Скорость команды в каждом спринте равна сумме оценок завершенных историй. Если команда раз за разом подтверждает свою скорость, с помощью этого значения можно определить, какой объем работы она сможет выполнить за каждый спринт. Такая информация полезна при планировании спринта.
Как определить принцип оценки работы.
Кнопка «. »Перейдите на доску или в бэклог и нажмите (
) > Board settings (Дополнительно > Настройки доски).
Откройте вкладку Estimation (Оценка сложности).
Классические команды разработчиков оценивали работу с точки зрения времени, используя дни, недели и месяцы. Однако многие команды agile предпочли очки за пользовательскую историю. Если вы недавно начали осваивать agile или не знаете, какую величину выбрать, рекомендуем использовать очки за историю.
Шаг 2. Оцените сложность своих задач
В Agile оценка сложности подразумевает измерение размера бэклога команды или отдельной рабочей задачи. Под отслеживанием понимается наблюдение за этими показателями с целью соблюдения сроков выполнения работы.
Чтобы оценить сложность задачи, выполните следующие действия.
В проекте Scrum выберите задачу на доске или в бэклоге.
На панели информации о задаче нажмите поле Estimate (Оценка сложности).
Введите значение оценки.
Если в двух словах, да, можете. Но если вы измените подход к оценке после начала спринта, за этим последует изменение объема работ в диаграмме Burndown.
Не переживайте, если определить сложность задач не так просто. Обратитесь к нашему руководству по оценке сложности работы. В нем приведены советы и рекомендации по правильной оценке сложности задач.
Шаг 3. Отслеживайте прогресс команды с помощью диаграмм Burndown
Диаграмма Burndown для спринтов
В этом отчете показан объем работы, которую предстоит выполнить за спринт. С его помощью можно следить, сколько всего работы осталось в спринте, и предсказывать вероятность достижения цели спринта. Отслеживая объем оставшейся работы в течение спринта, команда может управлять ходом работы и реагировать на наметившиеся тренды соответствующим образом. Например, если по диаграмме Burndown видно, что команда может не достичь цели спринта, есть возможность принять необходимые меры, чтобы вернуться в ритм.
Чтобы просмотреть диаграмму Burndown спринта, выполните следующие действия.
Выберите Backlog (Бэклог) или Active sprint (Активный спринт).
Нажмите Reports (Отчеты) и выберите Burndown Chart (Диаграмма Burndown).
Пояснение к диаграмме Burndown спринта
Объем оставшейся работы. Красной линией показан объем оставшейся работы по оценкам команды.
Контрольная линия. Серая линия отображает приблизительное положение, которое занимала бы команда, если бы работа выполнялась линейно, без задержек или опережения графика. Если красная линия находится ниже серой, поздравляем — все идет к тому, что команда выполнит работу целиком до конца спринта. Но это не значит, что успех гарантирован. При отслеживании прогресса команды нужно уметь правильно пользоваться имеющейся информацией.
Диаграмма Burndown для отслеживания эпика
С помощью этого отчета можно увидеть, насколько успешно команда справляется с работой в эпике. Он оптимизирован для команд Scrum, которые выполняют работу в спринтах, и упрощает отслеживание. Диаграмму Burndown эпика можно использовать, чтобы:
увидеть, с какой скоростью команда работает над задачами в эпике;
оценить, как увеличение или уменьшение объема работ во время спринта повлияло на общий прогресс команды;
предсказать, за сколько спринтов будет завершен эпик, на основе информации о прошлых спринтах и изменениях в ходе спринтов.
Чтобы просмотреть диаграмму Burndown эпика, выполните следующие действия.
Выберите Backlog (Бэклог) или Active sprint (Активный спринт).
Нажмите Reports (Отчеты) и выберите Epic Burndown (Диаграмма Burndown эпика).
Выберите эпик в раскрывающемся списке рядом с заголовком Epic Burndown. Вы сможете выбрать нужный эпик из проектов, которые настроены для вашей доски, с помощью фильтра доски.
Пояснение к диаграмме Burndown эпика
Добавленная работа. Сегменты темно-синего цвета отображают объем работы, добавленный в каждый спринт эпика. В этом примере объем работы измеряется в очках за пользовательские истории.
Оставшаяся работа. Сегменты светло-синего цвета отображают оставшийся объем работы в эпике.
Выполненная работа. Сегменты зеленого цвета отображают объем работы, выполненной в рамках каждого спринта в эпике.
Ожидаемое время завершения. В отчете показано, сколько спринтов потребуется для завершения работы над эпиком с учетом скорости работы команды.
Нужна дополнительная информация?
Подробнее об оценке работы можно узнать в нашем руководстве, посвященном очкам за пользовательские истории и оценке сложности в Agile.
Чтобы узнать больше о диаграммах Burndown релиза, обратитесь к нашему руководству по версиям.
Чтобы узнать больше о диаграмме Burndown для спринтов в Jira Software, обратитесь к нашей документации по диаграммам Burndown. О диаграммах Burndown эпика см. в нашей документации по диаграммам Burndown для отслеживания эпиков.
Чтобы узнать больше о показателях Agile-команды, обратитесь к нашему руководству по показателям.
Чтобы узнать больше о ведении проектов Scrum в Jira Software, обратитесь к нашему руководству, посвященному применению Scrum в Jira Software.
Диаграмма сгорания задач / Burndown Chart
В большинстве своем мы привыкли к графикам, идущим вверх, что означает положительную динамику. Однако они могут идти и вниз и также показывать положительную динамику. Одним из таких ярких примеров является «Диаграмма сгорания задач» (Burndown Chart). Само сочетание Burn Down дословно переводится как «гореть вниз» и, действительно, это так. Данный график является основным средством для отслеживания выполненных задач в спринте или во всём проекте. Хотя, по сути, он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum.
Пример Диаграммы сгорания задач:
Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться.
Красным отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.
Как может показаться на первый взгляд, данная «Диаграмма сгорания задач» (Burndown Chart) служит всего лишь для самоконтроля и самоотчета, однако её использование может рассказать об очень многом.
Читаем «Диаграмму сгорания задач» / Burndown Chart
Начнём с примеров негативных результатов как ведения графика, так и самой работы команды, и закончим более качественными.
1. Burndown Chart: Слишком рано
По «Диаграмме сгорания задач» (Burndown Chart) отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем:
В случае такой проблемы чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog.
2. Burndown Chart: Опоздали
Также один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач во время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны наполовину. Такие задачи, как выразился Джефф Сазерленд, «являются хламом».
В такой ситуации на Daily Scrum Meeting обязательно нужно говорить о проблемах, мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше, сразу надо решать проблему – это также один из постулатов методологии Scrum.
3. Burndown Chart: Без оценок
Может быть даже команда и работала, только забыла или не захотела использовать диаграмму сгорания задач, что является, прямо сказать, дурным тоном и противоречит эффективной работе. Команда не может контролировать себя, не может совершенствоваться и так далее.
4. Burndown Chart: Конечная оценка
Собственно, ситуация равна предыдущей. Несмотря на законченный Sprint, все итоговые оценки были внесены в диаграмму сгорания в самый последний день после завершения работы. Это равносильно тому, когда законченные задачи вообще не вносятся. По данному графику невозможно сделать выводы о правильности работы команды, и, даже более того, можно предположить, что команда не стремится к развитию.
5. Burndown Chart: Zero
Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться.
6. Burndown Chart: Релаксирующая команда
Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь в нём можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.
7. Burndown Chart: Совершенствование
Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу, ведя команду к цели.
Также, возможно, группа делала принципиальное ускорение для достижения цели.
Ещё одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.
8. Burndown Chart: Опыт
Налицо опытная группа, которая после начала работы сразу преодолевает все возникающие трудности и совершенствуется так, что резко переходит к активному сжиганию.
9. Burndown Chart: A++
Бесконечно можно смотреть на три вещи: как горит огонь, как течёт вода и как строится идеальный график =).
Scrum Sprint
Диаграмма сгорания задач является главным показателем для Scrum Sprint. Выполнение задач во время Спринта, должно всегда оцениваться и контролироваться диаграммой сгорания задач.
Product Backlog
Правильно составленный беклог, приведет соответственно к правильному Sprint Backlog. Грамотный Sprint Backlog построит самую идеальную диаграмму сгорания задач.
Daily Scrum Meeting
Scrum Team
Эффективность команды отображается на таких показателях, как Velocity и Burndown Chart. Чем идеальней диаграмма сгорания задач, тем более эффективно работает Scrum Team, так как это прямой показатель.
Scrum Master
Scrum: Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)
Что такое Спринт (Sprint) в Скрам (Scrum)
Спринт – это промежуток времени в течение которого идет работа над запланированной работой (обычно от 1 до 4 недель). Величина спринта планируется из того как быстро вы можете завершать проекты в рамках работы вашей команды.
В IT-сфере в идеале в конце каждого спринта выдавать обновленную версию продукта с улучшениями и дополнениями.
Что такое спринт в скрам
Например, весь проект может занимать 5 месяцев, разбитых на 21 недельный спринт по 7 дней.
В начале каждого спринта составляется план проектов на спринт, а в конце подводятся итоги спринта и ретроспектива (обратная связь от членов команды по поводу того, что можно как можно улучшить работу команды в следующих спринтах).
Планирование спринта обычно организует scrum-мастер и на нем product owner садится совместно с командой и решают какую часть продукта выпустить к концу спринта, и какие задачи из бэклога нужно для этого выбрать.
Как оценить силы команды на Spint (показатель Velocity)
Немаловажным вопросом во время планирования спринта является оценка сил команды для выполнения проектов в спринте – для оценки сложности проектов по трудозатратам используются специальные величины Story Points (SP)
Сложность любой задачи оценивается в определенном количестве Story Points (SP).
Чтобы понять лучше, что такое Story Points – вспомните простые элементы в конструкторе – это и есть SP, и из них можно собрать любую фигурку (задачу), или даже целую композицию из фигурок (проект).
Среднее количество Story Points в одном спринте называется Производительность команды за спринт (Sprint velocity) и рассчитывается делением суммы прошлых спринтов на количество выполненных Story Points.
Как оценить среднюю производительность за спринт (Sprint velocity)
Как оценить сложность задачи – играем в Planning Poker.
Сколько story points в индивидуальной задаче обычно каждый сотрудник оценивает сам на основании предыдущего опыта. Если задачи командные, то как правило проводится отдельное совещание, которая называется называется Planning Poker.
Опытные члены команды держат в руках карточки с написанным на них количеством SP (например могут быть номиналы по 1,3,5,10,50,100 SP), Product owner из общего списка задач (бэклога) задачи достает задачи по одной в порядке приоритетности, а участники игры показывают карточки SP, которые они бы дали этой задаче.
Оценка сложности задач происходит на основании их предыдущего опыта (чем более опытный сотрудник, тем точнее оценка как правило). Менее опытные члены команды также присутствуют на таких совещания, чтобы перенять опыт оценки трудозатрат в задачах.
Story points – это универсальная величина, которой могут измеряться задачи из абсолютно разных сфер деятельности.
Например:
– провести совещание = 5sp, подготовить коммерческое предложение = 15sp, сделать 40 звонков клиентам = 10sp;
– Разработать модуль API – 25sp, сделать форму регистрации 7sp;
– Прочитать 1ю часть книги 10sp, прочитать 1ю главу 2sp;
– Приготовить суп 10sp, сходить в магазин 5sp, пропылесосить в комнате 2sp и т.д.
Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)
Во время планирования спринта для Product Owner важно сделать 2 вещи:
1.Определить приоритетные цели для спринта
2.Грамотно оценить силы команды в Story Points на основании прошлого опыта, чтобы команда выполняла задачи равномерно по мере спринта.
Для этой цели ежедневно заполняется Диаграмма сгорания задач – график который показывает как уменьшается количество оставшихся Story Points по мере приближения к концу спринта (дедлайну).
График состоит из 2х осей: по вертикали – количество story points, по горизонтали – время
Диограмма сгорания задач (Burndown Chart)
На графике выше мы видим короткий спринт, который состоит из 7 дней. В среднем за такой спринт спринт команда выполняет задач на 50sp. Это значит что в среднем для того чтобы за 7 дней выполнить день нужно выполнять 7sp
Если команда опережает средние темпы, то линия уходит под график, это значит команда недооценила свои силы и поставила слишком легкие задачи.
Если линия сгорания story points уходит вправо от графика, это значит наоборот, команда переоценила свои силы, неправильно оценив объем работы в SP.
Нужно стремиться чтобы линия сгорания задач шла как можно ближе к идеальной прямой линии. С ростом опыта команды, растет точность оценки сложности задач в SP и график более плавно движется вдоль идеальной линии.
Совет из практики:
Рекомендуется держать некоторое количество задач наготове на случай, если выполнишь план на неделю быстрее. Список этих задач обычно называется коротким названием Next-up (Следующие) и по окончанию предыдущего спринта, он служит в качестве основы для формирования задач на новый спринт.
В чем польза диаграммы сгорания задач (Burndown chart) для руководителя:
Руководитель проектов / директор компании может смотреть как общую диаграмму сгорания задач (Burndown chart) как по отдельным проектам, так и индивидуально по каждому сотруднику, это позволяет быстро оценить текущее положение дел.
Также может строиться сводная Диаграмма сгорания задач (Burndown chart) по всему портфелю проектов.