У нас возникло 3 незапланированные задачи, как видно справа внизу. Об этом полезно будет вспомнить на ретроспективе.
Вот пример настоящего sprint backlog’а ближе к концу спринта. Он, в самом деле, становится довольно беспорядочным по ходу спринта, но ничего страшного, так как это ненадолго. На каждый новый спринт мы начинаем sprint backlog с чистого листа.
Как работает burndown-диаграмма
Давайте присмотримся к burndown-диаграмме:
Вот о чем она говорит:
• В первый день спринта, 1-го августа, команда определила, что работы осталось примерно на 70 story point’а. Это как раз и есть прогнозируемая производительность на этот спринт.
• 16-го августа работы осталось примерно на 15 story point’а. Пунктирная направляющая показывает, что они на верном пути, то есть в таком темпе они успеют закончить все задачи к концу спринта.
Мы пропускаем выходные по оси X, так как в это время редко что-то делается. Раньше мы их включали, но burndown при этом выглядел странновато, так как он «выравнивался» на выходных, и это походило на повод для беспокойства.
Тревожные сигналы на доске задач
Беглый взгляд на доску задач должен дать возможность любому человеку понять, насколько успешно продвигается итерация. ScrumMaster несёт ответственность за то, чтобы команда принимала соответствующие меры при обнаружении первых тревожных симптомов:
Эй, как насчет отслеживания изменений?
Лучший вариант отслеживания изменений, который я могу предложить при данном подходе — это делать фотографию доски задач каждый день. Делайте так, если это необходимо. Я тоже иногда так делаю, хотя ещё никогда не возникало необходимости пересматривать эти фотографии позже.
Если отслеживание изменений для вас очень важно, тогда возможно подход с доской задач вам вообще не подходит.
И все-таки, я бы предложил вам сначала оценить значение детального отслеживания изменений в спринте. После того как спринт закончен и рабочий код вместе с документацией был отослан заказчику, будет ли кто-нибудь разбираться, сколько историй было закончено на 5й день спринта? Будет ли кто-нибудь волноваться о том, какова была реальная оценка для задачи «Написать приемочный тест для истории Депозит» после того, как история была закончена?
Как мы оцениваем: в днях или часах?
В большинстве книг и статей, посвящённых Scrum'у, для оценки времени выполнения задач используются часы, а не дни. И мы так раньше делали. Общая формула была такой: один эффективный человеко-день равен шести эффективным человеко-часам.
Однако мы отказались от этой практики по следующим причинам: