Изменение User Story

115 views
Skip to first unread message

Misha Marchenko

unread,
Oct 16, 2013, 4:45:53 AM10/16/13
to agile-ukraine
Всем привет.
Если есть user story которая уже согласована с заказчиком и уже взята в спринт и что-то по ней сделано(минимум). И команда в этот момент придумывает новое решение, которое меняет поведение user story, но при этом делая ее более интуитивно понятной, но что влечет за собой необходимость ее переоценки, переописания и переделки мокапов.
Что лучше делать в таком случае?

--
Marchenko Mykhailo

Phone: +38 063 8477434
           +38 091 3001389

Andrew Pavlyukov

unread,
Oct 16, 2013, 5:09:49 AM10/16/13
to agile-...@googlegroups.com
Привет.


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

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


Andrew

Artur Rakytskyy

unread,
Oct 16, 2013, 6:53:29 AM10/16/13
to agile-...@googlegroups.com
Привет,

Из вопроса предполагаю, что команда работает по 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

unread,
Oct 16, 2013, 8:12:41 AM10/16/13
to agile-ukraine
Привет.

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

Можно еще до общения с 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

unread,
Oct 16, 2013, 9:11:53 AM10/16/13
to agile-...@googlegroups.com
  • насколько дороже/дешевле я заплачу?
  • насколько большую ценность получу?
Оба ответа можно получить только после оценки новой версии 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

unread,
Oct 18, 2013, 9:38:26 AM10/18/13
to agile-...@googlegroups.com
0. Поблагодарить команду за то, что они пытаются найти лучшие решения. 

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

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

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

Alexey Krivitsky

Certified Scrum Trainer

SCRUMguides : Agile coach, Scrum trainer
Agile Eastern Europe : Co-producer
AgileUkraine: Inspirator
Lego4scrumInventor

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


Reply all
Reply to author
Forward
0 new messages