Как разбивать задачи и увеличить эффективность ваших процессов?

О чем статья и зачем это вам?

Все всегда разбивают задачи на более мелкие чтобы их было удобнее анализировать/разрабатывать/тестировать. Всегда были Epic задачи в беклоге, которые мы били на более мелкие User stories. Но именно формат User stories и потребность в том, чтобы любая задача давала после своей реализации бизнес-ценность Заказчику, останавливает многих от разбиения на мелкие задачи. То есть мы не видим возможности разбить задачу кроме как разделить ее на технические задачи, и решаем остановиться.

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

В чем проблема больших задач?

Что дают большие задачи?

1. Лучше видна основная проблема, которую нужно решить. Команда видит не кусок проблемы, а всю ее, что дает лучший vision и дает принимать решения лучше. (Это можно решить другими способами).
2. Что-то еще?

Какие проблемы больших задач?

1. Они увеличивают вариативность процессов. Меньше предсказуемость в успешном закрытии спринтов, меньше вероятность в успеть закрыть такие задачи в релиз.
2. Они увеличивают нагрузку на команду. Разработчики "пилят" большую задачу 3 недели, тестировщики - курят. Затем тестировщики пилят, а разработка ждет.
3. Они увеличивают очереди и время цикла. Задача 3 недели в разработке. За это время никакие "приоритетные" задачи не будут закрыты.
4. Они уменьшают эффективность обратной связи и увеличивают риски. Только через 2 недели мы узнаем что не поняли проблему Заказчика.
5. Они снижают качество. Мы внедряем 2-х недельный функционал разом и получаем большое количество ошибок. Они стоят "дороже" по сравнению с тем, что мы бы могли внедрять функционал раз в 2 дня и решать проблемы постепенно. 
6. Наверное есть еще много производных проблем от тех, что описаны выше.  

На самом деле редко у кого есть большие задачи в работе. Команда легко бьет любую задачу на более мелкие, но они это делают в рамках своего понимания. И понимание у них техническое. В результате у таких мелких задач огромная связность, и проблема никуда не уходит.

1. Сделали за 2 дня изменение в Модели в БД. РО смотреть нечего.
2. Сделали за 1 день новые формы, которые еще не работают. РО это не интересно. 
3. Сделали за 3 дня логику, которая еще не полная и потому не позволяет проверить весь процесс. "Эй, РО. Пока не смотри, скоро все будет".
4. Доделали за 3 дня логику. Но нужен еще рефакторинг.
5. Сделали за 1 день рефакторинг. "РО, все готово".
6. В результате через 2 недели - "Но я же хотел чтобы инфляция применялась в рамках расчетов", "Мне не нужен выбор проектов, мне нужно выбрать сразу весь портфель проектов", "Расчет эффективности проектов не правильный. Зачем вы учитываете инвестиции для расчета социальной эффективности"
7. ОК, еще +1 неделя чтобы все доделать. 

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

Почему здесь может помочь Story Map?

Ранее я использовал предложение Dan Rawsthorne, которое услышал на AgileDays'12. В любой задаче можно определить backbone (основной костяк, который необходим для закрытия задачи), beef-up (бесконечные улучшения по задаче), alters (реализация альтернативных сценариев, fail cases), UI (так же бесконечные улучшения по UI/UX). Все фичи мы нарезали на эти части (в голове) и формировали по этому пониманию User stories. Но так как это разрезание было в голове у аналитика, то часто в процессе разработки были различные споры, что входит в scope задачи, и что нет.

Так же есть - The hamburger method. Пару раз мы к нему обращались, резали задачи как предлагается, но видимо из-за того что это было мало формализовано и большей частью выполнялось в голове, так же плохо сработало для нас.

В результате я вернулся к Story map.

