Изменение User Story

[Misha Marchenko]

Всем привет.

Если есть user story которая уже согласована с заказчиком и уже взята в спринт и что-то по ней сделано(минимум). И команда в этот момент придумывает новое решение, которое меняет поведение user story, но при этом делая ее более интуитивно понятной, но что влечет за собой необходимость ее переоценки, переописания и переделки мокапов.

Что лучше делать в таком случае?

--
Marchenko Mykhailo

Phone: +38 063 8477434
           +38 091 3001389

Skype: shami-13
Twitter: http://twitter.com/shami13
Linkedin: http://www.linkedin.com/in/shami13
Blog: http://blog.shami.com.ua
Site: http://shami.com.ua

[Andrew Pavlyukov]

Привет.

Похоже что нужно улучшать процесс Sprint Planning-а

В конкретном случае можно узнать мнение ПО по поводу "меняет поведение user story, но при этом делая ее более интуитивно понятной" и от этого уже отталкиваться 

Andrew

[Artur Rakytskyy]

Привет,

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

а) Если ПО согласен, то:

- отмечаем исходную User Story как Not Done/Outdated/Won't Fix,

- заканчиваем спринт без нее,

- в освободившийся слот добавляем ту User Story, которая уже была оценена ранее, влазит по всем критериям, и находится сверху Product Backlog по приоритету/срочности,

- на следующий спринт берем новый вариант User Story с новой оценкой,

б) Если ПО не согласен, то:

- делаем исходную User Story как и планировали,

- добавляем в Product Backlog новую User Story как Improvement/Redesign к исходной,

- на один из следующих спринтов берем новый вариант User Story с новой оценкой,

в) Если команда относительно большая, и есть договоренность планировать спринт по принципу типа 70% + 20% + 10% (must have + important + nice to have), а также у команды выделен буфер времени на внеплановую работу, то:

- проводим оценку новой версии User Story за счет буфера внеплановой работы,

- сообщаем ПО, что есть замена исходной User Story с такой-то оценкой,

- получаем от ПО согласие на новый вариант Sprint Backlog, иначе смотри б)

- заменяем исходную User Story на новую,

- делаем новую User Story за счет остатка исходной оценки + 20% + 10% хвостовой оценки (максимум)

Все три варианта обязан урегулировать Scrum Master, а варианты а) и в) требуют непосредственного личного участия ПО посреди спринта.

Ну и самый главный ответ на вопрос "что лучше делать" - лучше ничего не делать (ближе всего - вариант а) ) :)

Точнее, лучше не спешить все бросать, и не заниматься переделыванием посреди запланированной работы, не рисковать уже достигнутым результатом спринта, не ломать уже отработанный график планирования и поставки продукта.

Если говорить терминами проектного менеджмента - нужно начать с анализа и планирования рисков, как и в любой "нештатной" ситуации. Правда этот совет лежит уже за рамками Scrum :)

Удачи в решении, каким бы оно не было!

2013/10/16 Misha Marchenko <sha...@gmail.com>

--
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
---
Вы получили это сообщение, поскольку подписаны на группу Agile Ukraine.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес agile-ukrain...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--

With all regards,

Artur Rakytskyy

Technical Project Manager

http://epom.com/

Skype: epom.artur.rakytskyy

[Nataliya Trenina]

Привет.

Странно, но даже к такому структурированному и исчерпывающему ответу как у Артура хочется что-то добавить :) Наверное, это свойство ума - думать сразу что бы сделала я..

Можно еще до общения с PO посмотреть его глазами на ситуацию:

• насколько дороже/дешевле я заплачу?
• насколько большую ценность получу?

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

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

Еще было бы полезно провести ретроспективу этого случая - сразу, до окончания спринта. Минут 15-20 с советами себе же на следующее планирование.

Успехов!

Наташа

16 октября 2013 г., 13:53 пользователь Artur Rakytskyy <art...@gmail.com> написал:

--

Nataliya Trenina

Agile coach, Executive @ SCRUMguides 
Founder, Chair @ HOTCODE Conference 
Founder, Chair @ AGILE Eastern Europe

LinkedIn | Twitter | Facebook | Blog | 

+38.050.412.61.35 Skype nattrenina

HOTCODE COOL IS www.hotcode.org

[Artur Rakytskyy]

• насколько дороже/дешевле я заплачу?
• насколько большую ценность получу?

Оба ответа можно получить только после оценки новой версии User Story командой (считаем что приоритет новой версии остается прежним), а для оценки нужно время и желание. Так что в вариантах а) и в) ответы будут получены при наличии желания у ПО и довольно быстро, а варианте б) - в любом случае, но позже.

С обсуждением на ретроспективе - полностью согласен, раз возник такой вопрос в данной группе, и (предполагаю) случай нетипичный для уже сложившегося процесса.

P.S. Добавлю немного ценности к моему сообщению.

В моей сегодняшней команде мы часто сталкиваемся с подобными случаями, а также с тем, что приоритеты сильно и часто меняются как в Product Backlog, так и в уже запланированных итерациях (мы планируем 2-3 итерации вперед). 

Ко всему этому у нас приличное количество внеплановой работы из-за совмещения разработки и поддержки (мы выделяем в среднем 1,5 часа из 8 рабочих часов в день на внеплановые работы), и даже в уже начатой итерации бывают "замены" и "отмены" задач.

Я решил данную ситуацию отказом от Scrum, планированием в "идеальных" часах, отказом от групповой оценки большинства задач (а значит и Planning, Sprint Review Meetings), и очень формальной приоритезацией задач бизнесом.

Сейчас у нас довольно "кастомный" процесс разработки, но одной из ближайших целей является использование Kanban при максимальном сокращении цикла поставки (с двух недель до 1-2 дней).

P.P.S Daily Scrum у нас тоже нет, как и позиции Scrum Master :)

2013/10/16 Nataliya Trenina <nat.t...@gmail.com>

[Alexey Krivitsky]

0. Поблагодарить команду за то, что они пытаются найти лучшие решения. 

1а Если команда все еще верит в достижение цели спринта с улучшеной историей И продакт оунер согласен на улучшения - то обновить историю и работать на благо.

1б Если достижение цели уже под вопросом, то проведите мини планирование (после дейли) и помассируйте скоуп спринта, пока все не станет снова хорошо.

Подумайте также о вынесении улучшений текущей истории в новую историю - дабы было легче мессить скоуп.

--

Alexey Krivitsky

Certified Scrum Trainer

SCRUMguides : Agile coach, Scrum trainer

Agile Eastern Europe : Co-producer

AgileUkraine: Inspirator
Lego4scrum: Inventor

LinkedIn | Twitter | Facebook | XING | CV | Blog | Skype: alexeykrv | +38.050.358.9212