Vitsliputsli

Прям пример конкретный расписать очень затратно, но как некий базис, с опиcанием ошибок упрощения, пожалуйста.
Product Owner (PO) заводит Epic для создания форума типа этого, с описанием нужного функционала (не обязательно ТЗ, достаточно функциональных требований).
Проводится грумминг беклога проекта, не суть важно каким составом и как вы будете это делать, главное что в результате в беклоге проекта должны быть созданы Stories - это разбитый на подзадачи Epic, каждая Story - это законченная бизнес-ценность, т.е. никаких разработческих задач, только то, что можно будет "потрогать" бизнесу.
Каждая Story должна быть оценена в Story Points (SP) (надеюсь, понятно, что SP - это не трудозатраты и не часы разработки). Декомпозиция на dev-задачи это уже развлекухи разработки, на доске Scrum они не нужны.
"Страница логина пользователя" 3SP
"Создание нового вопроса пользователем" 13SP
"Отображение ленты вопросов для пользователя" 8SP
"Создание ответов на вопросы" 8SP
"Создание тегов-тем для вопросов" 21SP
Следующий этап - планирование спринта. Зная velocity команды мы можем спланировать сколько задач поместится в планируемый спринт, разумеется задачи могут зависить друг от друга - это тоже надо учитывать. Например, при Velocity=30SP, мы можем взять в беклог спринта:
"Страница логина пользователя" 3SP
"Создание нового вопроса пользователем" 13SP
"Отображение ленты вопросов для пользователя" 8SP
Итого 24SP, остальные уже не помещаются. Здесь видно, что при velocity=24SP, задача в 21SP занимает почти целый спринт, это очень опасная ситуация. Когда у нас в спринте несколько десятков задач, то ошибка в их оценке может быть в плюс, а может в минус, в среднем одно другое компенсирует, а вот с нашим делением будут большие проблемы. Поэтому Story также нужно дробить сильнее, чтобы задач в спринте было много.
На daily meeting кроме всего прочего не лишним будет смотреть на метрики спринта, одна из важнейших - график сгорания, отклонения в нем позволяют нам сделать вывод, что мы не успеваем реализовать все к концу спринта, а значит надо понять какие задачи не будут сделаны и предупредить бизнес. Стоит ли говорить, что если PO не появляется на ежедневных встречах и не следит за прогрессом, он не сможет вовремя скорректировать работу. Если PO не является реальным владельцем продукта и по каждому чиху будет брать время, чтобы уточнить у реального, то гибкость (agile) будет очень сомнительной.
В конце спринта на проде у нас должны быть 3 вышепреечисленные задачи. Пользователь сможет зайти, создать вопрос и просмотреть созданные им и не только им вопросы. Т.е. вроде как мы доставили определенный бизнесовый функционал, но на MVP это не тянет, отвечать на вопросы еще нельзя, поэтому для использования проект не готов. Не всегда за 1 спринт получается выкатить MVP, но благодаря тому что мы уже чтото выкатили, на это можно посмотреть вживую и получить обратную связь с корректировками, а значит это agile.
А далее, все тоже самое, регулярный грумминг, в начале спринта - планирование.
Баги и неожиданные срочные задачи идут параллельным потоком, оценке подвергаются только business stories, т.к. важно сколько вы сделали бизнесового функционала в спринт. Поэтому баги нужно решать отдельно, крупные изменения в инфраструктуре отдельно, старайтесь это делать параллельно основным задачам в спринте, но кто-то прибегает даже к выделенным "техническим" спринтам.
SP - это относительная величина, сравнивать их между командами бессмысленно, поэтому Velocity это тоже умозрительная эфимерная величина, она может меняться, подстраивайте ее исходя из того, сколько команда реально делает за последние спринты, а не год назад. Попытка улучшать производительность ориентируясь на Velocity печальна, как только мы вводим контроль на основе правильной метрики, метрика перестает быть таковой, поэтому введение KPI очень сложно и не везде осуществимо.