Что такое story points в jira
Story Points — оценка задач и планирование разработки продуктов
Что такое Story Points? Как оценить задачи для разработчиков? Как спланировать дорожную карту?
Story Points или сторипоинты — это бальная система оценки задач и планирования проектов в разработке.
У меня ушло около 10 лет практики руководства командами разработки на то чтобы понять что это и почему это важно.
Вводные
Первое что стоит понять, что сторипониты это не совсем оценка времени. Это скорее бальная оценка задач.
Она частично связана с трудоемкостью, но лишь отчасти.
Если проводить аналогию, то можно взять Шкалу Бофорта из метеорологии.
Там скорость ветра привязывается к баллам. Тоже самое следует делать в разработке — привязать оценку трудоемкости в идеальных днях к баллам или сторипоинтам.
Почему так надо делать? Чтобы что? Это сложные вопросы, на которые попробуем ответить ближе к концу статьи.
Почему проектные подходы ломаются в разработке?
Многие начинающие руководители в разработке пытаются оценивать сроки по задачам или разработчикам. Как это принято делать в старых проектных подходах.
Они просят разработчика оценить сроки по задаче. Это последствия слабого опыта в управлении разработкой.
Важно понять что оценка сроков по задачам и разработчикам — не работает, если вы разрабатываете что то более менее сложное или менее предсказуемое чем сложное.
Что значит менее предсказуемое чем сложное? Ответ на этот вопрос можно узнать если ознакомиться с моделью Киневина.
Сложные системы — это не так уж сложно 🙂 Большинство разработок с кодом — заметно отличаются в методах планирования. Системы типа Хаос или Запутанные — управляются иначе чем Сложные системы. Важно это понять. Модель Киневина — хорошо помогает понять в чем отличие.
Ключевые отличия планирования сроков по задачам и по итерациям
В старых проектных подходах было принято оценивать сроки так:
В подходах на основе Agile, Scrum, Kanban, оценка происходит иначе. Сильно иначе.
Там оценка идет по другим аспектам:
Важно понять что оценка сроков в Agile требует иных навыков и понятий:
Как быть? Что нужно уяснить?
Что такое баллы или сторипоинты?
Вот мы и подбираемся к ключевой идее. Почему нужно использовать баллы вместо трудоемкости или сроков по задачам?
Во первых стоит понять что такое баллы (сторипоинты) и как они связаны с идеальными днями?
В таблице ниже можно понять соотношение идеальных дней и баллов:
Эта таблица похожа на Шкалу Бофорта, только вместо скорости ветра тут идеальные дни, а вместо баллов Бофорта тут баллы истории или сторипоинты.
Важно оценить каждую историю по баллам. Сколько баллов у истории?
Если история слишком крупная — ее надо разбить на более мелкие истории.
Истории могут объединяться в темы (themes) или эпопеи (эпики, epics). Более подробно можно прочитать в книге “Agile: оценка и планирование проектов”.
Как планировать итерации?
Итерации Agile в Scrum принято называть спринтами (sprint).
Итерации обычно бывают на 1 месяц или на 2 недели.
В некоторых случаях применяются квартальные или годовые итерации.
Бывают применяют недельные итерации. Но обычно это про карго-культ, а не про разработку и agile. Могут быть исключения. Если речь идет про очень простые продукты и задачи.
Мы берем список историй, и пытаемся понять сколько из них влезут в следующий спринт или месяц?
Например сколько мы можем сделать историй в августе?
Ответ на этот вопрос не так прост и с ходу не дается.
Что такое скорость и вместимость?
Что такое скорость? Еще ее называют велосити (velocity).
Это то сколько баллов удалось закрыть в прошлых итерациях. Обычно берется 2–4 прошедшие итерации. Если мы за итерацию берем месяц, то речь идет про прошедшие 2–4 месяца. Так мы поймем скорость.
Средняя скорость команды в баллах и есть вместимость 1 итерации.
Предположим что у вас в команде 3 разработчика. А итерация равна 1 месяцу. Идеальную скорость мы можем посчитать через идеальные дни — 20 идеальных дней в месяце, на 3 разработчика — это 60 идеальных дней или 60 баллов — вместимость итерации.
Беда в том что идеальная скорость и вместимость — не достижимы.
Через 2–4 итерации вы узнаете что ваша скорость или вместимость равна в лучшем случае 30–40 баллов. Если все плохо то может быть 20–30 баллов. Если совсем плохо то 10–20 баллов.
Почему идеальная скорость отличается от реальной?
Тут играет куча факторов, которые снижают эффективность команды:
Почему сторипониты это не про идеальные дни?
Причина очень простая. Если слабому менеджеру сказать что сторипоинты это про идеальные дни, то он попытается оценить всех кто в команде. Он будет оценивать тестировщиков, аналитиков и всех кто есть в команде. А это тупиковый путь.
Суть в том что ключевое отличие в принципе оценки по бутылочному горлышку.
Что есть бутылочное горлышко чаще всего? Это программисты. Потому оценка сторипоинтов идет по программистам. Идеальные дни с точки зрения программистов. Сколько там займется времени по задачам у тестировщиков или аналитиков в большинстве случаев не имеет значения.
Хотя я видел ситуации когда мы упирались в тестировщиках. В этом случае было бы лучше оценивать задачи с точки зрения идеальных дней у тестировщиков. Но объяснить это команде было очень сложно. Потому продолжали оценивать как получится. Но это исключительные и очень редкие ситуации.
Потому в большинстве случаев мы просто оцениваем идеальные дни с точки зрения программистов, потому что именно они обычно бывают узким горлышком.
Это еще добавляет сюрпризов с точки зрения подсчета скорости и вместимости.
Но если все сделать правильно, то в конечном итоге скорость и вместимость становятся достаточно понятными, предсказуемыми и позволяют оценивать реальные сроки.
Что такое дорожная карта и Kanban доска?
Важно отличать Канбан доску от Дорожной карты.
Важно еще уметь применять оба инструмента. Это не так просто.
Подробнее про эти понятия можно почитать тут:
А можно без сторипоинтов?
А оно нам надо? Хороший вопрос 🙂 Этот подход далеко не единственный и далеко не всем командам он подходит.
Этот подход хорошо работает в следующих ситуациях:
Когда это все нафиг не надо?
Например если вы работаете над b2c продуктом, у вас 1 000 000 пользователей и все хорошо. Вы просто выкатываете то что выкатываете когда получится. Обычно там лучше применять Agile, Kanban & OKR.
Сторипоинты, короткие итерации, капасити и велосити в этом случае будут излишним усложнением. Конечно могут быть исключения.
Про карго-культ
Многие команды заявляют что используют Scrum или Agile. Но на деле там Срам, Ад-айл и Карго-культ )
Как отличить карго-культ? Какие ошибки часто встречаются?
Сроки спрашиваются по задачам и разработчикам
Руководство говорит о том что мы про Agile & Scrum, но сроки просит называть по разработчика и по задачам 🙂 Также пытаются оценивать метрики эффективности по каждому разработчику — это не про Agile и не про Scrum.
Путают итерацию (спринт) и этап проекта
Вот мы запланировали в итерацию 7 историй, но не успели сделать 2 истории. Давайте продлим срок итерации )) Это тоже карго культ. Итерация — это не этап проекта. У итерации срок не может сдвигаться. Итерация кончилась — посчитали скорость. Если надо — перепланировали следующую итерацию — пляшем дальше.
Отсутствует подсчет скорости
Итерации заканчиваются, а какая скорость получилась — никто не считает. В этом случае итерации бесполезны. Но кого это волнует в карго-культе? )
Ретроспектива не делается или делается в стиле “что было прикольно? а что плохо?”
Типа вот мы кофемашину в офисе поставили — это прикольно. А работы было много — это фигово.
Ретроспектива должна делаться на основе плана историй и итераций. Вот запланировали на итерацию 10 историй, 8 успели, а 2 нет. 8 успели — это круто. А 2 не успели — почему?
Может быть планирование было сделано плохо, или реальную скорость не учли? Или просто эффективный менеджер занимается очковтирательством, пытается показать свою амбициозность перед старшими и загоняет команду в не реальные планы?
В общем есть много различных признаков карго-культа, когда говорят правильные слова, но по факту занимаются имитацией бурной деятельности. Не дай бог попасть в такую команду )
Итого
Давайте подобьем итоги:
Если чего то не поняли — пишите вопросы в комментах. Разберемся)
Понимание относительных оценок в Agile. Даёшь Story Points!
В своей работе со Scrum-командами, я столкнулся с непониманием членов команды, как правильно оценивать задачи или user story. Из этого и родилась потребность в написании статьи, с помощью которой (я надеюсь), я смогу уложить знания в своей голове, лучше объяснять методику командам, а также помочь всем, кто будет ее читать эффективно и быстро оценивать задачи в своих проектах.
В этой части я не буду отвечать на вопрос «зачем вообще нужны оценки?», надеюсь, что на данный вопрос вы сами знаете ответ или на него уже ответил ваш руководитель, спонсор или инвестор. Я начну рассказ с сравнения относительных и абсолютных оценок.
В старой последовательной «водопадной» методологии разработки программного обеспечения и продуктов, где нельзя начать следующий этап без завершения предыдущего, существовало классическое деление на отделы: отдел разработки, отдел дизайна, отдел аналитики и т.д. Таким образом, техническое задание, пройдя через отдел архитектуры, аналитики, разработки (последовательность и наполнение зависели от организационной структуры и размера конкретной организации), обрастало деталями, дополнительными требованиями, архитектурными изысканиями и тому подобными артефактами. Финально получалась оценка в человеко-днях (или man day — md, терминология использовалась у одного из моих бывших работодателей). Считалось, а где-то до сих пор считается, что данный подход позволяет получить детальный бюджет проекта (смету) с точными абсолютными трудозатратами, на основе чего верстался портфельный бюджет и закладывался весь бюджет организации.
Однако, у данного подхода есть ряд существенных недостатков:
Как итог: у нас нет времени для детальной и точной оценки, но и ценности в этой оценке, по большому счету нет. Наша основная цель: понять сколько задач команда может взять в итерацию (спринт), для этого нам точно подойдет относительная оценка и дальше я расскажу, что же она из себя представляет применительно к гибким методологиям.
На тренингах команд я использую пример, который, на мой взгляд, хорошо иллюстрирует относительную оценку и ее применимость в современных реалиях.
Итак, для начала давайте представим себя астрофизиками, которым необходимо решить задачу по определению диаметров планет Солнечной системы:
Сможете сходу назвать диаметр такой планеты, как Уран?
Без помощи Google, ответить на этот вопрос тем из нас, у кого не было пятерки по астрономии будет сложно, задача потребует значительного времени и даже после этого совершенно точно будут разные варианты оценки.
Кто-то решит, что 22 750
Мы будем спорить и потратим очень много времени, чтобы договориться и выбирать лучший ответ, причём кто-то из команды все равно останется не довольным результатом.
Когда мы сравниваем объекты между собой, оценка становится проще и в команде возникает меньше споров и противоречий.
В этом и есть разница и проблема между абсолютной и относительной оценкой.
В приведенных мною выше примерах использовалась оценка в днях, также есть практика оценки задач в часах, что является примером абсолютной оценки. В Scrum пользовательские истории оцениваются относительно и при оценке используются Story Points.
Абсолютная оценка = Часы
Относительная оценка = Story Points
Story Pointы не имеют физических единиц оценки. Но я сталкивался с ситуациями, когда команды пытаются приравнять их ко времени, например, что 1 SP = 1 часу или дню, тем самым мы просто возвращаемся к абсолютной оценке. Важно помнить о том что мы должны оставаться в относительной шкале и задача Scrum мастера донести эту концепцию до команды и Product Ownera. Можно использовать пример с планетами, стаканом фасоли или другими сравнимыми вещами. Также, при продуктовом подходе, стоит помнить, что мы экспериментируем, мы ещё не знаем будет ли успешен наш продукт на рынке и сделаем ли мы удачный инкремент в этом спринте. Scrum Фреймворк предполагает процесс непрерывного улучшения на основе полученного опыта.
Эксперимент важен, он позволяет команде постоянно совершенствоваться и становиться эффективнее и относительная оценка помогает в этом, так как за основу оценки, мы берём задачи, которые команда уже делала. Таким образом оценка со временем становится все лучше, а результат все более прогнозируемым.
Для себя я выделяю 3 основных принципа, при которых оценка будет эффективна для команды и проекта в целом.
Методов относительной оценки множество, описание их механик тянет на отдельную статью. Я склоняюсь к самым простым, чтобы команде можно было быстро и легко начать их использовать. Далее расскажу об одном из них:
Мы, также используем размер XXL когда появляется задача с очень высоким уровнем неопределенности и такую «майку» точно необходимо декомпозировать на более мелкие.
Product Owner рассказывает команде контекст задачи, как он ее видит, после чего все члены команды «вслепую» (исключаем влияние на оценки) дают свои оценки ведущему (Scrum мастеру). Далее, слово предоставляется участнику, давшему самую высокую и самую маленькую оценку задаче. Выслушав их члены команды договариваются готовы ли они повысить или понизить свою оценку на основе услышанного, в итоге команда должна придти к единому мнению.
Не меняйте метод оценки часто, важно наблюдать за эволюцией команды, первые 1-2 спринта оценки могут не соответствовать полученным результатам, помните про эксперимент. Проводите ретро и обсуждайте с командой почему результат показал отклонение от первоначальных ожиданий, с помощью чего его можно улучшить, что необходимо предусмотреть.
Большое спасибо, что вы дочитали до конца! Я очень надеюсь, что мне удалось донести смысл оценочной системы и привести примеры ее работы. Буду рад и благодарен за любые комментарии или критику в свой адрес.
Стори поинты: как это работает
Сколько усилий нужно потратить на задачу? В условиях неопределенности и сложности ответ лучше дать не в часах. Куда удобнее относительные единицы, из которых самые известные — стори поинты. Мы перевели статью Майка Кона о том, какие факторы нужно учитывать, оценивая работу в стори поинтах, и как согласовывать эти факторы между собой. Бонус — список типичных ошибок в применении стори поинтов.
Стори поинтами измеряют усилия, которые нужны, чтобы выполнить элемент бэклога продукта или любой другой отрезок работы.
Пользуясь стори поинтами, мы присваиваем каждому элементу (работы) некое количественное значение. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. История, которой присвоено значение 2, должна быть вдвое больше истории со значением 1 и соответствовать двум третям истории со значением 3.
Вместо единицы, двойки и тройки команда могла бы использовать цифры 100, 200 и 300. Или 1 миллион, 2 миллиона, 3 миллиона. Важно соотношение, а не цифры как таковые.
Что включают в стори поинт?
Поскольку стори поинты выражают усилия для выполнения истории, команда должна оценить все, что повлияет на эти усилия. Это может быть:
Измеряя работу стори поинтами, обязательно оцените каждый из этих факторов.
Объем работы
Чем больше работы необходимо выполнить, тем, очевидно, больше должен быть условный показатель усилий. Возьмем разработку двух веб-страниц. На одной должно быть только одно поле и просьба ввести имя. На второй странице полей для текста должно быть 100.
Вторая страница не сложнее первой. Она не предусматривает взаимодействия между полями, и заполнять их не нужно ничем, кроме текста. Ее разработка не связана ни с какими рисками. Единственное отличие двух страниц — на второй сделать нужно больше.
Второй странице стоит присвоить больше стори поинтов. Может, не в 100 раз больше, хотя на ней и во 100 раз больше полей. В конце концов, существует эффект масштаба, так что в реальности мы можем затратить на вторую страницу всего в 2, 3 или в 10 раз больше усилий, чем на первую.
Риски и неопределенность
Нужно включать в оценку и риски или неопределенные моменты в работе. Например, команде бывает нужно оценить элемент бэклога, о котором стейкхолдер не может сказать ничего конкретного. Похожая ситуация: нужно давать наценку по сложности, когда внедрение фичи требует переписать старый ненадежный код без автотестов.
Неопределенность как таковая отражена уже в самой последовательности чисел для стори поинтов, которая напоминает ряд Фибоначчи: 1, 2, 3, 5, 8, 13, 20, 40, 100. Какое бы число вы не выбрали, усредненная неопределенность уже заложена в него — если, конечно, вы используете именно такое соотношение чисел.
Сложность
Также нужно учитывать сложность. Вернемся к нашей странице со 100 полями, между которыми нет взаимодействий.
А теперь представим себе другую страницу со 100 полями. Часть из них — поля с датами и, соответственно, календарными виджетами. В другой части можно вводить только ограниченное количество символов: например, номера телефонов. Есть и поля, в которых проверяется контрольная сумма (например, с номерами банковских карт). Кроме того, есть взаимодействия между полями. Для карты Visa страница должна выдавать поле с трехзначным CVV-кодом, а для карты American Express — с четырехзначным.
Хотя на экране по-прежнему 100 полей, разработка будет сложнее, а значит, займет больше времени. Растет вероятность, что разработчик ошибется и ему придется откатить какие-то из изменений и переделать работу.
Учитывайте все эти факторы
Может показаться, что невозможно отобразить три фактора в одном числе, но это не так. Объединяющим фактором должны стать необходимые усилия. Сначала оценивающие учитывают, какими могут быть общие трудозатраты по каждому элементу бэклога.
Потом нужно оценить, как на трудозатраты повлияет риск. Для этого стоит озвучить риски и оценить их влияение. Например, больше стори поинтов стоит присвоить элементу с более высокой степенью риска, особенно если он потребует выполнить больший объем работы, а не элементу, с которым проблемы менее вероятны.
И наконец, необходимо оценить сложность. Она может потребовать больше осмысления, проб и ошибок, коммуникации с заказчиком, проверки и времени на исправление ошибок.
Обратите внимание на Definition of Done
Оценка в стори поинтах должна учитывать все, что потребуется для доведения элемента бэклога до состояния готовности. Если в определениях готового у команды указаны автотесты для проверки истории (а это хорошая мысль), то в оценке должны быть учтены и усилия на написание тестов.
Типичные ошибки
Узнайте больше на наших ближайших тренингах.
Переведено и адаптировано командой BrainRain по материалам:
Scrum Story Points. Изобретение дьявола
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты/Story Points. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды.
Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться.
Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ «в лоб».
Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному.
Даже если стандартизировать их способ мышления при оценке и способ выполнения работы, то ничего не получится. СП применяют для нематериального производство, которое происходит в разумах людей.
И как в поговорке «к сожалению к рукам сотрудника прилагается и остальной человек».
Не нужно оценивать эффективность по количеству СП и тем более сравнивать 2 команды. ты сравниваешь одни уникальные усилия с другими уникальными усилиями. Оценивайте результат.
При оценке СП участвуют все члены команды, каждый высказывают свою оценку сразу целиком по всей задаче. Даже аналитик, хотя он не разработчик и не знает как это точно «закодить».
Работает такая оценка на опыте и СП предполагает именно усилия команды, а не отдельных ее членов.
Рассматривать команду надо не как группу индивидуумов, временно собранных вместе волею судеб, а как нечто неделимое, чёрный ящик, куда можно забросить задание и получить результат.
Что забавно, СП почти никогда не работает в группах людей, которые не понимают смысла работы друг друга и не работают на единой целью.
Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.
Ну и плюс немного дополнительных умозаключений:
Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.
Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет).
Представь что виртуальная «емкость усилий» есть у каждой задачи. Представь в виде ведра. Сложив 4 таких задачи ты просто получишь 4 ведра, а не одно большое ведро.
СП необходимы для оценки усилий и дальнейшего выбора в контейнер времени наиболее важных задач (часто такой контейнер называют спринтом).
А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.
Из предыдущего мифа следует простой вывод. СП нужны только на коротком промежутке времени и применяются именно для решения «сколько работы уложится в итерацию». После запуска итерации смысл СП исчезает.
Но Майкл Кон так не думает)
Так как оценка СП выражает объем, риски и сложность, то оценивать весь беклог в них и потом использовать на планировании спринта оценку в СП, которую поставили полгода назад бессмысленно. Даже если объем работы не поменялся, то изменилась сложность (люди не стоят на месте, они развиваются или деградируют + меняется состав команды) + могла изменится неопределенность (какие-то риски ушли, какие-то появились).
Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют velocity. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем «50/50, или сделаем или нет».
Итог: сферический спринт в вакууме стоил 16 сторипоинтов в феврале и 19 в марте.
Так вам эта информация исключительно чтобы понимать сколько усилий вы приложили тогда то и тогда то. Аппроксимировать всего 2 точки не получится.
СП влияют на прогнозирование ваших усилий и выбор задач в спринт, вам мало?)