Scrum: как обрабатывать элементы журнала, которые длиннее одного спринта

Я начинаю со SCRUM, и у меня проблема с пониманием одной вещи. Как SCRUM обрабатывает элементы журнала невыполненных работ, которые занимают более одного спринта?

Такие предметы называются Epic и должны быть разделены на меньшие пользовательские истории, которые короче, чем один спринт, и из-за этого их можно планировать, или Theme, которые будут разделены на Epics и те на общие истории. Эпики и Темы имеют общую характеристику - высокий уровень неопределенности = они не могут быть правильно оценены (оценка обычно очень высока и из-за этого они не вписываются в один спринт).

Поэтому хорошо начинать с таких историй, но вы не можете планировать их, пока владелец продукта не разбивает их на более мелкие конкретные истории. Эти истории используются только для того, чтобы отметить некоторые более крупные запрашиваемые функции (Epic) или целые наборы функций (Theme). Нарушение этих историй сделает эту особенность особенной.

Это также следует айсбергской структуре отставания продукта.

У вас нет таких предметов. Если это так, то элемент отставания недостаточно конкретен и не был должным образом разбит на более мелкие элементы. Некоторые люди называют их не отставанием, а толстыми предметами, и в Scrum они считаются анти-паттернами.

История пользователя аналогии с пирожными: как любитель пирожных, я хочу съесть пирог во второй половине дня. Я не могу съесть целый пирог за один день, поэтому его нужно нарезать так, чтобы оно соответствовало количеству, которое я могу съесть.

Когда Scrum был впервые «изобретен», спринт по умолчанию обычно составлял 4 недели.

Согласно тому, что мне сказали, причина этого очень длинного размера спринта была просто потому, что людям в то время было очень трудно представить, что вы могли бы достичь чего-либо в более коротких спринтах.

По мере того, как команды стали более уверенно относиться к scrum, они узнали, как лучше разделить элементы невыполненных заказов на более мелкие элементы более удобного размера, и команды разработчиков стали лучше не переусердствовать с предварительным дизайном, а просто делать достаточно.

Сегодня я полагаю, что большинство команд считают 4 недели очень большой продолжительностью спринта. У меня сложилось впечатление, что 2 недели вполне нормально. Команды XP проводят итерации всего за 1 неделю и заканчивают полные пользовательские истории в каждой итерации.

Таким образом, вам нужно лучше разделить элементы невыполненных заказов на более мелкие элементы, каждый из которых дает небольшой прирост стоимости бизнеса для конечного продукта. Возможно, это было доказано. (хотя я не исключаю, что могут быть очень специализированные домены, где это будет сложно)

Я согласен с тем, что в эти дни спринт длился 4 недели. Вы хотите уменьшить цикл обратной связи и научиться лучше обрабатывать небольшие единицы работы за более короткие итерации. Таким образом, будет меньше ошибок, меньше изменится и меньше сложностей в управлении за один раз.

Разделение историй часто является проблемной областью для людей, но с каждым разом вы становитесь лучше. Работайте в тесном сотрудничестве с ПО, чтобы выяснить, можете ли вы доставить его поэтапно и при этом сохранить ценность в спринте.

Вот отличный постер, который помогает разбивать истории, его можно найти на веб-сайте agileforall.com, и вы можете найти этот пост здесь, его действительно полезно использовать для уточнения элементов журнала невыполненных работ:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Также хорошо иметь свое определение готового, когда вы дорабатываете и планируете, чтобы вы могли помнить об этом, когда выполняете что-то за один короткий спринт.