Product Owner є певною єднальною ланкою між замовником і командою розробки. Остаточна інстанція щодо прийняття рішень в Scrum Team - це якраз і є Product Owner
Найголовніша відповідальність Product Owner - це створення і контроль Product Backlog
Основні обов'язки та відповідальність Product Owner при управлінні Product Backlog:
- Визначення елементів беклога продукту;
- Правильне розташування елементів для оптимізації досягнення мети;
- Забезпечення зрозумілості і прозорості Product Backlog;
- Забезпечення прозорості та зрозумілості вимог, над якими належить працювати всій Scrum Team;
- Загальна оптимізація для досягнення найбільшої цінності роботи Development Team;
- Відповідальність за розуміння беклога командою розробки.
Варто відзначити, що Product Owner може сам виконувати всі перераховані вище обов'язки, а може віддати їх на виконання Development Team, проте завжди залишається відповідальним.
Рішення Product Owner по виконанню тих чи інших завдань повинні виконуватися. Всі свої рішення, Власник Продукту транслює через той Product Backlog, який виходить. Важливо при цьому пам'ятати, що впливати на саму роботу Development Team він не може і часом навіть не присутня на планування, наприклад, на Scrum Planning Meeting. проте він завжди повинен знаходитися поруч, щоб у разі виникнення питань, їх можна було оперативно вирішити.
Життя Product Owner всередині Scrum Team
Для Product Owner важливо писати завдання не з боку того ж програмування, а з боку вимог замовника - «хотелок». Наприклад, система вибірки журналу працює повільно, хотілося б швидше. Якщо Product Owner напише - Провести оптимізацію бази даних, то це неправильний підхід. Адже проблема може бути і не в базі даних, або не тільки в ній. Тому опис всіх завдань йде простою мовою, наприклад, прискорити видачу журналу. Для ідей вирішення проблем, Product Owner (та й будь-який інший) є поле Примітка в Product Backlog.
Власник товару не може обмежити себе тільки складанням списку того, що йому потрібно, адже взаємодія з командою веде до більш кращою і ефективній роботі.
Повертаючись до того ж Planning Meeting, можна часто помітити, що як би не намагався Product Owner в заповненні Product Backlog, завжди з'являються спірні моменти. Найголовніша проблема - переоцінка Story Points. Product Owner часом не може передбачити всіх технічних аспектів тієї чи іншої дії (та й не повинен), і даючи завдання, він може не передбачити будь то далеких складних взаємозв'язків, які збільшують термін виконання роботи в кілька разів. В такому випадку відбувається перегляд оцінок цього завдання, а це може вплинути на вихід загальної кількості Story Points за межі можливостей команди, які оцінені за Velocity.
Product Owner потрібен не тільки на початковому етапі, як може здатися, але і протягом усього Sprint. Взаємозв'язок з командою правда проходить тільки одностороння - команда в міру виникнення питань вправі залучати Product Owner. Найчастіше відбувається так, що час, необхідний для залучення Product Owner залежить від загального часу, проведеного з командою. Про таке кажуть: «Команда дозріває для запитань до Product Owner»
Також важливим обов'язком Product Owner є зупинка спринту. У статті Abnormal Termination / Зупинка спринту докладно описано цю дію.
Scrum Team
Головний діючий єдиний організм, який всіма силами намагається не допустити появи такої неприємної ситуації як Зупинка спринту / Abnormal Termination і виконує всю роботу.
Product Backlog
Основний список всіх завдань, в якому зібрано все, що має бути зроблено команді протягом декількох спринтів. З нього завдання переносяться в Sprint Backlog.
Development Team
Двигун Scrum Team. Команда розробників працює як злагоджена футбольна або будь-яка інша команда. На їхньому полі гри (битви) - їм ніколи ніхто не заважає, а лише допомагає. Основний їх помічник - Scrum Master.
Sprint Planning Meeting
Дуже важливо і відповідальний захід в методології Scrum, яке безпосередньо буде впливати на всю роботу в майбутньому. Stakeholders можуть відвідувати цей захід.
Story Points
Щоб чітко розуміти як формується Velocity в Scrum, потрібно розуміти як грамотно оцінювати Story Points. Дане розуміння призводить до розвитку максимально продуктивною команди.
Оцінка Story Points, а точніше їх кількість, в глобальному масштабі відбувається за допомогою Velocity. Та швидкість, яку розвиває команда за формулою розраховується в даному графіку.
Sprint Backlog
Те що потрапило з Product Backlog в Sprint Backlog і буде набором завдань на поточний Sprint. Sprint Backlog - вкрай продумана річ, яка дозволяє виконати саме ті завдання за ітерацію, які створять робочий продукт.
Scrum Sprint
Мабуть основний процес в методології Scrum, зупинка якого і може статися. Під час Sprint відбувається вся робота Development Team, Scrum Master і Product Owner.