Вопрос о планировании спринта. Предположим, что скорость команды равна 20 Story Points (SP). Наиболее ранними историями в бэклоге продукта являются A (12 SP), B (5 SP) и C (4 SP).
Нетрудно заметить, что если мы возьмем все три задачи (21 СП), скорее всего, мы не закончим задачу С. Но если мы возьмем только А и Б (17 СП), то закончим спринт раньше.
Есть два возможных решения:
Кажется, что эти два решения похожи. Но, на мой взгляд, разница есть. Это мотивация.
Первое решение: это будет мотивировать команду поторопиться. Но демотивировать, если команда не будет делать всю запланированную работу. По моему опыту чаще встречается второй случай.
Второе решение: я видел, что работа обычно занимает все запланированное время. И это не связано с тем, как именно мы выделяем время на эту работу. Итак, если мы запланируем только две задачи в спринте, мы, скорее всего, выполним эти две задачи за весь спринт.
Что Скрам говорит об этом? Какой путь мы должны использовать?
Scrum — это не только завершение историй. Речь идет о создании ценности для бизнеса. Итак, вы должны начать с обсуждения и согласования цели спринта. Затем команда разработчиков может провести дальнейшее обсуждение и переговоры с владельцем продукта. Например, команда разработчиков может предложить убрать некоторые навороты из одной истории или изменить другую историю — и все это в интересах достижения цели спринта. Но окончательное решение принимает Владелец Продукта.
После этого скорость, стори-поинты и расстановка приоритетов — хорошая отправная точка для определения размера. Но помните, что скорость не может быть точным числом. Это может быть только диапазон - что-то вроде 20-25. Однако ваш вопрос остается в силе. Выжимаем ли мы больше, чем команда может сделать, или планируем безопасно?
Что Скрам говорит об этом?
Скрам хочет, чтобы команда создала потенциально готовый к поставке инкремент продукта в конце спринта. Таким образом, в конце спринта, увидев обзор спринта, владелец продукта должен иметь возможность сказать: «Хорошо, отправьте (или разверните)!» Таким образом, команда разработчиков должна помнить об этом и делать соответствующие выводы.
Вы также можете попробовать то, что предложил @CarynRose, и попытаться разделить истории на более мелкие части.
Один вариант, который я исследовал: если команда добилась хорошего прогресса в первых двух историях, я добавляю третью историю в середине спринта. Однако я всегда спрашиваю: «Вы уверены, что можете добавить это сейчас, полностью закончить и быть готовым к отправке?» Если есть какие-то сомнения, я не добавлю.
Другой вариант: во время планирования спринта, если есть пропускная способность, вы можете запланировать ограниченную по времени исследовательскую историю, чтобы снизить риск в элементе невыполненной работы (конечно, после консультации с владельцем продукта).
В идеале разбить большую историю. Но есть продуктивные способы использовать оставшееся время в спринте. Как насчет:
Я думаю, что задачу с 12 сюжетными баллами, вероятно, можно было бы разбить на 2 задачи меньшего размера, чтобы у вас были A, B, C и D, которые могли бы поддаваться другой расстановке приоритетов.
Это наиболее распространенная проблема, с которой сталкиваются при планировании проекта. И решение кроется в природе проблемы. В вашем случае, если другая команда зависит от AB или C, это будет иметь высокий приоритет и ДОЛЖНО быть выполнено в этом спринте. Точно так же, если нет зависимости ни от одной из Storypoint, и вы можете выпустить работающий продукт без нее. Идеально перенести эту историю в следующий спринт и осветить ее как часть элементов невыполненной работы по продукту.