Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.
Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.
Расчет времени, необходимого на выполнение задачи одновременно и очень простая и очень рискованная задача, с которой сталкиваются команды разработки.
Неверная оценка становится одной из первых причин срыва графиков или даже провала проекта.
Проблема в том, что бизнес рассматривает оценки как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».
К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:
Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.
Срочные встречи, рабочие письма, мессенджеры и упавший таск-менеджер еще больше запутывают и без того сложный процесс разработки, что делает идеальные часы, которые мы воображаем во время выставления оценок слабо полезными для менеджера проекта, пытающего собрать стремительно устаревающую диаграмму Ганта.
Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.
Естественно, подход с использованием SP не первая попытка решить озвученные проблемы, хотя и, вероятно, самый популярный.
В этом блоке я расскажу еще об одной программе, включающей в себя схему оценки задач. Программы называется PERT и знакомство с ней не обязательно для достижения цели тексты, поэтому можно смело перейти к следующему блоку.
Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.
Что если вместо оценки времени, которое потребуется для выполнение задачи мы будем оценивать усилия, необходимые на решение этой задачи? Для этого мы примем шкалу оценки и расставим на ней задачи, требующие оценки.
При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:
Звучит непросто, но давайте вспомним, что у нас нет необходимости выставлять каждой задаче четкую оценку, нам просто нужно найти ее место на шкале оценок между другими оцениваемыми задачами.
Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:
Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.
Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах, таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!
Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.
Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?
Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?
Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.
Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.
В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;
Суть метода заключается в следующем: всем участникам команды раздаются карты с числами из шкалы оценки. Затем выбирается задача и обсуждаются требования к ней. После обсуждения модератор просит всех членов команды выбрать карту и положить ее «рубашкой» вверх. Затем модератор дает сигнал показать карты.
Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».
Стоит отметить, что согласие не должно быть абсолютным. Вы можете условиться, что набор соседних оценок так же считается согласием.
Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.
Этот блок можно пропустить и перейти сразу к следующей странице.
Сколько часов в Story Point'e и как мне построить диаграмму Ганта?
Итак, мы оценили наш бэклог задач, но на Story Point'ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.
Тоже самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.
Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта. К тому же не забывайте про закон больших чисел, погрешности оценок взаимно компенсируются, это касается как задач, так и итераций. Стоит отметить, что это немного оптимистично, т.к. погрешности обычно связаны с недооценкой, а не переоценкой. Но ничто не идеально.
Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.
Какие нюансы нужно знать?
Каких ошибок можно избежать?
В заключении хочется собрать несколько советов для тех, кто в первый раз решил попробовать описанные методики в своей работе.
С чего начать
Это ваш первый покер планирования и команда не понимает относительно чего оценивать новые задачи. Соберите несколько уже реализованных задач, в идеале хорошо всем знакомых или типовых и оцените их сложность относительно друг друга. Используйте эти задачи для оценки новых.
У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.
Не усредняйте оценки
Иногда, когда два члена команды оценили задачу по-разному, так и подмывает назначить задаче усредненный балл и пойти дальше. Не поддавайтесь этому искушению, дискуссия это важный элемент оценки, в ходе нее команда может вскрыть ранее неизвестные особенности в реализации задачи.
Но, как и говорилось выше, вы всегда можете договориться о том, что близкие друг к другу оценки не будут являться поводом для дальнейшего обсуждения.
Не меняйте оценки
Даже если в ходе реализации вы поняли, что ошиблись при планировании, оставьте оценку неизменной. Вы будете ошибаться и в будущем, причем в обе стороны. Дайте этим ошибкам компенсировать друг друга, не вмешивайтесь в процесс.
Оценка багов
Я сталкивался с разными подходами к оценке багов. Некоторые команды оценивают все баги, кроме тех, что возникли в ходе реализации новых задач в итерации. Некоторые не оценивают баги, обосновывая это тем, что скорость команды должна показывать новую ценность, которая добавляется в продукт, и исправление багов не должно влиять на рост этого показателя.
Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.
Нулевые оценки
Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.
Вы можете ввести оценку в 1/2 балла для таких задач и ретроспективно отслеживать не превышает ли доля таких задач разумные пределы. Но главный совет все тот же, оставайтесь последовательными в своих решениях.
Переоценка незаконченных задач между итерациями
Не всегда удается закончить задачу в одну итерацию, даже если это планировалось изначально. Тем не менее не стоит изменять ее оценку при планировании следующей итерации исходя из количества оставшейся работы. Учитывайте это при планировании, но оставьте оценку неизменной для истории.
Ретроспектива оценок
Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.
В ходе ваших ретроспектив пройдитесь по оценкам, которые были сделаны при планировании итерации и обсудите не случилось ли больших отклонений между ожиданиями и реальностью.
Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.
Записывайте все
Если ваша система управления задачами не поддерживает оценки и не считает скорость команды автоматически, значит вам придется делать это в ручную. Как Вы, наверняка, уже догадались исторические данные важный инструмент совершенствования ваших оценок.
Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.
Проблема
Расчет времени, необходимого на выполнение задачи одновременно и очень простая и очень рискованная задача, с которой сталкиваются команды разработки.
Неверная оценка становится одной из первых причин срыва графиков или даже провала проекта.
Проблема в том, что бизнес рассматривает оценки как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».
Майк (Менеджер): Какова вероятность того, что ты справишься за три дня?Я думаю, что диалог выше звучит довольно знакомо для любого разработчика или менеджера проекта.
Питер (Разработчик): Пожалуй, справлюсь.
Майк: Можешь назвать число?
Питер: Пятьдесят или шестьдесят процентов.
Майк: Значит, есть довольно высокая вероятность, что тебе понадобится четыре дня?
Питер: Да. может понадобиться даже пять или шесть, хотя я в этом сомневаюсь.
Майк: До какой степени сомневаешься?
Питер: О, я не знаю… Я на девяносто пять процентов уверен, что работа будет сделана менее чем за шесть дней.
Майк: То есть может быть и семь?
Питер: Ну, если все пойдет наперекосяк… Черт, если ВСЕ пойдет наперекосяк, может быть десять и даже одиннадцать дней. Но ведь вероятность такого совпадения очень мала, верно?
К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:
Корреляция оценки и оценивающего
Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.
Идеальная оценка в неидеальном мире
Срочные встречи, рабочие письма, мессенджеры и упавший таск-менеджер еще больше запутывают и без того сложный процесс разработки, что делает идеальные часы, которые мы воображаем во время выставления оценок слабо полезными для менеджера проекта, пытающего собрать стремительно устаревающую диаграмму Ганта.
Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.
Альтернативные решения
Естественно, подход с использованием SP не первая попытка решить озвученные проблемы, хотя и, вероятно, самый популярный.
В этом блоке я расскажу еще об одной программе, включающей в себя схему оценки задач. Программы называется PERT и знакомство с ней не обязательно для достижения цели тексты, поэтому можно смело перейти к следующему блоку.
Program Evaluation and Review Technique
PERT или Program Evaluation and Review Technique была разработана в 50-е годы XX века в ВМС США.
Для оценки задачи по схеме представляются три числа:
O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.
N: номинальная и наиболее вероятная оценка.
P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.
По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:
А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:
Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:
Как видим данный метод заставляет оценивающего задумываться не только о позитивных, но и негативных сценариях и даже использует элемент статистики. Но, к сожалению, не отвечает на все поставленные вопросы и к тому же весьма усложняет сам процесс оценки.
Для оценки задачи по схеме представляются три числа:
O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.
N: номинальная и наиболее вероятная оценка.
P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.
По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:
А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:
Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:
Как видим данный метод заставляет оценивающего задумываться не только о позитивных, но и негативных сценариях и даже использует элемент статистики. Но, к сожалению, не отвечает на все поставленные вопросы и к тому же весьма усложняет сам процесс оценки.
Story Points
Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.
Что если вместо оценки времени, которое потребуется для выполнение задачи мы будем оценивать усилия, необходимые на решение этой задачи? Для этого мы примем шкалу оценки и расставим на ней задачи, требующие оценки.
При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:
- Объем требуемой работы;
- Техническую сложность задачи;
- Возможные риски и неопределенность в требованиях;
Звучит непросто, но давайте вспомним, что у нас нет необходимости выставлять каждой задаче четкую оценку, нам просто нужно найти ее место на шкале оценок между другими оцениваемыми задачами.
Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:
Относительность оценки
Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.
Замена часов на абстрактные баллы
Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах, таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!
Числа Фибоначчи, майки и собаки
Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.
 |
 |
