Привет! На связи Владимир и утренний мини-подкаст ProductDo (аудио 👇).
Сегодня расскажу про сторипоинты, т.к. были вопросы под одним из предыдущих постов.
Зачем нужны сторипоинты?
Чтобы оценивать размеры задач. Они позволяют отличать тикеты "на пару часов" от тикетов на "пару спринтов". Простая математика и эмпирические замеры позволяют понять, сколько в среднем сторипоинтов ваша команда может сделать за спринт. А это уже позволяет отвечать на вопросы "А когда эта конкретная задача/эпик/проект будут заделиверены?"
Не делайте сторипоинты в часах, не привязывайте их ко времени разработки. То, что для джуна Васи – стори 10 часов, то для сениор программистки Кати – стори 10 минут.
Сторипоинты - попытка создать одинаковую "валюту". Есть разные подходы к определению сторипоинтов:
- от 1 до 10
- от 1 до 5
- XS, S, M, L, XL...
- числа Фибоначчи (1, 2, 3, 5, 8, 13...)
Я сам использую Фибоначчи – это позволет не спорить: "Это 7 или 7.5 сторипоинтов?"
С каждой командой определяется "стоимость". Например:
1 – простое изменение в коде без зависимостей и тестов
2 – простое / средне-простое изменение в коде без зависимостей
...
8 – сложное изменение с зависимостями
13 – двухнедельная работа...
Опа! Как мы не нехотели, сторипоинты всё равно через спринт велосити связаны со временем в усредненном виде. Это неизбежно, но не мешает не привязывать сторипоинты ко времени разработки конкретных задач.
Если у вас много сторипоинтов 8 и 13 - надо лучше груммить, делить таски на саб-таски с меньшим числом сторипоинтов.
Зачем всё это?
- Разработчики лучше понимают сколько времени уйдет на задачу.
- ПМ понимает сколько задач брать в спринт, понимает максимум конкретной команды.
- Можно гораздо точнее планировать и определять сроки запусков проектов.
Надеюсь, было полезно!
Пишите в комментах: используете ли вы сторипоинты, как их считаете, находите ли такой подход полезным?
Сегодня расскажу про сторипоинты, т.к. были вопросы под одним из предыдущих постов.
Зачем нужны сторипоинты?
Чтобы оценивать размеры задач. Они позволяют отличать тикеты "на пару часов" от тикетов на "пару спринтов". Простая математика и эмпирические замеры позволяют понять, сколько в среднем сторипоинтов ваша команда может сделать за спринт. А это уже позволяет отвечать на вопросы "А когда эта конкретная задача/эпик/проект будут заделиверены?"
Не делайте сторипоинты в часах, не привязывайте их ко времени разработки. То, что для джуна Васи – стори 10 часов, то для сениор программистки Кати – стори 10 минут.
Сторипоинты - попытка создать одинаковую "валюту". Есть разные подходы к определению сторипоинтов:
- от 1 до 10
- от 1 до 5
- XS, S, M, L, XL...
- числа Фибоначчи (1, 2, 3, 5, 8, 13...)
Я сам использую Фибоначчи – это позволет не спорить: "Это 7 или 7.5 сторипоинтов?"
С каждой командой определяется "стоимость". Например:
1 – простое изменение в коде без зависимостей и тестов
2 – простое / средне-простое изменение в коде без зависимостей
...
8 – сложное изменение с зависимостями
13 – двухнедельная работа...
Опа! Как мы не нехотели, сторипоинты всё равно через спринт велосити связаны со временем в усредненном виде. Это неизбежно, но не мешает не привязывать сторипоинты ко времени разработки конкретных задач.
Если у вас много сторипоинтов 8 и 13 - надо лучше груммить, делить таски на саб-таски с меньшим числом сторипоинтов.
Зачем всё это?
- Разработчики лучше понимают сколько времени уйдет на задачу.
- ПМ понимает сколько задач брать в спринт, понимает максимум конкретной команды.
- Можно гораздо точнее планировать и определять сроки запусков проектов.
Надеюсь, было полезно!
Пишите в комментах: используете ли вы сторипоинты, как их считаете, находите ли такой подход полезным?