Расскажите, насколько плохая практика помечать тикет, который не был доделан

в спринте специальным статусом типа Done но не совсем (надо подумать над названием), а на хвост создавать еще один и брать его в новый спринт?

Ну если так, отмените первый, причину в коммент, создайте новый, свяжите, оцените как новый и вперед. Все зависит от того, как вы ведете учет.

пока никак, рисую процесс для своей команды и задумался, как бы красиво оставить недоделанный тикет, чтобы по нему было видно, что он не был сделан в спринте

Просто карточка в бэклог проекта возвращается. Какая разница сделана она частично или не сделана, результат один - не сделано. На ретро нужно разобрать почему, устранить причину и не допускать такого в будущем. Не нужно делать процессом такое исключение. Нельзя настраивать команду, что истории могут быть не сделаны. Уж лучше брать меньше историй в спринт, чем на грани. Наверняка не выполнили, потому что в других историях не учли время на что-то

я люблю, когда о любой проделанной работе есть артефакт, когда мы занимаемся тайм фреймингом (спринтами), то хотелось бы чтобы эти артефакты еще строго относились к одному из фреймов и соответствовали реально проделанной работе пометить тикет Incomplete и сделать еще один на хвост вроде бы решает эту задачу, просто немного бюрократии

Такая практика вмешивается в упорядочивание бэклога, за которое отвечает РО. То есть, помиме его взгляда на мир, появляется что-то, что должно пойти вне очереди. Это неверно. Из скрам гайда по этой же причине убрали обязательность включения в бэклог следующего спринта экшен айтемов с ретроспективы.

мейк сенс

Каждый элемент бэклога должен нести ценность. Если ты сможешь разбить незаконченный элемент на два так, чтобы сделанное несло ценность и соответствовал ДоДу, то ты его закроешь в спринте. А остаток оформи в виде нового элемента, так же, с условием наличия ценности. Чтобы подобные упражнения не случались неожиданно в конце спринта, надо проводить переоценку остатков ежедневно, тогда сигнал о возможной проблеме ты на BDC увидишь гораздо раньше, чем накануне ревью.

а ну то есть предлагаешь переписать тикет и закрыть его в конце спринта? не канонично как-то, но лучше чем ничего

Я бы переносил всегда недоделанные стори в следующий спринт. Да, отчет пропадает. Но это свое образные налог на хреновый процесс. По-идее команда должна оптимизировать, что бы незаконченных айтемов не было. Это не обязательно, но наверняка подрывает цель спринта.

Не переписать, а разбить на два.

Меняет. Он обязывает РО согласиться с включением этого элемента в следующий спринт. А у РО в голове может быть цель для следующего спринта абсолютно не связанная с тем, что переносится. Каждое планирование должно начинаться с чистого листа, безо всяких долгов.

а что с долгами делать? без них же нельзя закоммититься на новый спринт

Стоп, стоп PO же вообще ничего не решает за Sprint Backlog - это план команды. Айтем который недоделали как сидел в позиции N внтутри Product Backlog так и сидит.

Возвращать в бэклог с переоценкой оставшегося. И все долги участвуют в упорядочивании бэклога наравне со всеми остальными элементами.

тогда там будет висеть оценка на хвост, а не на весь спринт (

Спринт бэклог набирается из бэклога продукта для достижения цели спринта. А не цель спринта устанавливается по факту набора элементов из бэклога продукта.

Конечно. Оценка - это всегда сколько осталось. И пофигу, сколько уже потрачено.

а если захочется через пару месяцев прикинуть, сколько сил было потрачено на набор тикетов? старая оценка утеряна

Она тебе зачем? Мир поменялся. То, что 2 месяца назад стоило 13 теперь стоит 5.

Спросят у разработчика что он делал полгода, а он возьмет свои тикеты и просуммирует SP, поч нет?

Интересно тогда зачем в Продак Беклоге есть что-то кроме целей? Почему это не Objective-based roadmap раскиданый по спринтам? Чет тут в Гайде каким-то булшитом попахивает

а разве цели(эпики) нужно клаcть в бэклог? Мне всегда казалось, что как только цель разбита на исчерпывающие подзадачи, то она как PBI вытаскивается из бэклога, оставляя после себя множество других PBI (те самые подзадачи)

Тогда получается, что мы из айтемов Product Backlog собираем цели обратно, и достижение цели ~ выполнение всех айтемов на которые она разбита

Кмк, тут есть проблемы с переводом. В английском языке есть два слова - "objective" и "goal". На русский оба слова переводятся как "цель". Но, как говорится, есть нюанс. Objective - это цель стремления, та, с которой РО приходит на планирование. В процессе формируется бэклог спринта и формулируется sprint goal, под которой уже комитятся. И, кстати, sprint goal является частью бэклога спринта.

Кто спросит и зачем? Так-то можно спросить и сколько строк кода написал Только зачем?

Ну у менеджмента всякие загоны бывают)

Так все же, являются ли выбранные для спринта задачи substitute для установленной цели или нет?

Менеджмент надо завернуть на РО, пусть он им результаты продаёт, а не вот это вот всё.

получается из чего? не понял))) я параллельно пытаюсь понять, нужно ли держать эпики в бэклоге, если для них уже есть разбиение на подзадачи?

Ну так если они попросят в окно прыгнуть, ты ж не станешь прыгать

А где держать эпики кроме бэклога продукта? Можно свимлайн отдельный для них сделать, будет удобно. В SAFe отдельный бэклог для эпиков, но это тот же бэклог другого уровня.

Вопрос в том где их держать когда эпик декомпозирован))) Кто выше — подзадача эпика или эпик? Или вообще эпик там не держать с момента, когда он декомпозирован?

Согласен. Эпик - это законченная бизнес инициатива. Она может реализовываться не сразу, этапами. Мы эпиками отражаем стратегию развития продукта.

Я же предложил решение - отделить свимлайном юзерстори, эпики и задачи и выше или ниже эти блоки не имеет значения. Эпики не беруться в работу, они выполнены, когда выполнены все составляющие юзерстори.

А зачем эпики вместе со сторями в одном борде? Как они будут отражаться в воркфле?