Роман Сахаров "Зміна Scope спринту посередині...

Зміна Scope спринту посередині розробки: хто винен і що робити?

Sakharov Roman @ E5

Давайте знайомитись ;)

Роман СахаровLead Business Analyst & Resource manager @ EPAM SystemsCertified Scrum Master, Trainer Пройшов шлях від бізнес аналітика до resource менеджера, успішно впроваджую процеси і проводжу тренінги в EPAM Systems по гнучкими методологіями розробки та бізнес аналізу. Створюю власні тренінги.

Ситуація…

- У мене нова геніальна фіча, давай робити!

…

- Що?.. Середина спринту? Ну і що, фіча ж мега-важлива! Робіть ВЖЕ!

А що, власне, відбувається?

Product Owner хоче додати в sprint нові user stories

Розробник під час роботи розуміє, що user story більше, ніж думали спочатку

Тестувальники під час тестування / написання тест кейсів розуміють, що у user story потрібно зробити більше, ніж вважали розробники

Product Owner хоче додати в sprint нові user stories

Чому?

Нові ідеї, які здаються Product Owner терміновими (або такими і є)

PO не розуміє / йому все одно, що sprint scope не можна змінювати

Мітинг PO з бізнесом після вашого sprint planning та затвердження їм sprint scope

Що робити?

1. З'ясовуємо чому РО хоче додати нові Stories

2. Пояснюємо наслідки для Sprint-у

3. Кажемо «Ні» (без фанатизму)

4. Пропонуємо варіанти вирішення:

1. Зробити це в наступному sprint 2. Прибрати щось на замін 3. Граємося з класикою проектного

менеджменту ;)

Resources Quality

Scope

Як попередити?

Навчаємо Product Owner Agile, Scrum

Задіюємо PO в плануванні (робимо частиною команди)

Показуємо втрати компанії в у.о. внаслідок таких дій

Створюємо і оновлюємо план релізів з розбивкою на спринти, зі всіма зацікавленими

Робимо PBR до того як бізнес / РО затвердили sprint scope

Розробник розуміє, що user story більша, ніж думали спочатку

Чому?

Розробник не вникав в суть історії під час планування / PBR

Технічна складність виявилась вищою при розробці

PO не надав всю інформацію спочатку і не відповів на уточнюючі питання

Що робити?

1. Оцінюємо об’єм змін

2. Вам пощастило і ви встигаєте (happy end)

3. Вам не пощастило… ідемо до РО з варіантами рішень:

1. Виділити це в окрему історію

2. І знову цей трикутник ;)

Resources Quality

Scope

Як попередити?

Мотивуємо розробників читати історії перед PBR

Домовляємося з РО про виділення часу на дослідження

Пишемо recaps & follow-ups на PBR та додаємо питання в конкретні історії

Не беремо історію без всієї інформації, використовуємо definition of ready для story

Проводимо дворівневе планування

Тестувальники виявляють, що user story більше, ніж думали спочатку

Чому?

Тестувальники не залучені в планування / PBR / естімацію

Тестувальники неправильно оцінили обсяг роботи

Нові деталі внаслідок кращого розуміння продукту

Що робити?

Загалом те ж що і у випадку розробника…

1.Оцінюємо об’єм змін

2.Вам пощастило і ви встигаєте (happy end)

3.Вам не пощастило… ідемо до РО з варіантами рішень:

1. Виділити це в окрему історію

2. Знову цей трикутник;)

Як попередити?

Мотивуємо тестувальників читати історії перед PBR

Додаємо в definition of story ready затвердження її тестувальниками

Оцінка історії тестувальниками - must have

Пишемо тест кейси на початку спринту

Обговорюємо тест кейси з розробниками

То як правильно?

1. Всі відповіді надані

2. Деталі реалізації готові

(wireframes, mockups,

scenarios)

3. Пріоритети виставлені

4. Чітке розуміння

1. Дрібні уточнення

2. Проблеми?

1. Розуміння scope наступного спринту 2. Оформлення доопрацювань

PBR – Product Backlog Refinement

1.Вичитка 2.Запитання 3.Попередня оцінка 4.Попередній вибір команди

Навчаємо команду

Навчаємо команду Agile

Вони повинні вміти push back PO;)

Зрозуміти і допомогти ;)

1) Шукаємо причини зміни sprint scope

2) Допомагаємо їх усунути

Плани на вересень ;)

Workshops Workshops

• Kanban 14/09Kanban 14/09

• Communication with Communication with client 27/09 client 27/09

ITKaiZenClubITKaiZenClub

Webinars Webinars

• Типові помилки в Типові помилки в комунікації з комунікації з клієнтами 23/09клієнтами 23/09

• Scrum VS Kanban: Scrum VS Kanban: Kanban wins? Kanban wins? 004/094/09

Дякую за увагу!

info@e-5.com.ua

E5Trainings

E5Trainings E5 www.e-5.com.ua