Как работать задачи unestimatable в скрам, спринт? [закрытый]

Это "задачи", которые кто-то в мире делал раньше, или они просто новые для вашей команды. Я предположу позже. Если это так, то вы обнаруживаете, что у вас нет необходимого опыта в вашей команде для решения проблемы. Таким образом, вы будете развивать этот опыт по мере продвижения. Все это означает, что сложность ваших историй выше. В первой паре спринтов вы можете набрать некоторые из историй как 13, а затем позже они становятся 8s потому что тогда у вас есть необходимые знания.

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

Мне нравится резервировать "спайки" (да, это термин, используемый в scrum) для попытки решить проблемы бизнес-домена, которые не имеют известного решения. Не для того, чтобы команда занималась тренировками.

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

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

вы действительно имеете в виду задачи или вы говорите о продуктах Backlog Items (PBIs)? На самом деле, мне трудно поверить, что задача не оценены. Если они действительно не являются, они, скорее всего, слишком велики (задачи не должны превышать 16h, что уже огромно).

Если вы говорите о PBIs, ситуация, которую вы описываете, довольно удивительна и теоретически не должна произойти. В худшем случае просто назначьте им большое количество сюжетных точек, это точно означает, что там на них много неопределенности. Но, поскольку PBI, которые готовы к спринту, не должны превышать половину вашей скорости (или вы поставите слишком большой риск на свой спринт), очевидный способ решить эту ситуацию-разделить такие предметы на более мелкие куски, которые могут включать исследование. Но важная часть состоит в том, чтобы держать вещи timeboxed, даже (или особенно) R&D. Имейте в виду, что с Scrum все timeboxed.

другими словами, чтобы уменьшить неопределенность, разбить вещи на меньшие вещи (будь то предметы или задачи)!

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

разделить задач unestimatable в задачу устранить неопределенность, и "остальные". Удалите неопределенность с помощью тестов Proof-of-concept или решений spike. Либо запланируйте спайки в этом спринте и остальную работу в следующем спринте, либо отложите начало спринта на неделю спайков.

мы часто не знаем достаточно, чтобы разбить историю на задачи. У нас есть период открытий, прежде чем мы узнаем, какие задачи будут. "Шипы", кажется, сложно управлять. Например, вы не сможете время периода обнаружения. Во-вторых, я не могу эффективно планировать спринт, не зная, сколько времени займет история.

кажется, что другой вариант - сделать всплеск в Sprint 1 и задачи в Sprint 2. Недостатком является то, что кажется, что процесс заставляет неестественное срыв работы. Зачем открывать эту неделю, а затем подождать некоторое время, прежде чем начать работу.

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

вы путаете точность с точностью?

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

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

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

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

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

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

Это также подкрепляется работой Лэтэма по теории постановки целей, где он специально решает эту проблему.