Планирование Спринта — совещание Scrum-команды, которое часто носит характер мозгового штурма и направлено на нахождение ответов на следующие вопросы:

• Как спринт добавит стоимости продукту?
• Что можно успеть сделать?
• Как делать запланированную работу?

Результатом такого совещания является Бэклог Спринта (Sprint Backlog) — план, созданный разработчиками на спринт. План должен содержать как минимум:

• цель спринта, т.е. "почему мы это делаем?"
• задачи, которые необходимо завершить для достижения цели спринта и рождения инкремента с ожидаемым набором функциональностей, а также сложность или трудоёмкость задач. Помогает ответить на вопрос "что мы делаем?"
• план действий для успешного выполнения намеченных задач — "как мы это делаем?"

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

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

Бэклог спринта должен быть на виду и доступен любой заинтересованной стороне без отвлечения членов Scrum команды — помним о прозрачности.

Зачастую при оценке задач для определения объёма задач, которые команда может выполнить за спринт, используются безразмерные абстрактные величины. Story points являются примером таких величин.

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

Вопреки популярному мнению Scrum не обязывает использовать ни Story points ни другие абстрактные величины, однако крайне рекомендует именно эмпирическое планирование с учётом итеративной природы работы.

Эмпирическое планирование не запрещает использовать старые добрые человеко-часы.