Story map в исходном понимании используется для формирования и ведения карты функционала по продукту. Большая и подробная карта функций/историй. Я нашел эту технику мало полезной пару лет назад. Идея чтобы собрать всех членов команды и за 1-2 дня сформировать 2 сотни историй, которые сформирует исходный беклог продукта, кажется мне не продуктивной. Уже через неделю мы узнаем о продукте гораздо больше и половину историй нужно будет выкинуть, иначе мы их сделаем и это будет никому не нужно.

Потому для ведения scope по продукту я используют Impact mapping, и функционал представляется в виде дерева. В рамках Impact map я нахожу процесс стратегического планирования более эффективным.

Но я вернулся к Story map чтобы разбивать крупные фичи, которые являются атомарными в Impact map. "Стресс-тестирование портфеля проектов", "Оценка эффективности портфеля проектов". Для Impact map это атомарные фичи, Стресс-тестирование - это отдельная фича сценарного анализа, а оценка эффективности - это часть процесса мониторинга. Но в части разработки это будет стоить нам 2-3 недели на каждую из этих задач, потому давайте бить. 

Как я разбиваю задачи?

Как инструмент я использую "Google Sheets".

Сверху слева-направо разбивают задачу на этапы/шаги/части в зависимости от типа задачи.
Сверху-вниз описываю инкремент по задачам, которые можно сделать в рамках этого шага, отсортированные по их ценности/реализуемости. Чаще всего первый шаг - это "мы ничего не делаем".

1. Нужно позволять делать ввод данных - не делаем ввод данных. 
2. Нужно делать расчет - не делаем расчет. 
3. Нужно визуализировать результаты - показываем статику. 

В результате есть матрица из N x M мелких задач, которые можно сделать независимо.

Так как задачи слишком много и они слишком мелкие, то нужно сделать их объединение в рамках одной задачи Вашего беклога. Для этого можно использовать следующую логику:

1. Задачи по самым рисковым шагам/этапам решаем первыми.
2. Группируем задачи так, чтобы были все шаги по горизонтали, и можно было максимально быстро показать результат Бизнесу.
3. Группируем задачи исходя из их сложности. Сколько задач можно объединить чтобы получилась задача на 2-3 дня. 

Далее цветами можно сгруппировать задачи в рамках user stories, и определиться с их приоритетом в беклоге.  

Для разбиения Story map по столбцам я использую следующие подходы:

1. У нас есть use case на процесс, который имеет ряд шагов. Столбец == шаг процесса.
2. У нас есть большой функционал, который независим между собой. Столбец == независимая часть задачи.

Какие есть проблемы/примеры их решения?

Какие могут быть проблемы с построением Story Map или разбиением задач?

Интеграция 2-х систем

Есть мнение что статус интеграции систем бинарен - он или есть или нет. В результате это занимает 2 месяца и проходит довольно мучительно. А именно:

1. Разрабатываем API для интеграции и согласуем его для обоих систем. Неделя.
2. Реализуем это API для обоих систем. Так главная наша надежда/удача: "мы делаем это параллельно и независимо, потому выйдет дешевле". 1 месяц
3. Начинаем тестировать интеграцию и вылазят проблемы. В результате мы много раз переделаем весь API и переписываем обе реализации. Еще +1 месяц.

Как это можно сделать:

1. Формируем Story Map по методам, которые входят в API. 
2. Реализуем 1 метод, который передает 1 параметр, в обеих системах и начинаем тестировать. 1 день.
3. Находим все проблемы с сетевой связностью, со различных стандартами SOAP в Java и С++ и тп. Решаем их. Пишем интеграционные тесты, чтобы можно было автоматически тестировать интеграции 100 раз в день. Пишем моки сервисов для каждой системы, чтобы можно было тестировать интеграцию локально. 1 день
4. Реализуем 1 метод, которые передаем все параметры, в обеих системах и начинаем тестировать. 2 дня.
5. Находим проблемы с различным представлением строк/многомерных массивов/последовательностей в реализациях SOAP для Java и С++. Решаем их и договариваемся что все дальнейшее API будет это учитывать. 1 день.
6. Итеративно наращиваем API с постоянным тестированием интеграции. 1 месяц
7. Остальное время мы съэкономили.        

