Embed Size (px)
Citation preview
Изменение sprint scope по средине разработки: кто виноват и что делать?
Давайте знакомиться ;)
Алена ПрихничCo-founder & trainer @ E5
Scrum Master @ Betlab
IC Agile certified professional
Прошла путь от сотрудника отдела поддержки до менеджера проектов и руководителя офиса. Проводжу тренинги по гибким
методологиям, менеджменту и мотивации.
Последний проект - открытие киевского офиса аутсорсинговой компании в Киеве.
А вы? ;)
Все как в жизни ;)
А что вообще происходит?
Product Owner хочет добавить в sprint новые user stories
Разработчик во время выяснения деталей с PO понимает, что размер user story больше, чем думали изначально
Тестировщики во время тестирования понимают, что размер user story больше, чем думали изначально
Product Owner хочет добавить в sprint новые user stories
Почему? У PO может быть
контракт/ внешние обезательства/ он кому-то что-то пообещал и забыл
PO не понимает/ ему все равно, что sprint scope нельзя менять
Совещание PO с бизнесом после вашего sprint planning и утверждения им sprint scope
Что делать? Выясняем почему РО хочет
добавить новые stories
Обьясняем последствия для sprint
Говорим «Нет» (без фанатизма)
Предлагаем варианты решения:
• Сделать это в следующем sprint• Выкинуть что-то в замен• Играемся с классикой проектного
менеджмента ;)
Resources Quality
Scope
Как предотвратить?
Просвещаем PO относительно Agile, Scrum etc.
Вовлекаем PO в планирование (делаем частью команды)
Показываем потери компании в у.е. от таких действий
Создаем и обновляем план релизов с разбивкой на спринты, делимся им с РО, бизнесом и всеми заинтересоваными
Делаем PBR до того как бизнес/ РО утвердили sprint scope
Разработчик во время выяснения деталей с PO понимает, что user story больше, чем он оценил
Почему?
Разработчик не вникал в суть истории во время планирования/ PBR
ВА не получил ответы на вопросы разработчиков
PO не предоставил всю информацию изначально
Что делать?
Оцениваем объем изменений
Вам повезло и доп. работа до нескольких часов
Вам не повезло... идем к РО с вариантами решения:• Сделать это в
следующем sprint• Выкинуть что-то в
замен• Опять этот
треугольник ;)
Resources Qua
lity
Scope
Как предотвратить? Мотивируем разработчиков
читать истории перед PBR
Договариваемся с РО о выделении на это времени
Пишем recaps & follow-ups на PBR
Добавляем вопросы в конкретные истории
Не берем историю без всей информации, используем definition of ready для story
Проводим двухуровневое планирование
Push PO на daily basis ;)
Тестировщики во время тестирования понимают, что user story больше, чем они оценили
Почему?
Тестировщики не вовлечены в планирование/ PBR/ эстимацию
Тестировщики не правильно оценили объем работы
Новые детали в результате лучшего понимания продукта
Что делать?
Да то же, что и в случае с разработчиком ;) Оцениваем объем изменений
Вам повезло и доп. работа до нескольких часов
Вам не повезло... идем к РО с вариантами решения:• Сделать это в
следующем sprint• Выкинуть что-то в
замен• Опять этот
треугольник ;)
Resources Qua
lity
Scope
Как предотвратить?
Мотивируем тестировщиков читать истории перед PBR
Добавляем в definition of story ready утверждение ее тестировщиками
Оценка истории тестировщиками – must have
Пишем тест кейсы в начале спринта
Обсуждаем тест кейсы с разработчиками
А как правильно?
2 weeks sprint
Team
Product Owner
Scrum master
Sprint backlog
Sprint Planning
Daily Stand up
Sprint ReviewRetrospective
Epic grooming
Storygrooming
PBR – Product Backlog Refinement
1.Чтение2.Вопросы3.Предварительная оценка4.Предварительный выбор команды
1. Все вопросы отвечены
2. Детали реализации готовы
(wireframes, mockups,
scenarios)
3. Приоритеты выставлены
4. Четкое понимание
1. Мелкие уточнения
2. Проблемы?
1. Понимание scope следующего спринта2. Оформление доработок
Расставляем акценты
Обучаем команду
Обучаем команду Agile
Они должны уметь “push back” PO ;)
Понять и помочь ;)
1)Ищем причины изменения sprint scope
2)Помогаем их устранить
А что дальше?
Product Development Mindset
