PO - 04 - Product Backlog

Цель: - Понять что такое product backlog - Понять за что отвечает PO

Тезисы:

Scrum Guide говорит по Product Backlog (PB) только то, что это упорядоченный список улучшений в продукте который является единственным источником для работы Scrum Team.

Это НЕ означает что PO может организовать PB совсем как угодно. Что бы это понять надо вспомнить о том, что Scrum основан на эмпирицизиме и держится на трех столпах - прозрачности, инспекции и адаптации для того, чтобы реализовать эмпирический подход. Это относится ко всем артефактам, ролям и действиям в скраме.

Как PB может поддержать прозрачность?

Что бы PB был прозрачным - результат выполнения PB должен быть измеримым, т.е. должен быть определен и способ измерения, и конкретные параметры с которыми можно будет сравнивать.

Примерами могут быть рабочий сценарий (пройден/нет) и/или технические характеристики (например скорость ответа или использование ресурсов)

Как PB может поддержать инспекцию?

Что PB можно было инспектировать - он должен быть готов к инспекции к совершенно конкретный момент - не позднее Review. PO может обеспечить это создавая PBI достаточно маленькие, чтобы команда могла их done в рамках спринта.

Как PB может поддержкать адаптацию?

Адаптация PB происходит на ревью в рамках обсуждения со stakeholders и получения обратной связи. Для того, что бы stakeholders были заинтересованы - PBI должны поставлять конкретную бизнес-ценность для конкретных stakeholders

Есть множество способов это обеспечить - INVEST, user stories, RUP-style use cases/scenarios, для нас важно что простое понимание колон Scrum позволило расширить простую формулировку "единственный источник работы" до четких требований к тому, какой должен быть Product Backlog.

Ну и для того, чтобы поддерживать эмпирицизм - нам нужно понимание что каждый PBI рассматривался как гипотеза и команда имела четкое понимание как применить факт как подтверждения, так и опровержения этой гипотезы.