Модернизация

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

Как это можно сделать:

1. "Сделать изменение для 7 услуг" и "сделать изменение для 7 услуг так чтобы все услуги всегда работали" - это 2 разные задачи и вторая задача сильно дороже. 
2. Делаем Story map по шагам услуги
3. Делаем изменение для самых рисковых шагов для 1 услуги. Ломаем все остальные услуги.
4. Итеративно дорабатываем 1 услугу и показываем Бизнесу. Получаем OK.
5. Дорабатываем остальные услуг по аналогии.     

Какие результаты вы можете получить?

Какие результаты от разбивания задач на более мелкие, разработка по которым будет стоить 2-3 дня? Не скажу, что все именно из-за мелких задач, но это сильно влияет:

1. Это СИЛЬНО сокращает время цикла по задачам, как я писал для Kanban-системы. Далее идут уже следствия сокрашения Cycle time.
2. Это уменьшает вариативность процесса. То есть более предсказуемое и постоянное кол-во задач, закрываемых за релиз (для Kanban), и более постоянный velocity в Scrum.
3. За счет того, что у вас более предсказуемый и постоянный поток, вы сможете уменьшить WIP и размер очередей в процессе.
4. Это снизит переработки (когда или очень много работы или ее мало) сотрудников и повысит их загрузку.
5. Меньше Cycle time и выше Work time -> увеличение эффективности команды
6. Это повысит качество результатов.
7. Это сильно ускорит обратную связь от Бизнеса, в результате снизит ваши риски и увеличит доверие Бизнеса.

Готовы попробовать?

Как перейти на Kanban из Scrum или Scrumban-а? Часть 2

У нас был Scrumban и я решился на изменения.

Так как аналитика была на месяц вперед, то очень часто ее результаты "протухали". То есть результаты анализа по задачам были готовы, но в спринт не попадали. Понимание менялось, и сами результаты устаревали. Так же активность по аналитике была периодической. За пару дней к workshop она сильно возрастала, но готовность всех задач к обсуждению обычно не была реализована.
Контролировать это в рамках Scrum было сложно. Хотелось перейти на Flow/Поток задач. Вместо бесконечных споров про оценку и Scope историй фокусироваться на Impact/Влиянии.

В общем я решился.

Из Scrumban переход на Kanban занял у меня 2 часа на настройку В Agile Jira и еще час на создание новой бумажной доски.

Старую Scrum доску я оставил, удалив все Draft спринты - теперь это просто Product Backlog. В нем мы формируем задачи по релизам, как обычно.

Создал общую Kanban доску со всеми статусами по аналитике и разработке. Именно здесь задается весь Flow - указаны все возможные статусы задач и порядок их следования. Указал WIP на разные статусы. Здесь специально не присутствует столбец с беклогом - в нем всегда слишком много задач и потому он получается слишком большим.
Именно эта доска синхронизируется с бумажной.

Далее создал Kanban доску "Research" для аналитики. Она начинается с беклога и завершается готовностью задачи к разработке.

Sprint беклог перешел в Kanban доску "Development" для разработки.

Так как статусов слишком много для отчетов/анализа я создал еще одну доску "Common", объединим статусы по этапам.

Которая дает вот такой отчет и позволяет увидеть где у нас проблемы и wastes.

Что в результате после пары недель полета:
1) Команда считает что без спринтов на них ничего не давит, и они стали медленнее работать. Я в это не верю, и хочу проверить идеи #NoEstimates.
2) У нескольких знакомых видел что спринты позволяют лучше планировать в условиях заказной разработки. Знаешь срок завершения проекта, знаешь сколько спринтов успеешь провести, планируешь какой функционал должен быть закрыт за каждый спринт. Боюсь это самообман и походит на планирование через MS Project. IMHO, процесс планирования должен быть другим.
3) Все Scrum активности (кроме планирования) мы оставили и так же проводим их по расписанию.