Оценка в команде
Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?
Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?
Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.
Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.
Покер планирования
В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;
Суть метода заключается в следующем: всем участникам команды раздаются карты с числами из шкалы оценки. Затем выбирается задача и обсуждаются требования к ней. После обсуждения модератор просит всех членов команды выбрать карту и положить ее «рубашкой» вверх. Затем модератор дает сигнал показать карты.
Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».
Стоит отметить, что согласие не должно быть абсолютным. Вы можете условиться, что набор соседних оценок так же считается согласием.
Альтернативы
Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.
Этот блок можно пропустить и перейти сразу к следующей странице.
Афинная оценка
Об этом методе я узнал все из той же книги Роберта Мартина «Идеальный программист. Суть метода заключается в том, что все задачи записываются на картах без каких либо оценок. Экспертная группа стоит возле окна или стены, на которой карты распределены случайным образом. Участники не говорят между собой — они просто сортируют карты. Карты задач, требующих больше усилий, перемещаются вниз, требующих меньше усилий смещаются наверх.
Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.
На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.
Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.
Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.
На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.
Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.
Планирование проекта
Сколько часов в Story Point'e и как мне построить диаграмму Ганта?
Итак, мы оценили наш бэклог задач, но на Story Point'ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.
Тоже самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.
 |
 |
Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта. К тому же не забывайте про закон больших чисел, погрешности оценок взаимно компенсируются, это касается как задач, так и итераций. Стоит отметить, что это немного оптимистично, т.к. погрешности обычно связаны с недооценкой, а не переоценкой. Но ничто не идеально.
Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.
Практика
Какие нюансы нужно знать?
Каких ошибок можно избежать?
В заключении хочется собрать несколько советов для тех, кто в первый раз решил попробовать описанные методики в своей работе.
С чего начать
Это ваш первый покер планирования и команда не понимает относительно чего оценивать новые задачи. Соберите несколько уже реализованных задач, в идеале хорошо всем знакомых или типовых и оцените их сложность относительно друг друга. Используйте эти задачи для оценки новых.
У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.
Не усредняйте оценки
Иногда, когда два члена команды оценили задачу по-разному, так и подмывает назначить задаче усредненный балл и пойти дальше. Не поддавайтесь этому искушению, дискуссия это важный элемент оценки, в ходе нее команда может вскрыть ранее неизвестные особенности в реализации задачи.
Но, как и говорилось выше, вы всегда можете договориться о том, что близкие друг к другу оценки не будут являться поводом для дальнейшего обсуждения.
Не меняйте оценки
Даже если в ходе реализации вы поняли, что ошиблись при планировании, оставьте оценку неизменной. Вы будете ошибаться и в будущем, причем в обе стороны. Дайте этим ошибкам компенсировать друг друга, не вмешивайтесь в процесс.
Оценка багов
Я сталкивался с разными подходами к оценке багов. Некоторые команды оценивают все баги, кроме тех, что возникли в ходе реализации новых задач в итерации. Некоторые не оценивают баги, обосновывая это тем, что скорость команды должна показывать новую ценность, которая добавляется в продукт, и исправление багов не должно влиять на рост этого показателя.
Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.
Нулевые оценки
Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.
Вы можете ввести оценку в 1/2 балла для таких задач и ретроспективно отслеживать не превышает ли доля таких задач разумные пределы. Но главный совет все тот же, оставайтесь последовательными в своих решениях.
Переоценка незаконченных задач между итерациями
Не всегда удается закончить задачу в одну итерацию, даже если это планировалось изначально. Тем не менее не стоит изменять ее оценку при планировании следующей итерации исходя из количества оставшейся работы. Учитывайте это при планировании, но оставьте оценку неизменной для истории.
Ретроспектива оценок
Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.
В ходе ваших ретроспектив пройдитесь по оценкам, которые были сделаны при планировании итерации и обсудите не случилось ли больших отклонений между ожиданиями и реальностью.
Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.
Записывайте все
Если ваша система управления задачами не поддерживает оценки и не считает скорость команды автоматически, значит вам придется делать это в ручную. Как Вы, наверняка, уже догадались исторические данные важный инструмент совершенствования ваших оценок.
