Но как и говорили выше, надо понять как оно работает сейчас, почему оно работает и как его улучшить))

У нас просто мобильный банк, а у них все сложно с обратной связью =)

Но это мое мнение и мой опыт.

Я с радостью приму конструктивную критику.

Лучше в стори поинты включать хорошие стори, а поинты вообще не включать!

Я поэкспериментировал - вынес оценку тестировщиками и они ее делают во времени. Потому что иногда сильно аффектило на размер скоупа

просто у нас в разных командах по-разному. Кто то при формировании спринтов в велосити команды учитывает только труд разработчиков и только разрботчики оценивают задачи, а кто-то оценивает задачи с учётом тестироващиков. Они могут сказать, ой тут очень сложное тестирование! и вот вопрос как же лучше….

я за то чтобы задачу оценивать многогранно, хотя бы разработчики + тестировщики

Я не так давно, был в Luxoft, на AgileTalks.

И познакомился там с дядькой, не помню его Фамилию.
Но у него своя компания по настройке процессов в компаниях.

Так вот мы с ним обсуждали, как применять SP в рамках аутсорса, так как все разрабы хотят, а заказчики чаще всего не понимают их.

Он мне подсказал вариант, которому я потом нашел подтверждение в американских статьях по Best Practice.

Суть в том, что в SP надо оцениватьвсей командой беклог и эпики. Но когда ты делаешь декомпозицию и береш задачи в спринт, ты их оцениваешь в часах. Так как работаем мы все равно в часах и платят нам в часах.

Если мы берем стандартный, 2 недельный спринт, в нем у разработчика 80 часов работы, сразу 1 час отсекаем на дейли и синхронизацию(а по-хорошему лучше 2, так как принято в Luxoft). У тебя остаеться 70, минус скрам активности в зависимости от команды 5-10 часов, 60-65 часов. Буфер на заболел\устал 1 день. и того 50-55 часов разработки.

Рисуешь табличку и применяешь методики Timeboxing. Выбираешь 2-3 стори что-бы они влезли в эти 55 часов. И просишь ребят, разбивать передачу в тестирование по окончанию каждой стори. Если на демо Стейкхолдеры все апрувят, заказчик все деплоит=)

Вот как-то так и построил процесс на галлере =)

Ничоси наворотили. То есть переводим в сторипойнты, чтобы потом перевести в часы обратно. Зачем сторипойнты-то здесь тогда, оценивают в идеальных часах, так пусть и оценивают.

На эпике вилка в часах уж очень большая получается :)

А там посчитали сколько примерно SP съели, оценили в SP беклог, и примерно поняли за сколько его осилим

Изначали оценок вообще небыло, оценивали только то что брали в спринт

Я в переводы не вдавался, но оценка эпиков это то для чего sp нужны. А таски нужно в часах оценивать.

Абсолютно!

есть подход что оценка нужна прежде всего для приоритезации внутри бэклога продукта, а когда уже дошло дело до бэклога спринта, то либо вообще не оценивать, или в часах, так как горизонт планирования уже от 1 до 4 недель, там можно и в часах более-менее попасть

Кому нужно, это во-первых. А во вторых, сумма задач в эпике в часах будет оценкой этого эпика в часах. Зачем ему вторая оценка?

Потому что sp могут помочь очень быстро оценить эпики или большое количество историй и принять решения уровня релизов. Чтобы пару дюжин эпиков оценить в часах нужно много работы и погрешность высокая

Рекомендую посмотреть видосы или почитать книжку Кона

Нужно прямо как-то звучит как requirement, на самом деле оценка в часах самих задач - это наоборот НЕ НУЖНО, а исключения составляет какие-то штуки из простого домена 🙂

Ок. Если нужно, то в часах

А лучше вообще не оценивать