Остальное - покажет время.

Бумажная доска выглядит так. Scrum-овские карточки с миньонами заменяются на более простые Kanban-карточки.

Как перейти на Kanban из Scrum или Scrumban-а? Часть 1

Что лучше Scrum или Kanban? Не думаю что есть ответ, они для разных целей.
Нужен ли вам Kanban? Так же зависит от ваших целей.

Мое мнение - они фокусируются на разном.
В Scrum больше фокуса на реализации scope спринта. То есть важно уметь нарезать правильно истории и задачи, правильно их оценивать, реагировать на проблемы с ними, и все это заканчивается результатом - Успех или неуспех в реализации scope Спринта беклога. Не успех - давайте нарезать по-другому, давайте оценивать лучше, давайте обсуждать лучше.
В Kanban (я надеюсь) больше фокус на саму поставку историй, на скорость поставки, на их ценности. Именно поэтому я решился на изменение.

Scrum имеет сильное преимущество перед Kanban - он более строгий и формальный. Он дисциплинирует команду, PO, Заказчика. Вы не можете обеспечить стабильный scope Спринта на 2 недели? Заказчик все время требует перекрасить кнопку в красный и именно сегодня? Это не в Scrum процессе проблемы - это у вас проблемы. Вы оцениваете в часах, а потом требуется от разработчиков чтобы оценки исполнялись с высокой точностью? Вы не можете зафиксировать объем одной истории и при реализации она сильно пухнет? Вам нужно через все это пройти и научится. Потому я уверен что успешный опыт Scrum процесса нужен это эволюции команды и других участников проекта.

Почему мы перешли на Kanban?

В процессе работы мы перешли от чистого Scrum в сторону Scrumban, и последующий переход на Kanban был довольно логичен.

Проблема была в аналитике. Мы вынесли процесс аналитики за пределы Спринта, то есть к Планированию аналитика по всем историям должна была быть достаточной для их оценки. Аналитика должна была быть финальной - в процессе реализации все появляются вопросы/проблемы, которые нужно решать совместно разработчик-аналитик. Но до планирования большая часть аналитики должна быть выполнена.

Далее как я писал ранее про теорию ограничений возникло желание увеличить скорость выпуска путем увеличения усилий по аналитике, то есть к моменту Планирования по истории должны быть готовы все необходимые артефакты по историям - OK от Заказчика, готовые/согласованные SpecByExamples, скетчи/прототипы интерфейсов. Это увеличило длительность и сложность процесса аналитики и сделало его более формальным. В результате у нас появляются Draft Спринта (задачи, которые должны быть готовы к Планированию и которые мы вероятнее всего возьмем в Спринт) и Pre-Draft Спринта (задачи, которые мы грумим, если есть время). То есть 2 предварительных спринта по 2 недели. Мы делаем аналитику на месяц вперед.

Для Draft и Pre-Draft спринтов я создал отдельные аналитические Kanban доски, где описаны какие стадии и в какой порядке должны пройти истории в процесс аналитики. Чтобы формализовать процесс и сделать его визуализацию. То есть там есть столбцы на OK от бизнеса, на предварительное обсуждение с РО для формирование общего vision, на разработку скетчей, прототипов и спек.

Настройка SQL выборки для доски 

Настройка столбцов и статусов

У нас Scrum и 3 Kanban доски для работы. Это можно назвать Scrumban.

Продолжение следует.

Создание презентаций для тренингов

Смена подхода по созданию слайдов для презентаций за последние 2 недели. Последние презентации доступны здесь - Slideshare.net

Как результат - уверенно "черчу" на графическом планшете. 

Инкрементальность и прозрачность

Мы не успели. Мы хотели реализовать фичу с межведом и не успели.

