Webinar requirements management

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

Prykhnych Helen & Sakharov Roman @ E5

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

Алена Прихнич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 больше, чем думали изначально

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

1. Все вопросы отвечены

2. Детали реализации готовы

(wireframes, mockups,

scenarios)

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

4. Четкое понимание

1. Мелкие уточнения

2. Проблемы?

1. Понимание scope

следующего спринта

2. Оформление доработок

PBR – Product Backlog Refinement

1.Вычитка2.Вопросы3.Предварительная оценка

4.Предварительный выбор

команды

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

Почему?

У PO может быть контракт/внешние обезательства/он кому-то что-то пообещал и забыл

PO не понимает/ему все равно, что sprint scope нельзя менять

Совещание PO с бизнесом после вашего sprint planning и утверждения им sprint scope

Что делать?

Выясняем почему РО хочет добавить новые stories

Обьясняем последствия для sprint

Предлагаем варианты решения: Сделать это в следующем

sprint Выкинуть что-то в замен Играемся с классикой

проектного менеджмента ;)

Resources Quality

Scope

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

Просвещаем PO относительно Agile, Scrum etc.

Показываем потери компании в у.е. от таких действий

Создаем и обновляем план релизов с разбивкой на спринты, делимся им с РО, бизнесом и всеми заинтересоваными

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

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

Почему?

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

ВА не получил ответы на вопросы разработчиков

PO не предоставил всю информацию изначально

Что делать?

Re-estimation of stories Вам повезло и доп. работа до

нескольких часов Вам не повезло – идем к РО с

вариантами решения: Сделать это в следующем

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

Resources Quality

Scope

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

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

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

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

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

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

Push PO на daily basis ;)

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

Почему?

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

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

Что делать?

Re-estimation of stories Вам повезло и доп. работа до

нескольких часов Вам не повезло – идем к РО с

вариантами решения: Сделать это в следующем

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

Resources Quality

Scope

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

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

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

Добавляем в definition of story ready утверждение ее тестировщиками

Оценка истории тестировщиками – must have

Пишем тест кейсы в начале спринта

Обсуждаем тест кейсы с разработчиками

Обучаем команду

Обучаем команду Agile

Они должны уметь push back PO ;)

Понять и помочь ;)

1) Ищем причины изменения sprint scope

2) Помогаем их устранить

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

Welcome на наш workshop“Управление

требованиями на Agile проектах: от идеи к

работающему продукту”12 июля с 11:00 до 17:00

А также!

Odessa Web Camp 21-24 Июля!Наш доклад: Управление требованиями в Agile: как это происходит в реальном миреНаш воркшоп: по Управлению требованиямии скидка 10% по промо-коду E5Trainings

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

Будем рады видеть вас 12 июля Workshop «Управление требованиями на проекте: от идеи к работаюшему продукту»10 и 29 июля ITKaiZenClub – встреча сообщества менеджеров в Киеве [email protected] E5Trainings E5Trainings E5 www.e-5.com.ua