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

Prykhnych Helen & Sakharov Roman @ E5

Before starting

#ITKaiZenClub@E5Trainings

WiFi Pass: welcome2cgn

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

Алена ПрихничCo-founder & trainer @ E5

IC Agile certified professionalПрошла путь от сотрудника отдела поддержки до менеджера проектов и руководителя офиса. Проводжу тренинги по гибким методологиям, менеджменту и мотивации.

Последний проект - открытие киевского офиса аутсорсинговой компании в Киеве.

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

А вы? ;)

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

А что вообще происходит?

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 Quality

Scope

Как предотвратить?

Мотивируем разработчиков читать истории перед PBR

Договариваемся с РО о выделении на это времени

Пишем recaps & follow-ups на PBR

Добавляем вопросы в конкретные истории

Не берем историю без всей информации, используем definition of ready для story

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

Push PO на daily basis ;)

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

Почему?

Тестировщики не вовлечены в планирование/ PBR/эстимацию

Тестировщики не правильно оценили объем работы

Новые детали в результате лучшего понимания продукта

Что делать?

Resources Quality

Scope

Да то же, что и в случае с разработчиком ;) Оцениваем объем изменений

Вам повезло и доп. работа до нескольких часов

Вам не повезло... идем к РО с вариантами решения: Сделать это в

следующем sprint Выкинуть что-то в замен Опять этот треугольник ;)

Как предотвратить?

Мотивируем тестировщиков читать истории перед 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) Помогаем их устранить

Хотите узнать больше?

Welcome на наш Workshop «Kanban: stop staring, start

finishing!» 14 сентября 11:00 до

18:00

Планы на осень

Workshops

• Kanban 14/09

• Communication with client 27/09

ITKaiZenClub 21/10

Webinars

• Типичные ошибки в коммуникации с клиентами 23/09

Спасибо за внимание!

info@e-5.com.ua

E5Trainings

E5TrainingsE5www.e-5.com.ua