Scrum сжигает графики, могут ли они стать отрицательными?[закрыто]

Question

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

Мой вопрос в том, как вы справляетесь с выгоревшими графиками, когда вы превысили свои обязательства по спринту?Я могу придумать два варианта:

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

Конечное решение для моей команды - это то, которое понятно бизнесу и приносит реальную пользу разработчикам.До сих пор ни одно из этих решений не сработало идеально.

Answer 1

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

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

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

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

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

Answer 2

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

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

Редактировать

• Прогоны показывают работу, оставшуюся для завершения "чего-то" (спринт, релиз, MMF / "Epic" и т.д.).
• Выгорание показывает накопление "чего-то" (заработанной ценности для бизнеса, преодоленной сложности и т.д.).
• Совокупные технологические схемы показывают и то, и другое + дают вам представление о качестве вашего процесса

Answer 3

Когда мы добавляем больше элементов в спринт, мы обновляем оценка оставшейся работы чтобы отразить это на графике выгорания спринта:

альтернативный текст http://www.movingsummit.co.uk/images/burndown_chart.JPG

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

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

альтернативный текст http://www.movingsummit.co.uk/images/burnup_chart.JPG

Answer 4

Расширение оси Y действительно дает всем понять, что вы идете выше цели спринта.Обычно это не является большой проблемой, потому что вы не придаете этому большого значения.

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

Answer 5

Расширение оси Y графика выгорания ниже нуля является хорошо зарекомендовавшей себя практикой для отслеживания освобождение прогресс.

Примерная диаграмма выгорания выпуска

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

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

Answer 6

Если вы постоянно становитесь негативным из-за своего выгорания, это будет указывать на то, что вы постоянно переоцениваете, тем самым завершая свою работу "слишком рано".Чтобы исправить это, начните умножать оценку на коэффициент меньше 1 (т.е.0.75, 3/4) (я забыл правильный термин для этого - это "масштабирование"?).Сделайте это в течение одного-трех спринтов, посмотрите, как это влияет на результат, может потребоваться пара итераций, чтобы получить правильный коэффициент для каждого разработчика.Это означает, что вы сможете больше вписаться в обычный спринт, и он не должен заканчиваться рано.

Answer 7

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

А как насчет Владельца продукта?Насколько сильно вы хотите сообщить о том, что перевыполнили свои обязательства?Насколько важно для команды различать эти два случая и использовать их в ретроспективе для анализа того, как улучшить оценки в следующий раз или взять на себя обязательства с самого начала?Аналогичный подход был использован для определения альтернативной диаграммы выгорания (http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown), поэтому изменение основы диаграммы и сокращение ее объема явно показывают возросший охват, а увеличение может быть связано с тем, что команда обнаружила новые задачи, начиная работать над историей где-то в спринте ;-)

Ciao
АНдреаТ