Если не учитывать сам способ оценки, кои рассмотрены в PMBoK , с фокусироваться на самих единицах то есть несколько вариантов:
1. Оценка __длительности__ задачи в днях - никогда не точная, но её всегда хотят услышать. Отвечает на вопрос: "Сколько времени примерно займет выполнение работы по достижению цели указанной в задаче приданными ресурсами?".
Плюсы: всегда можно сравнить: сколько времени уже прошло и сколько планировали потратить. Если итог не понравился то можно или включить обвинение "Ну вот, обещал и не сделал" или устранить причины "Что мешает завершить прямо сейчас? "
Минусы: иллюзия что всё под контролем.
2. Оценка __трудозатрат__ в человеко-днях(часах). Отвечает на вопрос: "Сколько человеко-часов (человеко-дней) нужно потратить на достижение указанной в задаче цели?". Иными словами, этот показатель напрямую конвертируется в оценку стоимости работ. Длительность у задачи может быть 5 дней, а вот трудозатраты могут быть 20 человеко-дней. То есть на задаче может быть задействовано 4 человека. Как правило это оценка присуща для пакетов работ: "эту пользовательскую историю наша команда из 5 человек реализует за неделю" , внутри "история" может дробиться на задачи реализации.
Плюсы: мы можем конвертировать оценку в ожидаемые прямые затраты и отслеживать инвестиции.
Минусы: оценка все-равно не точная, но есть иллюзия контроля. И если не предпринимать мер по реальному контролю (типа метода освоенного объема) это остается иллюзией.
3. Оценка в __размерах__ работы. Отвечает на вопрос: "Насколько одна работа больше другой?", то есть тут вообще дней никаких нету. Но зато можно мерять работу в метрах (Уложить 1000 метров кабеля), в квадратных метрах (Мне нужно уложить 5 кв.м плитки), в кубических метрах (Разгрузить 5 кубометров дров), или в просто в пунктах (Это сложная работа на 5 пунктов)
Минусы: (1). Это очень не линейный параметр. Разница между размером 4 и 5 работы, совсем не 1 размер работы, это может быть и 3 размера. Например привезти 5 кубометра дров - 1 камаз, а 6 кубометров -уже 2 камаза, то есть в 2 раза дороже. Для интеллектуальной работы тоже самое, там расхождение оценок размера в 2 раза может привести к 4 кратной разнице в трудозатратах и/или времени выполнения.
(2) Нельзя использовать для для рычага: " мы оценили задачу в 2 единицы, а уже прошло 4 дня" - и что? Единицы размера работы не пересчитываются в дни никак. Можно вывести коэффициент для прогноза, но он будет не точный.
Плюсы: очень быстрая оценка (буквально "больше или меньше"), очень неточная оценка поэтому иллюзии контроля ситуации нет.
Ошибка использовать какой либо коэффициент к размеру работы для пересчета в дни.
Важно: Для интеллектуальной работы, оценка в относительных размерах должна строиться на основе самой маленькой задачи у которой размер = 1. То есть это именно "размер" задачи, или уровень сложности. (ага, на 1 уровень у нас 1 монстр на минуту игры , а на уровне 2 - 10 монстров)
Какой же подход выбрать?
Выбирайте любой, что больше нравится. Все метрики можно использовать для расчета скорости реализации объёма работ и прогноза реализации. (см Диагональный буфер)
Как выбрать: (алгоритм)
1. Хотите рычаг для ускорения работы? - оценка длительности в днях
2. Хотите прогноз затрат и если в задачах вовлечено больше одного исполнителя? - оценка в трудозатратах
3. Хотите просто видеть прогноз срока завершения? - оценка в размерах.
4. Хотите по быстрому оценить работу? - оценка в размерах.