скрам покер что это
Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким
В прошлом посте мы рассказали о том, как работаем с бэклогом, а сегодня поделимся подробностями о процессе планирования, который в нашем случае не только полезный, но и увлекательный, поскольку оценку задач мы проводим с помощью «Planning Poker».
Как и зачем мы проводим планирования
Планирование — это регулярный процесс командного обсуждения каждой задачи. Мы проводим его раз в 2 дня, и в нем участвуют только члены инженерной команды и те, кто ставит им задачу.
Для проведения планирования мы собираем всех участников в конференцию лично или удаленно.
Заказчик (постановщик задачи – менеджер продукта, маркетолог или даже генеральный директор) обязательно должен присутствовать на планировании, чтобы объяснить суть задачи, рассказать, как он ее понимает, донести до команды почему задача важна и мотивировать исполнителей на ее выполнение. Цель инженерной команды — за счет дополнительных вопросов выяснить максимальное количество подробностей, вытянуть из заказчика скрытые требования, предложить свои идеи по реализации и выработать наилучший способ решения. Либо объяснить, почему выполнение задачи стоит отложить на некоторое время или не брать в работу вообще.
Постановка задачи
Заказчик зачитывает свою задачу (это всегда делает строго заказчик, чтобы избежать “сломанного телефона” при передаче данных и ускорения процесса выработки решения), объясняет, что именно нужно сделать и почему это важно.
Цель каждого участника команды исполнителей, задавая различные вопросы заказчику и членам команды, выяснить что именно нужно сделать и понять, как лучше всего решить задачу. Затем исполнитель объясняет, что конкретно он планирует сделать, и уточняет, устроит ли такой вариант заказчика и команду. Все участники высказываются по очереди, и после того, как все определились с наилучшим решением, наступает этап оценки сложности задачи.
Оценка сложности
Оценка сложности производится с помощью цифровых карт — это и есть так называемый Planning Poker: все участники команды исполнителей должны в закрытую оценить сложность задачи в днях трудозатрат, т.е. сколько рабочих дней (из расчета стандартных 8 часов) нужно конкретно ему (участнику) на выполнение задачи. После того как все исполнители положили карты рубашками вверх, все должны перевернуть свои карты так, чтобы числа были видны всем участникам процесса.
Исполнители с пограничными оценками (т.е. участники, которые дали самую низкую и самую высокую оценку по времени) должны объяснить свой выбор. С одной стороны, давление команды не позволит участникам дать неадекватно завышенную оценку сроков, с другой — команда получает возможность обсудить возможные проблемы по задаче. Тот, кто поставил наименьшую оценку по времени, делится с командой, как именно он планирует выполнить задачу так быстро. Участник, который дал самую большую оценку, должен рассказать о том, какие риски и сложности он предвидит при выполнении этой задачи. После повторного обсуждения с учетом всех подводных камней, команда принимает решение о том, какая оценка является более подходящей для задачи. Этот срок заносится в карточку с описанием задачи в таск-менеджере.
Главная цель оценки сложности не предсказать, когда задача будет готова, а убедиться, что все участники одинаково понимают задачу.
Если один участник оценивает задачу в ½ дня, а другой в 3 дня, они явно задумали выполнять задачу по-разному, и поэтому должны согласовать свои действия и объяснить, почему надо делать именно так, как они думают. Иногда расхождение в оценке может быть обусловлено разным опытом в решении схожих задач, в этом случае берется максимальная оценка, но если срок отличается более чем на 1 день, то задача выполняется в парном программировании, когда тот, кто оценил в меньшую сторону, руководит тем, кто оценил в большую.
Советы:
Нужно стремиться, чтобы сложность задачи не превышала 1 день.
Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше. Так все участники будут хорошо помнить все детали обсуждения каждой конкретной задачи. Если задача провисела в очереди на исполнение более 4-х дней, ее нужно снова вынести на обсуждение, чтобы команда вспомнила, что и как нужно сделать по задаче.
Если задача выполняется на 2 дня дольше, чем планировалось, ее нужно вынести заново на планирование и обсудить с командой и заказчиком все сложности и проблемы с которыми столкнулись в ходе выполнения, чтобы в следующий раз при оценке учесть их.
Формат «Planning Poker» хорошо прижился в работу наших команд: разработчиков, аналитиков, админов, и позволяет лучше понимать задачи и пути их решения на этапе постановки.
А как вы обсуждаете задачи и оцениваете сложность и время их выполнения? Делитесь своим опытом в комментариях!
Как оценивать задачи по методу Planning Poker
Если вы не любите оценивать задачи «на глаз», а хотите точных результатов — поиграйте в Planning Poker. Мы расскажем, что нужно делать.
Причем тут покер
Planning Poker (покер планирования) — техника оценки задач для гибких команд. Проводится с помощью карт и напоминает игру в покер.
Иногда метод называют Scrum Poker, так как он подходит для скрам-команд из пятидесяти человек.
Метод Planning Poker впервые описал в своей статье один из авторов agile-манифеста Джеймс Греннинг.
Что почитать про Agile и Scrum:
В оценке по методу Planning Poker участвует вся команда во главе с менеджером проектов — это одно из условий. Руководитель раздает всем участникам по колоде специальных карт. Можно использовать реальные карты, например, вот такие.
Для удаленной команды подойдут онлайн-сервисы. Правила оценки при этом не изменятся.
Сервисы для оценки задач онлайн:
Сервис для планирования и блог о Planning Poker. Можно использовать с компьютера или смартфона. Бесплатная базовая версия подходит для команд до пяти человек. Платные тарифы интегрируются с Jira и в них можно добавлять неограниченное количество пользователей.
Русскоязычная платформа, где можно заказать реальную колоду карт. Онлайн-версия продукта доступна только для пользователей Facebook.
Британский сервис для простого и быстрого онлайн-планирования.
Командная оценка помогает получить объективный результат. Например, разработчик лучше знает, сколько времени реально занимает его работа, но может преувеличить ее сложность, чтобы перестраховаться и получить больше времени. Поэтому процесс оценки всегда контролирует менеджер, он же ведущий. Идея в том, чтобы учесть мнения всех членов команды и сделать наиболее точные прогнозы.
Как работает метод
Вот как проходит оценка задачи по методу Planning Poker. Мы расскажем, что делать, когда команда находится в офисе и ее можно привлечь к обсуждению.
Выберите задачу для оценки
Возьмите из бэклога задачу, которую нужно оценить. Сформулируйте ее так, чтобы вся команда одинаково понимала, что делать.
Так выглядит простой бэклог.
Разделите задачу на этапы. Например, создание главной страницы — это макет, верстка, разработка. Давайте определим, сколько времени займет разработка.
Соберите команду и договоритесь о значениях
Соберите всю команду за одним столом и раздайте каждому по колоде карт. Не важно реальная она или виртуальная, это всегда будут карточки с числами. Но номинал карт, который выбирают команды, может отличаться.
Что за числа на картах
Числа Фибоначчи. Это последовательность чисел, которая начинается с двух единиц, а каждое следующее число получается, если сложить два предыдущих. Вот так: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Чаще всего команды используют именно числа Фибоначчи, но добавляют в колоду ноль.
Пять карт. Можно использовать карты с такими значениями: 0, 1, 3, 5, 10 или просто числа от 0 до 5.
Игральные карты. Некоторые команды используют обычные игральные колоды. Это не так удобно, как работать со специальными картами, но допустимо, если заранее договориться о значениях.
Дополнительные символы. В колоду могут входить карты с такими значениями:
Прежде чем начать работу с картами, установите единые значения и выберите единицу измерения. Вы хотите понять, сколько времени займет задача или нужно оценить ее сложность?
Таблица единиц измерения
Оценивают, сколько дней или рабочих часов займет выполнение задачи.
Нет точных единиц измерения. Задачи оценивают относительно одной самой маленькой и простой.
Примерная оценка задач по размерам условных маек — XS, S, M, L, XL.
Мы для примера будем оценивать задачу в рабочих часах.
Разработка главной страницы интернет-магазина
Озвучьте задачу
Когда известны все значения, озвучьте задачу для оценки, но не обсуждайте ее, пока все не выберут подходящую, по их мнению, карту. Если, например, разработчик выскажет свое мнение о задаче до начала голосования, остальные уже не смогут быть объективны, потому что станут ориентироваться на его оценку.
Дайте команде время подумать
Сколько времени дать — на ваше усмотрение, но не слишком много, чтобы не затягивать процесс. Поставьте таймер и сообщите команде, сколько есть времени. Когда оно вышло, все участники должны выбрать карту и положить ее на стол рубашкой вверх. Следите за синхронностью. Открыть карты можно, только когда решения приняли все, то есть карты всей команды лежат на столе.
Оцените результат
Откройте карты и оцените результат. Если все карты близки по значениям, команда оценила задачу примерно одинаково и можно на этом закончить. Что делать, когда есть контрастные различия? Например, два разработчика оценили задачу по-разному: Junior выбрал карту с номиналом 4, а Senior — 10.
Попросите каждого высказаться и выслушайте их аргументы. Вы и остальная команда поймете, почему они так считают. Например, Senior завысил цифру, чтобы получить больше времени, хотя может работать быстрее. А Junior недооценил сложность задачи по неопытности. Обычно реальность находится где-то посередине.
Если есть одна оценка, которая сильно отличается от остальных. Например, так:
Это значит, что QA ошибся или у него есть сведения, которых нет у остальных. Выслушайте его в первую очередь. А после обсуждения повторите голосование, уже ориентируясь на новые данные.
Повторите все сначала
Если все быстро договорились, а вы получили желаемый результат, то переходите к следующей задаче. Если нет, то продолжайте голосование, пока результат не получится однозначным. Ваша цель — среднее арифметическое от всех предложенных командой оценок.
Заключение
Теперь вы знаете, как оценивать задачи по методу Planning Poker. Чтобы делать все правильно, соблюдайте эти принципы.
Planning Poker помогает добиться объективной и точной оценки задач. Но, чтобы все работало, важно соблюдать правильную последовательность шагов. Вот чек-лист, который еще раз напомнит, что и когда делать. Держите его под рукой во время оценки, и тогда вы точно ничего не упустите.
Ни одна командная техника не работает без грамотного руководителя. Поэтому менеджер проекта должен уметь взаимодействовать с командой так, чтобы добиваться нужного результата.
Этому можно и нужно учиться: не обязательно получать психологическое образование, но и совсем забывать про soft skills не стоит. Выбирайте курсы с комплексным подходом к обучению, где уделяют внимание всем аспектам менеджерской работы.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Planning poker: заметки о первом впечатлении разработчика
Я, как и некоторые другие программисты, не большой любитель митингов. Порой, надоедают все эти sprint refinement, sprint review, retrospective сессии.
Частота проведения Planning Poker митингов
Я даже и не знала, что какие-то из наших команд практикуют Planning Poker. Дело в том, что у нас в проектах участники команд из двух офисов: голландского фронт-офиса и российского бэк-офиса. Использование Planning Poker-а для контента спринтов в наших условиях просто нереально. Для подобных сессий нужно собирать целую команду в одном месте и трудно это организовывать на регулярной основе. Поэтому команда проводит подобные сессии только для бэклога задач на несколько лет, некоторые из которых вообще кажутся безумными и нереальными для реализации, ну и задачи, требующие больше времени, чем менеджеры готовы дать на текущий момент времени. Для этих целей Planning poker просто идеален, на мой взгляд. Если у вас есть опыт использования Planning poker для распределенных команд без сбора всей команды в одной комнате, будет интересно ознакомиться, отпишитесь в комментариях.
Для каких команд было бы полезно использовать Planning Poker
Большие задачи разбиваются и оцениваются по отдельности
Большинство задач содержали как минимум 3 части, исходя из специфики проекта: software, firmware и собственно тесты. Для сложных систем из группы составляющих элементов оценка делалась для одного элемента.
Можно пригласить поучаствовать кого-то из другого проекта
При оценке сложности задачи бывают весьма полезны дополнительные вопросы новичков. Как вы поняли, для этой священной миссии пригласили меня. Дело в том, что незнающий человек может задать вопросы, которые также будут полезны в учете оценок членов команды. Я сама пару раз заметила, как после моего вопроса, некоторые люди сразу же начали искать другую карточку, хотя уже определились с оценкой.
Требуемое время для planning poker сессий
Подобные сессии требуют большие временные затраты. Время обсуждения каждого вопроса зависит от полноты предоставленных требований и понимания решения проблемы. Время на обсуждение вопроса может варьироваться от 5 до 30 минут. Так я принимала участие для обсуждения последней трети части бэклога задач. На это ушло полтора часа.
Итак, подведем итоги.
Все хорошо в меру. Planning poker сессии являются полезной деятельностью, но требуют много времени, так что я не считаю разумным проводить их очень часто, если только вы не располагаете свободным временем. Собирая такие митинги время от времени, вы будете поддерживать общую осведомленность в команде по разным частям проекта, что поможет улучшить процесс решения задач. А для кого-то может быть хорошей возможностью познакомиться с другими частями проекта на случай, если заскучаете работать со своей.
Planning Poker или White Elephant, что выбрать для оценки СЛОЖНОСТИ задач?
Всем привет! Меня зовут Сергей Титков я процессный менеджер в компании Ростелеком ИТ. В этой статье я хочу рассказать про две хорошие техники помогающие в планировании.
Введение
Планирование, на мой взгляд, один из самых сложных процессов разработки ПО. Причем большая часть сложности это наша когнитивная сложность, возникающая от того, что разработка софта очень вариативна. Даже просто само осознание вариативности уже само по себе сложно, а уж выстраивание пути проекта в условиях огромного количества рисков и вероятностей, сродни прокладыванию безопасных путей через имматериум. Поэтому всегда приятно, когда нам, что-либо, помогает в планировании и облегчает это весьма непростое дело.
Вот как раз о некоторых таких техниках, помогающих в планировании мы и поговорим. Не следует думать, что эти техники это все планирование. Эти техники малая часть подмножества техник планирования.
У рассматриваемых техник есть ограничения:
эти техники применимы для оценки сложности;
эти техники применимы для оценки полезности;
если их использовать для оценки трудоемкости, то вы получите крайне удручающую картину.
Что еще необходимо учитывать. Во время проведения сессий не фокусируйтесь только на том, что сложнее или проще. Очень важно общение и еще раз общение! Нащупывание путей решения проблемы, выявление и обсуждения подводных камней. Я бы очень рекомендовал, чтобы на сессиях оценки сложности присутствовал человек, который сам не участвует в дискуссии, но заносил бы в любом удобном виде, хоть списком, хоть майнд картой выявленные проблемы и предложенные пути решения. В пылу обсуждения многие моменты просто теряются и такая запись очень сильно поможет для подсвечивания найденных проблемных мест. Я знаю о чем подумали многие, давайте просто сделаем видеозапись, а потом из нее все вынем. Я бы крайне не рекомендовал такой подход, то что было на встрече, на ней и остается, наличие записи полностью убивает чувство защищенности и свободы.
Небольшое отступление.
В разработке программного обеспечения очень многие понятия обозначают, то чем они не являются. Для нашего примера это сложность, трудоемкость и время исполнения (за сколько сделаем) – очень часто считается, что это тождественные понятия и надо их измерять в человеко-днях. И это очень типичное заблуждение. Эти три понятия, в общем случае, очень мало, между собой связаны. Это разные фасеты. Точно также как “горячий”, “кислый”, “зеленый” тоже разные фасеты. Не надо путать тёплое с мягким, а трудоемкость с длительностью.
Разберем чуть подробнее.
Время исполнения (за сколько сделаем) – считается, что это то же самое, что и трудоемкость. Но это не так. Главное отличие состоит в том, что это не время которое мы потратили на задачу, а время, через которое мы можем сказать, да задача полностью выполнена. Наполнить наш бензовоз с помощью насоса можно, скажем за 1 час, и если все так просто. То через час + небольшой запас, мы можем сказать – да все готово. Но ситуация меняется когда надо наполнить бензовоз можно только, например, в присутствии комиссии, а собирается она раз в месяц. По факту наполнять мы его будем все тот же час, но поскольку нам ждать месяц, пока комиссия соберется, то время исполнения и будет месяц.
Покер планирования (Planning Poker)
Напомню, мы оцениваем СЛОЖНОСТЬ! И только ее! Суть ПП, заключается в том, что оцениваем то что нужно оценить в наших любимых относительных единицах – стори поинтах попугаях. Точность в виде крылышка нам не нужна. Поскольку это относительные единицы, то такая оценка уникальна для команды. Удав он 38 попугаев или 5 мартышек или 2 слона. Не забывайте об этом! Численные оценки должны использоваться для сравнения задач внутри команды, но никак для сравнения между командами.
Классическая колода для ПП содержит следующие карты с числам: 1, 1/2, 2, 3, 5, 8, 13, 20, 40, 100
Картинка взята из статьи википедии. Взяли числа Фибоначчи и немного изменили Оригинальные числа Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.
Рекомендованная колода
Числа
1, 3, 5, 8, 13, 21. Этого более чем достаточно. Двойка выкинута по рекомендации Паши Озолина, а он фигни плохого не посоветует. Дело в том, что люди часто спорят насчет того что 1, а что 2.
А про ½ вообще лучше промолчать.
Фигура Эшера
Мы вообще не понимаем как это можно сделать! Потенциальный черный лебедь. Отправляйте задачу на полный цикл анализа/постановки.
Тривиально
Просто сделать. Например, включить принтер.
Чай
Запрос на перерыв
Правила проведения сессии покерного планирования
Первое и самое важное!
Руководителя быть не должно.
Голосуем в темную. Исключаем подстройку под общее мнение. Каждый кладет карту перед собой и все вскрываются одновременно. После каждой сессии карты мешаются. Лучше под столом. Раскладывать карты нельзя.
Менее авторитетные участники говорят первыми. Первым говорит стажёр.
Первыми высказываются участники с наибольшим разбросом. Причем сначала высказывается тот у кого наименьший авторитет в команде.
Высказывания должны быть короткими:
идеально 1 – 2 минуты;
Оцениваем СЛОЖНОСТЬ, а не трудоемкость
Численные результаты НЕ ЗАПИСЫВАЕМ в протокол. Если записали, это стало трудочасами и тут вы потеряли производительность в полтора-два раза. Более детально почему так происходит отлично раскрыто у ДеМарко в военных играх.
Как проводим
Есть множество отличных статей и видео на тему КАК проводить сессию покерного планирования. В этой стать фокус сосредоточен на том, ЧТО нужно сделать и чему нужно следовать, чтобы сессия была успешной. Поэтому очень тезисно, как проводить:
говорим, что будем оценивать;
даем людям подумать не больше 5 минут;
вскрываемся 🙂 по правилам описанным выше;
проводим сессию торговли;
приходим к соглашению.
Что делаем с результатами?
После проведения сессии покерного планирования у нас есть следующие артефакты:
список того что оценивали с оценкой сложности;
список проблем и возможных их решений.
Со вторым понятно, анализируем и берем в работу. А с первым чуть сложнее. На основании цифр упорядочиваем список по возрастанию сложности, если у задач равная сложность, то можете, например случайным образом выбрать порядок. Далее у упорядоченного списка убираем численные значения и передаем на вход квадранту Кантора, о нем будет чуть ниже.
Белый слон (White Elephant)
Сам термин имеет негативную окраску, в общем случае это то, от чего невозможно избавиться и оно несет одни убытки, подробнее можно прочитать тут: Белый слон (идиома). К методу оценки сложности это разумеется не относится, метод весьма не плох. За популяризацию применения белого слона хочется сказать огромное спасибо Павлу Озолину
Суть метода. Мы оцениваем СЛОЖНОСТЬ задач друг относительно друга. Одна из задач будет всегда либо сложнее, либо проще, никаких цифр. Равной по сложности она быть не может. Выполнив таким образом ряд сравнений задач между собой мы получим список задач упорядоченных по сложности. Как это лучше всего сделать, приведено в примере ниже. Сложность задачи кодируется ее положением в списке. Напомню, что в случае покерного планирования возможна ситуация когда задачи будут иметь одинаковую сложность.
Правила
Случайным образом выбираем случайный элемент из тех что хотим оценить. И все остальные элементы сравниваем с ним. Элемент сложнее?
В общем случае получаем два множества:
К получившимся подмножествам применяем ровно такой же подход. Повторяем ровно до тех пор пока не получим список упорядоченный по возрастанию сложности. По сути это вариация на тему быстрой сортировки. Сложность метода n*Log(n).
При проведении торговли, какая задача проще, а какая сложнее необходимо придерживаться следующим правилам:
менее авторитетные участники говорят первыми;
аргументация почему нужно так расположить задачи должна быть краткой, до трех минут.
Помним, что мы проводим сессию оценки сложности для того чтобы нащупать проблемы и понять пути их решение, ни в коем случае не надо скатываться в выяснение отношений. Живое общение крутых профессионалов.
Пример
В качестве примера рассмотрим, что нам необходимо упорядочить по сложности эпики. Для визуализации удобно стикеры, если вы распределенная команда то онлайн доски ваш выбор.
Случайным образом выбираем первый элемент, с которым будем сравнивать все остальные. В нашем случае это EPIC 3.
Сравниваем EPIC 1 с EPIC 3
EPIC 1 проще или сложнее EPIC 3? Проводим сессию торговли. По результатам торгов решили, что EPIC 1 сложнее EPIC 3. Размещаем EPIC 1 правее EPIC 3
Проводим сравнение остальных эпиков с EPIC 3. В результате у нас получилась вот такая картина. В процессе торгов выяснилось что EPIC 5 проще чем EPIC 3 и более того он самый простой из всех эпиков. Для EPIC 5 и EPIC 3 процесс анализа сложности закончился.
Для эпиков 1, 2, 4 необходимо повторить процедуру сортировки. Выбираем новый опорный эпик для сравнения, пускай это будет EPIC 1
Проводим процедуру сравнение эпиков 2, 4 с ним. В результате проведения анализа, выяснилось, что оба эпика сложнее чем EPIC 1, результат представлен ниже на картинке.
Нам осталось выполнить сравнение двух оставшихся элементов: EPIC 2 и EPIC 4 и решить кто из них сложнее. В этом сравнение победил EPIC 4. Вот наш список эпиков отсортированный по сложности. Далее мы трансформируем его список работ, как это сделать будет описано ниже, в разделе про квадрант Кантора.
Сравнение покерного планирования и белого слона
Покер планирования
Белый слон
Требует меньше времени на большом количестве задач
Мало чувствителен к количеству задач. Растет как N.
Споров меньше, сессия торгов проходит быстрее
Нет цифр. Всегда однозначно.
Не чувствителен к присутствию руководства. Список всегда будет упорядоченным по сложности 🙂
Можно сразу заносить в джиру.
Много споров. Сессия торговли по каждой задачи идет дольше. Все постоянно фокусируются на числах.
Стал клише и слишком заезжен. Многие считают бесполезным.
Повышенные требования к обеспечению безопасности встречи.
Дает заблуждение об объеме работ за счет количественной оценки в “сторипойнтах”.
В таблице выше описаны плюсы и минусы каждой техники, выбирайте что вам подходит больше исходя из ваших условий. Приведу в каких случаях я выбираю покерное планирование, а в каких белого слона, курсивом выделены наиболее важные моменты
Покер планирование
Нужно оценить больше 10 элементов.
Могу обеспечить “безопасность” проведения сессии.
На уровне ощущения, что то упущено серьезное. Надо копнуть глубоко. Очень желательно запротоколировать все подсвеченные проблемы и варианты их решения.
Белый слон
Нужно оценить до 10 элементов.
То что нужно оценить являются абстрактными вещами. Например есть две задачи: описать политику качества для атрибута защищенность и описать политику качества для атрибута сопровождаемость.
Когда необходимо провести сессию быстро.
Сессия должна быть публичной.
Квадрант Кантора
Мало оценить сложность того что мы сделаем, нам надо это еще и доставить. Доставляем мы обычно пачками(релизами). Ниже будет описано в как определить последовательность реализации. Квадрант Кантора можно применять как для итерации, так и для всего проекта в целом. И это неудивительно, поскольку он является подмножеством универсальных матриц 2Х2. Более детальное описание можно найти в книге: Murray Cantor Object-Oriented Project Management with UML.
без этого не выпускаемся (если спринты упакованы по времени, то “то невыполнение этой задачи означает невыполнение цели спринта и как следствие его перезапуск”);
вполне может быть перенесена в следующий спринт
Квадрант Кантора для релиза/итерации, выполняем задачи по сиреневой стрелке, начинаем с левого верхнего квадранта, для каждого квадранта дано описание, почему следует выполнять работу в такой последовательности. Порядок следующий:
Без этого не выпускаемся + сложные(задачи берутся с хвоста списка).
По тому как решаются такие задачи можем сразу понять темп релиза….
Без этого не выпускаемся + простые
Делаем просто потому, что это надо обязательно делать.
Реализуем в следующий релиз + простые(задачи берутся с головы списка).
Стараемся сделать наверняка и побольше, выполняем обязательства.
Реализуем в следующий релиз + сложные
Обычно до этого квадранта дело уже не доходит.
Приведенная выше последовательность выполнения работ позволяет минимизировать неопределенность и как следствие митигировать риски, а также обеспечивает максимально правильное использование времени.