Остервальдера или другие.
Полная схема Scrum
В результате описанного выше процесса, который иногда называют нулевой итерацией, у вас появляется начальное наполнение бэклога и теперь можно запускать спринты, которые объединяются в более крупный релизный цикл, как это изображено на полной схеме Scrum.
Почему релизы не выпускаются каждую итерацию, если она итерация должна поставлять ценность? Дело в том, что темп выпуска релизов определяется не внутренней скоростью разработки, а характером взаимодействия с рынком – проведением рекламных компаний, привлечения групп пользователей и так далее. Все это разворачивается в собственном темпе. То же можно сказать и про корпоративную разработку: внедрение нового функционала требует изменения бизнес-процессов и обучения пользователей, и эти процессы разворачиваются в собственном темпе. При этом технически новый функционал уже может быть в продукте.
Релизный цикл накладывает свой отпечаток на спринты, могут появляться отдельные спринты стабилизации и выпуска релизов, в некоторых проектах после выпуска может быть предусмотрен спринт срочных доработок по запросам пользователей, или даже переключение в потоковую обработку задач до стабилизации.
Подготовка бэклога к спринту.
Как написано выше, предварительный бэклог наполнен крупными задачами, для которых известен только принципиальный способ реализации. Они несут значительную долю неопределенности, которая недостаточна для уверенного планирования спринта. Поэтому до планирования задачи бэклога, которые с большой вероятностью будут включены в спринт, необходимо дополнительно детализировать. Возникает естественный вопрос: а насколько подробно необходимо прорабатывать задачи, кто именно их оценивает. На этот вопрос есть следующий функциональный ответ: содержание задачи должно быть проработано настолько, чтобы (а) Product Owner был уверен, что выполнение этих работ принесет стейкхолдерам желаемую ценность и (б) Команда могла оценить трудоемкость выполнения этих работ на планировании. Не меньше, но и не больше. Потому что именно на основании оценки задач и принимается решение, что помещается в спринт, а что – нет. Однако, использование только функционального ответа недостаточно, потому что разные люди будут по-разному давать ответ на этот вопрос. Поэтому хорошей практикой является разработать чек-лист Definition of Ready, формулирующий критерии готовности задачи к планированию.
За подготовку и необходимую детализацию задач отвечает Product Owner. Как уже говорили, Она выполняется не заранее, а по мере продвижения проекта только для ближайших спринтов. Потому что детальные проработки проекта целиком имеют печальное обыкновение сгнивать раньше, чем добираются до реализации, и оказываются бесполезной работой.
Если такая подготовка задач к будущему планированию требуют заметных трудозатрат, то их надо планировать в предыдущим