Оценки историй в Scrum [закрыто]

Question

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

• ценность истории для бизнеса: Москва техника - Должен, должен, мог бы, будет/не будет это реализовано
• сложность/сложность сюжета (= сюжетные очки):1, 2, 3, 5, 8, 13, 21, 100 — связаны со сложностью/усилиями истории, а не с идеальной продолжительностью дней.

100 очков истории могут включать в себя несколько историй с «Было бы/не было бы», потому что на самом деле это более сложные истории, которые при необходимости будут разбиты на части позже.

Рассчитано важность истории основан на ценности и усилиях и не дублирует истории MoSCoW.

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Удачи!

Answer 3

Я могу только описать свой опыт.

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

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

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

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

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

Answer 4

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

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

ХТХ
АНДРЕАТ