Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании.
Она будет полезна всем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. Для краткости назовем их стейкхолдерами. Стейкхолдеры опасаются, что при переходе к Scrum и agile команды перестанут брать на себя обязательства по реализации требований к определенному сроку. В этой статье мы разберемся, почему разработчикам так сложно называть сроки. И как после перехода в Scrum и agile сохранить уверенность, что команда сделает доработки к определенному сроку.
Статья будет полезна и разработчикам. Часто стейкхолдеры спрашивают сроки у разработчиков, оставляя за собой право на изменение требований. А разработчики еще даже не знают, как реализовать то, что хотят стейкхолдеры. В этой статье мы разберемся, почему сроки так важны для стейкхолдеров и как можно вести диалог о сроках, сохраняя при этом гибкость.
Обе стороны обнаружат в статье ценные рекомендации, которые помогут сгладить противоречия и наладить эффективное взаимодействие, сохранив ценности и принципы agile.

Статья делится на две части: теорию и практику. В теории осветим методы гибкого планирования в Scrum и agile с возможностью устанавливать сроки. Эта часть написана на основе статей и книг Майка Кона. В практике рассмотрим алгоритмы кратко- и долгосрочного планирования в соответствии с рекомендациями Майка Кона и моим опытом.
Пару слов о себе. Я старший скрам-мастер в Росбанке. Помогаю организовывать работу 2 скрам-мастеров и 9 команд, насчитывающих до 100 человек. Более 12 лет в IT, успел попробовать себя в шкуре разработчика, аналитика и руководителя проектов. Погрузился в мир agile и Scrum и не вынырнул. Проверяю свой опыт с помощью сертификаций: PMP, PSMII, A-CSM, PSPOI. На Хабр пришел делиться знаниями и практиками разработки ПО, в полезности которых убедился на своем опыте.
Теоретическая часть
Kudos to Mike Cohn

В первую очередь хочу выразить признательность Майку Кону. Именно его книги и статьи привели меня в agile и Scrum. Я помню себя руководителем проектов, который только-только сдал сертификацию PMP и думал: «Ну вот теперь-то все мои проекты будут укладываться в сроки и бюджет, а объем требований не будет увеличиваться!» Ситуация на моих проектах изменилась не сильно.
В то же время моя жена попала на проекты, где работали по Scrum. И каждый день рассказывала, насколько это круто. Как довольны были и стейкхолдеры, и разработчики. Я относился к этим рассказам с недоверием. Потому что о Scrum у меня тогда было представление: «Команды на себя никаких обязательств не берут». «Как же, — думал я, — теперь укладываться в сроки?». В этот момент жена подсунула мне книгу Майка Кона «Agile: оценка и планирование проектов». Прочитав ее, я понял, что мое представление ошибочно, и решил попробовать Scrum в своих командах. Выходит, благодарить мне надо не только Майка Кона, но и свою жену
