Оценка сюжета в Scrum

Question

Мы начали проект, который будет управляться с помощью Scrum/XP. Мы написали весь портфель продуктов для оценки в целях оценки. Мы делаем, что все истории являются ориентированным на клиенте, и мы оцениваем их

• история стоимость бизнеса: МОСКВЫ техника - Должно, должно, может, будет/не будет иметь это реализовано
• история усилий/сложности (= история баллов): 1, 2, 3, 5, 8, 13, 21, 100 - связанные с рассказа сложности/усилий, а не идеальных дней продолжительность

100 сюжетных точек может иметь некоторые истории с В/Не будет потому что они на самом деле являются более сложными историями, которые будут разбиты позже, если потребуется.

Расчет Значимость истории основана на значении & усилием, не перекрывая истории MoSCoW.

Но без 100 точечных историй наши истории до сих пор (также разбиты) имеют сложность между 2 и 8, что, по нашему мнению, является подходящим размером истории, чтобы избежать микроуправления. Но некоторые истории стали связаны друг с другом. У нас есть истории, которые могут занять больше, если их сделать в первую очередь, и меньше, если какая-то другая история будет сделана до них.

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

Answer 1

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

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

Помните, что с Velocity вы начинаете с догадки о том, что можете выполнить. Обычно это происходит только после того, как вы нажмете на 3-й или 4-й спринт, определите реалистичную скорость, которую команда может управлять. Да, это означает, что вы, возможно, предположили, что команда может доставить 20 очков за Спринт и на самом деле может делать только 15 очков. Да, это означает, что время доставки гаснет или истории падают ниже линии разреза.

Что касается зависимых рассказов, вы должны работать с владельцем продукта. Если команда говорит с ними, вы обычно можете перестроить истории. Большинство людей восприимчивы к тому, кто говорит им: «Если мы сделаем А, теперь он возьмет полный Спринт, но если мы это сделаем, то позже это займет 15% от Sprint», что делает его довольно убедительным.

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

Надеюсь, что эта информация полезна.

Answer 2

Я могу описать только свое времяпрепровождение.

Когда мы планировали первый спринт, мы решили, что мы можем выполнить 18 очков. Таким образом, мы взяли несколько историй, и общая оценка составляла 15 очков. Как я уже упоминал выше, мы делали первые шаги в схватке, поэтому мы решили, что 3 неиспользованные точки и форм-фактор 0,6 гарантируют наш успех.

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

В результате мы провалили наш первый спринт только с 8 точками.

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

Но второй спринт был намного лучше, и мы сделали почти все (на самом деле мы сделали все, но с некоторыми ошибками). Я думаю, что мы примем меньше форм-фактора в третьем спринте, и он будет успешным.

Answer 3

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

Например: - задание 3 - это 8 баллов, если выполнено после задания 2, но 12 баллов, если выполнено независимо.

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

Удачи!

Answer 4

Есть несколько шаблонов, которые помогут вам разбить User Stories таким образом, что они останутся INVEST, что означает, что вы попытаетесь сохранить зависимости, размер, тестируемость и ценность в частности. Вы можете узнать больше об этом здесь: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Ричард активно применяет и совершенствует их, и он не одинок ;-)

Просто имейте в виду, что разделение и сохранение зависимостей (это похоже на создание критического пути в диаграмме Ганта) собирается превзойти способность команды проявлять творческий подход и вести переговоры по этим историям, а также может скрывать «неценовое предложение».

НТН
ANdreaT