Какие есть факты?

1. Команда А потратила в совокупности примерно 2 месяца на фичу межведомственного взаимодействия.
2. После этого была полная уверенность что все хорошо. Мы видели запросы - они создавали ощущение что все OK 
3. Комнада Б получила неделю чтобы показать свою часть и общее демо по задаче при сильно уменьшенном scope.
4. В результате продемонстрировать фичу в полном объеме не смогли.
5. Не смогли показать - значит все потраченное время это waste.

Знакомо?

Сейчас когда все видят fail, лучше всего пытаться что-то изменить. Мы все делали как раньше - это привело к fail, наверное есть что можно поменять.

Я вижу 2 проблемы.

Инкрементальность 

"Scrum employs an iterative, incremental approach to optimize predictability and control risk." Из Scrum Guide.

Как было в нашем случае. 

Мы разбили фичу на отдельные US, которые можно было делать параллельно. Потратили неделю. За день до демонстрации стали соединять куски в общую фичу. Вылезли проблемы. В результате ошиблись в сроках где-то на день, и как результат - фичу не показали. Это не единичный случай - большинство fail спринта имеют эту проблему в основе.

Как можно было сделать в рамках инкрементального подхода. 

Сделать маленькую сквозную задачу чтобы получить результат в самом минимальном объеме:

1. На форме ввода данных запроса есть только кнопка отправить запрос.
2. На клиентской части показываем лишь номер запроса и кнопка "Ответить".

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

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

Если бы это было бы не специальное демо, а просто обычный спринт - мы так же увидели бы фичу в конце спринта возможно с неполным АС. Но фича бы была. По ней можно было бы узнать больше и принимать следующие решения. Это крайне важно.

Какие варианты решения я вижу? 

Shift

Нужен shift мышления самих разработчиков. Его сейчас нет ни в одной из команд. Более того сейчас у разработчиков позиция что это нельзя делать, так как в инкрементальном подходе стоимость фичи выходит дороже. Нет - это не так. Это такое же заблуждение как с парной разработкой. "2 разработчика отдельно сделают всегда больше чем в паре." 

Эта смена мышления решит все проблемы с инкрементом продукта, но это сложно. Каждому в голову не залезешь.

Backlog 

Сверхспособный РО умеет так бить User Stories заранее что вынуждает команды из-за WIP ограничения поставлять продукт в рамках спринта инкрементально. Но фактически это означает что РО будет думать не над тем как быстрее и эффективнее сделать продукт. Его мысли направлены на то, чтобы вместо Scrum Master сформировать такие ограничения чтобы команда самоорганизовалась в сторону инкремента продукта. Это возможно, но это печально. 

Scrum Master 

SM может добиваться постепенной смены мышления в команде обсуждая реализацию каждую фичу и сподвигать их на инкрементальную разработку внутри монолитной единой крупной story как фичи. 

Прозрачность 

Второй факт что усугубляет проблему - это отсутствие прозрачности. Мы используем следующие утверждения:

1. Команда самоорганизована и отвечает только за финальный результат спринта. За промежуточные результаты в спринте никто не отвечает. То есть команде можно сказать что "у вас есть проблемы" только в самом конце спринта уже на демо. Когда все что могло случится - уже случилось и изменить ничего нельзя.
2. Burn-down chart ни о чем не говорит. Это мое любимое! Не важно что прошло пол-спринта и мы не съели ни одного point! Это не твои проблемы, Чувак! Ты нам мешаешь. Еще полчаса и мы сразу закроем 2 задачи на 5 и на 8, и все сразу станет OK.

В результате burn-down chart не используется, перетаскивание задач по статусам используется только чтобы видеть статус конкретной истории. То есть НЕТ НИКОГО прозрачного механизма, который бы мог показать как идет дела в любой момент времени. 

А его нет потому что он и не нужен. Подход прост - мы как Команда делаем что можем и в конце просто смотрим успели мы закрыть спринт или нет.

