Что должно быть перед каждым Sprint?

Что должно быть перед каждым Sprint

Это один из ключевых вопросов в agile процессе. Хороший sprint начинается до того, как он начинается. Вот что я делаю:

1. Проработанный Backlog

User Stories с высокой четкостью — каждая story, которая попадет в sprint, должна быть четко описана:

• Что нужно сделать (title)
• Почему это нужно сделать (business value)
• Как это выглядит (acceptance criteria)
• Примеры и edge cases

Я НЕ даю в sprint story, которая звучит как "Fix the thing". Stories должны быть конкретны.

Acceptance Criteria — это must have. Разработчик должен точно знать, когда story готова. Примеры хороших AC:

Given пользователь на странице профиля
When он нажимает кнопку "Изменить пароль"
Then открывается форма изменения пароля с полями "Старый пароль" и "Новый пароль"
And кнопка "Сохранить" неактивна до заполнения обоих полей
And система показывает ошибку если пароли не совпадают в требуемых критериях

Оценки — каждая story должна быть оценена (story points, t-shirt sizing или часы). Если story слишком большая (больше 13 points), ее нужно разбить.

2. Dependency Mapping

Я проверяю, какие stories зависят друг от друга:

• Story A зависит от Story B?
• Есть ли внешние dependencies (API от другой команды, дизайн от дизайнера)?
• Все ли dependencies готовы?

Это предотвращает ситуацию, когда разработчик сидит и ждет, потому что блокирован другой story.

3. Spike stories и исследования

Если sprint будет содержать новую технологию или неясный aspect, я уже должен был провести spike в предыдущем sprint или даже раньше.

Spike это short investigation, которая дает нам уверенность в том, как решить проблему.

4. UX/Design готовность

Дизайны одобрены — не должно быть active discussions о том, как выглядеть features. Это должно быть решено до sprint.

Макеты или прототипы — особенно для сложного UI, я должен иметь designs или прототипы, которые показывают, как это будет работать.

Утверждение от заказчика — если дизайн критичен для business, заказчик должен его валидировать.

5. Данные для тестирования

Test data и fixtures готовы — если team нужны специфичные данные для тестирования, они должны быть созданы перед спринтом.

Staging окружение — если используется staging, оно должно быть свежим и отражать production.

6. Требования к интеграциям и API

Если stories требуют интеграции:

• Я должен имеет API документацию
• Договоренность с другой командой о timeline
• Тестовый доступ если это external API

7. Clarity на определении Ready

Team должна понимать, что значит story "Ready" для sprint:

• Story описана с достаточным деталем
• Acceptance criteria ясны
• Нет неясностей
• Оценка дана
• Dependencies понятны
• Design готов (если нужен)

Это что-то вроде Definition of Ready для вашей team.

8. Planning документ

Перед sprint planning meeting я подготавливаю:

• Приоритизированный список stories
• Обоснование приоритизации
• Estimation notes если были сложности
• Риски и dependencies

Это помогает meeting быть более эффективным и решать реальные вопросы, а не выяснять базовые детали.

9. Stakeholder alignment

Лучше всего провести mini-alignment meeting перед sprint с key stakeholder'ами, где мы согласуем:

• Какие features будут в sprint
• Какие будут исключены из scope
• Зависимости и риски
• Timeline для feedback и approvals

10. Инструменты и конфигурация

Jira (или другой tracking tool) должна быть чистой и правильно структурирована:

• Все stories в нужном epic'е
• Точки добавлены
• Labels корректно установлены
• Links установлены для dependencies

Типичная timeline

Sprint N-1:

• Сбор требований
• Обсуждение с заказчиком

Sprint N:

• Написание и уточнение stories
• Design review
• Estimation
• Planning meeting
• Execution

Sprint N+1:

• Уже готовим stories для Sprint N+2

Что происходит если не подготовить

Я видел спринты, которые начинались с неясными требованиями:

• Много meetings во время sprint для уточнения
• Разработчики пишут code на неясных требованиях
• Рework когда требования наконец приходят в ясность
• Team деморализирована
• Velocity нестабильна

Моя позиция

Business Analyst должна убедиться, что team входит в sprint с высокой четкостью требований и низким уровнем амбигуфити. Это позволяет team сфокусироваться на качественной разработке, а не на расшифровке requirements.

Good sprint это результат хорошей подготовки до sprint.