View source for 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 рассматривался как гипотеза и команда имела четкое понимание как применить факт как подтверждения, так и опровержения этой гипотезы.

[[Category:Product Owner (курс)]]