Толпа сжигает диаграммы дотла: задачи или истории? [закрытый]

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

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

Количество задач бесполезно. Это число может изменяться каждый день, особенно если Вы даете "свободу" разработчикам. Они могут разделить задачу к меньшей части без изменения общего времени. Такая статистическая величина бесполезна. На что это указывает? Это влияет на цель спринта?

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

1. Прогресс дорожки для потребностей того клиента так их менеджер проектов имеет некоторое понимание, что происходит.
2. Оценки обзора против фактической работы потребовали для улучшения нашей оценки способности.
3. Клиенты счета в течение времени на самом деле потратили в случае, если это - часть задания почасовой ставки.
4. Дайте обратную связь разработчиков об их прогрессе, таким образом, они могут справиться с отвлекающими факторами соответственно.

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

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

И, в то время как я нахожу значение в проводящих мозговой штурм задачах при оценке истории, я предпочитаю иметь истории, которые являются достаточно маленькими, что нет никакого желания отследить их вообще. На самом деле получение кредита для законченных задач является очень вводящим в заблуждение, поскольку имеющий даже половину всех определенных задач, законченных все еще, не гарантия, что Sprint поставит любое значение вообще. И это - то, чем интересуются заинтересованные стороны в конце: сколько из спроектированного значения будет на самом деле поставлено?

Так, отслеживание историй и работа над дальнейшим разрушением историй и дают более точную обратную связь и снижают риск никакой доставки значения.

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

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

Если история занимает 2 дня для окончания, то у Вас есть плоская строка в течение 2 дней, и нет никакого способа сказать, сидит ли команда на их ползунках или той увеличенной работе (таким образом переход в часы задачи).

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

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

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

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

Другая полезная вещь, которую нашла моя команда, использует сложенную линейную диаграмму с одной строкой для каждого из, "Чтобы Сделать", "Происходящий", "Готовый к QA", и "Проверенный". Таким образом, легко видеть любую фазу в процессе, который создает резервное копирование.

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

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

После того, как команда поймет ценность разбиения историй на задачи, я хочу попробовать сжечь по историям. Так что иметь небольшие истории с максимум 5 или 8 очками истории. Из блога Джеффа Сазерленда, это большой шаг на пути к достижению командой высоких результатов.

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

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

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

Burndowns (или даже «выгорание») должно указывать только на оставшуюся работу.

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

Просто наметьте историй, оставшихся , чтобы завершить.

Это - более жесткая мера, но массировать цифры бесполезно - scrum должен сообщать плохие новости, чтобы все было исправлено.