И все управления процессом поставки продукта у нас сводится к тому чтобы прийти за пару дней до демо и сказать - Чувак, нижних 3-х задач не будет, не жди. Давай выкинем их из спринта.

Chart - это один из механизмов перехода с Push управления на Pull на управление через  сигналы и прозрачности. РО должен не присутствовать на daily, и просто проходя мимо доски глядя на chart понять если ли риски на fail спринта и какие. Смысл chart-а в том что он убирает все эти эмоции и ощущения членов команд (Да, эта фича уже готова. Там пара тестов написать, залить в develop и перенесем в "Done"), и показывать просто цифры. Chart показывает факт - остальное ему не важно. В этом и смысл.

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

Что делать?

Я изменю процесс определения scope истории на более формальный и более определенный. Должно быть лучше видно как можно вырезать scope в случае проблем. Но это не решение.

Что делать командам А и Б?

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

Как писать пользовательские истории (User Stories)

Вы "вляпались" в Scrum и начали описывать требования к продукту в виде User Stories. Есть Шаблон - он понятен, но жутко не удобен. Но это же Scrum - просто делай, и будет магия.

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

Приходите на планирование. РО читает название истории. Все делают удивленные лица. РО рассказывает, что нужно сделать в рамках этой историй. Все кивают. Оценивают. И далее нужно лишь запомнить, что под этим большим, непонятным названием истории с оценкой "5" скрывается задача на добавление нового поля на форму и в БД.

Зачем нужны User Stories?
Про это написано куча статей. Не верите в User story - не используйте.

Мои правила на написание User Story

1. Есть один actor 
2. Есть одно действие
3. Есть одна ценность / value / impact. Я выделяю ее ЗАГЛАВНЫМИ БУКВАМИ при написании User story.  

Actor 

C актером все более-менее просто. Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в  начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла - значит эта часть бесполезна.
Вы определили роли в Системе и поняли что их не очень много - Пользователь, Оператор и Админ. И креативите по 100 историй, которые начинаются как "Как Пользователь Я ...". У вас закрываются  несколько спринтов, истории которых начинаются одинаково. Зачем вам это нужно?  Да, это бесполезно.
Джеф Паттон предлагает следующее:

1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп. 
2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли "Пользователя системы"
3. Пишите истории с точки зрения этих актеров указывая их уникальные названия. 
4. В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие - для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны.

Действие

Наверное здесь сложно ошибиться - это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное "КАК"-решение.

Ценность

Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите "чтобы ..." и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?

Отказаться от формулировки "чтобы". Это корень зла. ДА, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.

Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.

Представим что вы создали историю - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение".
У меня Аcceptance Сriteria - это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ". То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.

Но в чем ценность того, что аналитик стал получать отчет быстрее?
Здесь можно перейти к общей постановке Цели для продукта. Чтобы прийти к такой истории вы:

1. Вы построили Impact mapping
2. Вы определили Цель и метрику на нее. Например, "ускорение сроков согласования инвестиционных бюджетов". 
3. Вы определили что "инвестиционный аналитик" может вам помочь в достижении этой цели.
4. Вы сделали предположение что если аналитик будет получить отчет №17 быстрее, то это приведет вам к вашей цели.  
5. Потому данная история - это проверка данного предположения достижения цели.  

То есть смысл Impact map - это трассировка от User story к общей Цели продукта. Если такой связи нет и вы не можете ее найти - значит вы делаете что-то бесполезное.

То же самое можно сделать в любой момент времени на любом этапе создания продукта. Вы знаете что нужно сделать и это будет полезно, но вот ценность определить однозначно не можете. Вы видите десятки вариантов то, что нужно написать в "чтобы ...". Постройте путь до цели в Impact map. Найти то влияние что вы должны оказать на актера в результате. Не пишите всякую чушь, в которую сами не верите.    

Удачи!