Когда ваша команда по схватке закончила работу по спринту на ранней стадии, каковы официальные правила/рекомендации по принятию дополнительной работы?

Ответ 1

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

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

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

Начиная с следующего пункта, это, конечно, еще один вариант. Если вы не можете закончить это, Lex Scrum говорит, не трогайте его. И мне нравится этот закон в какой-то степени, потому что он фактически создает слабину, которая может быть использована разработчиками... как исправление ошибок и возврат технического долга. Если реализация другой истории - лучшее использование вашего времени: найдите тот, который вы можете закончить. Если вы не можете найти/создать один, это фактически препятствие, которое вы только что нашли. Предполагая, что мы говорим хотя бы о чем-то вроде 4hours для 2-3 разработчиков, мы действительно должны иметь возможность найти что-то полезное для реализации с этими ресурсами, не так ли?

Ответ 2

Если вы принимаете только новую работу, которую знаете, команда может закончиться на данной итерации? Можно ли запустить следующий элемент с большим приоритетом, даже если вы знаете, что у команды нет времени, чтобы закончить его?

Помните "Физические лица и взаимодействия над процессами и инструментами" Сделайте то, что вам подсказывает ваш здравый смысл. Не слишком зацикливайтесь на инструментах и ​​процессах.

В соответствии с руководством Scrum объем работы, которую Команда обязуется, полностью зависит от Команды.

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

Если команда до конца заработает все элементы отставания, команда обязательно должна заняться еще несколькими.

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

Чтобы ответить на вопрос окончательно, Scrum говорит, что вам следует договориться с Владельцем продукта и о необходимости дополнительной работы.

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

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

Ответ 7

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

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

Ответ 8

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

• Сократить технический долг
• Используйте время, чтобы узнать что-то ценное
• Пусть команда возьмет "Золотая карточка" . Они вовремя, они, вероятно, заслужили это.
• Разделите следующую историю на более мелкие (хотя и все еще значимые) истории, первая из которых может быть завершена к концу спринта.
• Если следующая история не может быть завершена, как указано выше, сделайте следующую историю, которая может быть завершена вовремя.

Надеюсь, что это поможет,
Ассаф.

Ответ 9

Вот что делают мои команды -

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

Во-вторых, если команда решает, что они могут обрабатывать X больше пунктов работы, тогда они переходят к ПО и подтверждают приоритет отставания и находят одну или несколько историй, которые суммируются с этими точками Х. Иногда им приходится немного отставать от отставания, чтобы найти те, которые подойдут. Пока PO в порядке с окончательным выбором, команда движется вперед с новой работой.

В-третьих, любая новая работа, которую выбирает команда, имеет тот же уровень обязательств, что и исходная работа. Любые частично завершенные истории в конце спринта потерпели неудачу.

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

Ответ 10

Я думаю, что решение ненасильственного спринта может состоять в том, чтобы остановить спринт. Если команда выполнила эту работу, спринт закончится. Другой вариант добавления большего количества историй в резервный спринт слишком рискован, и редко команда на 100% уверена, что сможет справиться со всей дополнительной работой. Насколько я знаю, нет правила, что спринт (пусть скажем, 2-недельный) не может быть закончен на 2 или 3 дня раньше.

Ответ 11

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

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

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