11.04.2015 Одесса. Impact Hub Odessa. Конференция PMLab. Алена Прихнич (Senior Scrum Master, E5) “Изменение Scope спринта посередине разработки” Мы поделимся нашим опытом и постараемся ответить на вопрос: почему заказчик меняет спринт Scope посередине спринта,как убедить заказчика не делать это,как научить команду не поддаваться на угрозы и мольбы заказчика, что делать самому, чтобы избежать подобных ситуаций? Подробнее: http://geekslab.co/ https://www.facebook.com/GeeksLab.co https://www.youtube.com/user/GeeksLabVideo

1. Изменение sprint scope по средине разработки:
кто виноват и что делать?

2. Давайте знакомиться ;)
Алена Прихнич
Co-founder & trainer @ E5
Agile Project manager @ Ciklum
IC Agile certified professional
Прошла путь от сотрудника отдела поддержки до менеджера
проектов и руководителя офиса. Проводжу тренинги по гибким
методологиям, менеджменту и мотивации.
Последний проект - открытие киевского офиса аутсорсинговой
компании в Киеве.

3. А вы? ;)

4. Все как в жизни ;)

5. А что вообще происходит?
 Product Owner хочет
добавить в sprint новые
user stories
 Разработчик во время
выяснения деталей с PO
понимает, что размер
user story больше, чем
думали изначально
 Тестировщики во время
тестирования понимают,
что размер user story
больше, чем думали
изначально

6. Product Owner хочет добавить в
sprint новые user stories

7. Почему?
 У PO может быть
контракт/ внешние
обезательства/ он кому-
то что-то пообещал и
забыл
 PO не понимает/ ему все
равно, что sprint scope
нельзя менять
 Совещание PO с
бизнесом после вашего
sprint planning и
утверждения им sprint
scope

8. Что делать?
 Выясняем почему РО хочет
добавить новые stories
 Обьясняем последствия для
sprint
 Говорим «Нет» (без фанатизма)
 Предлагаем варианты решения:
• Сделать это в следующем sprint
• Выкинуть что-то в замен
• Играемся с классикой проектного
менеджмента ;)
Resources
Quality
Scope

9. Как предотвратить?
 Просвещаем PO относительно
Agile, Scrum etc.
 Вовлекаем PO в планирование
(делаем частью команды)
 Показываем потери компании в
у.е. от таких действий
 Создаем и обновляем план
релизов с разбивкой на спринты,
делимся им с РО, бизнесом и
всеми заинтересоваными
 Делаем PBR до того как бизнес/
РО утвердили sprint scope

10. Разработчик во время выяснения деталей с PO
понимает, что user story больше, чем он оценил

11. Почему?
 Разработчик не вникал
в суть истории во
время планирования/
PBR
 ВА не получил ответы
на вопросы
разработчиков
 PO не предоставил
всю информацию
изначально

12. Что делать?
Оцениваем объем изменений
 Вам повезло и доп. работа
до нескольких часов
 Вам не повезло...
идем к РО с вариантами
решения:
• Сделать это в
следующем sprint
• Выкинуть что-то в замен
• Опять этот треугольник ;)
Resources
Q
uality
Scope

13. Как предотвратить?
 Мотивируем разработчиков читать
истории перед PBR
 Договариваемся с РО о выделении
на это времени
 Пишем recaps & follow-ups на PBR
 Добавляем вопросы в конкретные
истории
 Не берем историю без всей
информации, используем definition
of ready для story
 Проводим двухуровневое
планирование
 Push PO на daily basis ;)

14. Тестировщики во время тестирования понимают,
что user story больше, чем они оценили

15. Почему?
 Тестировщики не
вовлечены в
планирование/ PBR/
эстимацию
 Тестировщики не
правильно оценили объем
работы
 Новые детали в результате
лучшего понимания
продукта

16. Что делать?
Да то же, что и в случае с
разработчиком ;)
Оцениваем объем изменений
 Вам повезло и доп. работа
до нескольких часов
 Вам не повезло...
идем к РО с вариантами
решения:
• Сделать это в
следующем sprint
• Выкинуть что-то в замен
• Опять этот треугольник ;)
Resources
Q
uality
Scope

17. Как предотвратить?
 Мотивируем тестировщиков
читать истории перед PBR
 Добавляем в definition of story
ready утверждение ее
тестировщиками
 Оценка истории
тестировщиками – must have
 Пишем тест кейсы в начале
спринта
 Обсуждаем тест кейсы с
разработчиками

18. А как правильно?

19. 2 weeks sprint
Team
Product
Owner
Scrum
master
Sprint
backlog
Sprint
Planning
Daily
Stand up
Sprint Review
Retrospective
Epic
grooming
Story
grooming
PBR – Product Backlog
Refinement
1.Чтение
2.Вопросы
3.Предварительная оценка
4.Предварительный выбор
команды
1. Все вопросы отвечены
2. Детали реализации готовы
(wireframes, mockups,
scenarios)
3. Приоритеты выставлены
4. Четкое понимание
1. Мелкие уточнения
2. Проблемы?
1. Понимание scopeследующего спринта2. Оформление
доработок
Расставляем акценты

20. Обучаем команду
 Обучаем команду
Agile
 Они должны уметь
“push back” PO ;)

21. Понять и помочь ;)
1) Ищем причины
изменения sprint
scope
2)Помогаем их
устранить

22. А что дальше?
Product Development Mindset

23. Спасибо за внимание!
helen@e-5.com.ua
E5Trainings
E5Trainings
E5
www.e-5.com.ua