По сравнению с оценкой в человеко-днях, оценка в Story points - это относительная оценка задач. Такая оценка обеспечивает возможность учёта и управления ожиданиями Заказчика когда непонятно "что делать", но есть субъективное мнение "эта задача больше чем" или "эта задача меньше чем".

Можно применять когда нельзя ТОЧНО сказать "сколько займет времени, скажи хотя бы насколько одна задача будет сложнее или проще другой задачи". Это такой вариант "размера" или "физического объёма", так же как есть "тонны грунта" или "километры кабеля".

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

И всё!

Попытки привязать эти оценки к чему-то другому, равно как "ты ДОЛЖЕН оценивать вот так", "я/МЫ ЗАЛОЖИЛ такую скорость...", "Я от тебя ОЖИДАЮ такую оценку...." это это попытка подмены понятий. То есть, использование суррогата человеко-дней, вместо честного использования "человеко-дней оценки".

Например: приходит новый сотрудник и вы ему говорите: "У нас каждый делает 20 единиц историй (SP) в спринт". Это значит 1 SP = 0.5 дня (если 2 недельный спринт). То есть тут происходит прямая подмена понятий. У вас просто оценка задач в "полднях", при чём в суррогатных. Также и попытка взять обязательства "Ты мне сколько этих единицы историй сделаешь за спринт?" или "Я хочу чтобы ты наработал Х единиц историй за спринт" - это тоже подмена понятий. Так, как с днями можно сравнить ТОЛЬКО оценочные дни.

Когда авторы Единиц Истории придумывали относительные оценки закладывали совсем иную базу: когда нельзя ТОЧНО сказать "сколько займет времени, скажи хотя бы насколько одна задача будет сложнее или проще другой задачи". Это такой вариант "размера" или "физического объёма", так же как есть "тонны грунта" или "километры кабеля".

Также, стоит учитывать, что большая часть Agile-подходов будучи придуманными во внутреннем ИТ больших корпораций, НЕ ИМЕЮТ никаких механизмов взятия на себя обязательств по срокам выполнения работы. Поэтому есть механики "с учетом ТЕКУЩЕЙ скорости сделаем тогда....." и "вчерашняя погода" для управлением объёмом поставки итерации/спринта.

Принцип "вчерашняя погода"

Источник: Экстремальное программирование.

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

Инженеры всегда найдут чем заняться если останется время. А с другой стороны, у вас же портфель заказов приоритизирован, не так ли?

Покер планирования

Источник: Экстремальное программирование.(XP)

Правила игры "Покер Планирования":

Игру играет команда, при оценке длительности задач. Задачи описаны в виде карточек Историй (Пользовательских историй, сценариев применения Продукта). То есть, это не "технические задачи", а задачи имеющие ценность для конечного Пользователя (Целеуказателя).

Примечание: "Игра в планирование" (Planning game) появилась в XP при оценке длительности задач в "идеальных человеко-днях". Если у вас постоянно паралич анализа, и не можете оценить длительность, то можете использовать единицы СЛОЖНОСТИ - Story Points (Единицы истории). Алгоритм игры не меняется.

Шаги:

  1. Ведущий: "На торги выставляется задача _ про __, делайте ставки"
  2. Участники: скидывают карты с оценками рубашкой вверх. (для исключения влияния)
  3. Ведущий: вскрываемся
  4. Участники: переворачивают карты
  5. Ведущий: давайте сравним
  6. Участники: сравнивают оценки и если все оцени одинаковые , но есть "выскочки" кто дал большую или меньшую оценку.
  7. Ведущий: А почему такая оценка?
  8. Участник "выскочка": объясняет почему он так считает, остальные разъясняют свою позицию.
  9. Ведущий: Обсуждение завершено, делайте новые ставки по этой задаче!
  10. Участники: скидывают карты с оценками рубашкой вверх. (для исключения влияния)

Цикл повторяется, до тех пор пока команда не придёт к единому мнению относительно сложности задачи в Единицах Историй (Story points).

Другая статья по теме: Как оценивать задачи

Быстрая оценка "Больше-меньше"

Если же вы настойчиво не хотите применять оценку днях, потому что "работа ну настолько неизвестная, что её совсем никак нельзя оценить в идеальных днях", то можно применить оценку в относительных единицах размера Истории (Story points).

  1. Выберите среднюю по размеру (Сложности) задачу
  2. Установите этой задаче оценку - 3
  3. Возьмите следующую из корзины
  4. Если она больше ранее взятой - то оценка - 5, если меньше то оценка 2
  5. Повторите шаги для всех задач раскладывая по кучкам: 1-2-3-5-8 .

Важно: помнить что

  1. Сложность это не ДНИ, не ПОЛДНЯ, это размер большой или маленький.
  2. 1 единица + 1 единица это НЕ РАВНО 2 единицы. Это может быть и 3 и 5 единиц. Сложность возрастает экспоненциально.

Применимость: есть большая стопка (физическая) карточек историй и их нужно оценить.

Что реализует BIPULSE

BIPULSE использует вместо относительных оценок "идеальные человеко-дни", так как этот показатель можно сравнивать с фактическими днями. Но в модуль управления физическими объёмами позволяет оценивать задачи и в относительных единицах Историй (Story Points). С другой стороны, при применении "ковбойского метода оценки", не нужно искать ОДНУ оценку задачи, но при этом есть основа для обсуждения.