PBI vs Історія користувачів

Нещодавно власник продукту до товарного блоку додав товар, який говорить "Коли я переходжу на сторінку входу з x сторінки, я бачу помилку. Я хочу, щоб цю помилку було видалено".

Мені здається, що це не випадок використання, і він не повинен бути PBI (товарний запас продукту). Однак, коли я обговорював це, майстер scrum сказав мені, що історії користувачів - це не PBI, і PBI може бути звітом про помилки, завданням, історією користувача, будь-яким, і буквально будь-яким елементом, який слід вирішити спочатку.

Я не впевнений у цьому. Крім того, я не можу знайти гарне визначення PBI в Інтернеті . Отже, моє запитання полягає в тому, які речі можуть потрапляти до Блоку товарів як товари? Чи відображається затримка продукту в історії користувача? Вони однакові?

Чи відображається затримка продукту в історії користувача? Вони однакові?

Не обов’язково, але в цілому вони роблять. Як сказав ваш майстер scrum, і інші речі можуть бути предметами відставання продукту. Однак це залежить від того, як працює ваш SCRUM. Деякі команди мають окремий відставання помилок, яке також враховується для спринтів, а інші зберігають такі речі у відставанні продукту.

Два окремі журнали ускладнюють власнику продукту пріоритетність завдань, оскільки тепер два журнали потрібно враховувати для наступного спринту. Але вони пропонують кращий нагляд, і обидва можуть мати пріоритет окремо.

Отже, моє запитання полягає в тому, які речі можуть потрапляти в Блокування товарів як товари?

Це може бути все, що є частиною продуктового бачення та подорожі до товару, який ви хочете створити. Він здебільшого містить вимоги (розповіді користувачів), але також може містити дії або технічні речі, які не належать безпосередньо продукту (наприклад, "Купуйте новий сервер для команди розробників", "Створіть рекламу для продукту"). Відставання повинно уникати необмежених деталей і не слід намагатись керувати технічними речами. Нестабільність продукту може містити все, що надає цінність продукту.

Немає єдиного справжнього Scrum. Іноді окремі відставання є кращим способом управління продуктом, іноді вони просто в дорозі. Дізнайтеся, що найкраще працює для вас.

Працюючи над помилками, ми додаємо їх до відстаючих і називаємо їх історіями помилок . Додавши виправлення помилок таким чином, відставання таким чином, зрозуміло, що це не просто виправлення помилок. Ми можемо додати інші завдання, щоб переконатися, що автоматичні тести написані та перевірка виконана. Це також робить більш очевидним, що слід дотримуватися DoD.

Ми ніколи не використовували термін PBI (навіть якщо наш інструмент відставання називає їх так), це завжди історії користувачів, історії помилок або просто просто історії .

Це в основному лише вибір термінології вашої команди, і поки вам все зрозуміло, що це, що насправді не має значення.

Усі вищезазначені відповіді не посилаються на авторитетний вихідний документ для рамки Scrum: Посібник з Scrum .

Блокування продукту

Існує розділ, що описує Записи продукту та елементи, які часто називають ПІІ, що містяться в ньому.

Записи продукту перераховують усі функції, функції, вимоги, удосконалення та виправлення, що є змінами, які слід внести до продукту в майбутніх випусках.

Але не фіксується як план проекту.

Нестабільність продукту розвивається в міру того, як продукт і середовище, в яких він буде використовуватися, розвиваються. Блокування продукту є динамічним; він постійно змінюється, щоб визначити, який товар повинен бути відповідним, конкурентоспроможним та корисним.

Історія користувача

Термін історія користувача ніколи не з’являється в Посібнику з Scrum, оскільки

це рамка, в рамках якої можна використовувати різні процеси та методи.

Використання історії користувача лише одна з можливих методик запису ПІІ.

ДОДАТКОВО: Хоча звичайно бачити формат "Як, я хочу, так що", це може суперечити його первинному наміру . Цей проблемний формат також був вирішений на Agile 2017 .

@Falcon це добре пояснив. Одна сторінка, яка має офіційне визначення, це: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog Те, що ви описали, не повинно розміщуватись у затримці продукту відповідно до цього опису.

Існує загальне непорозуміння, що в Блокуванні продуктів дозволено використовувати лише історії користувачів. Навпаки, Scrum нейтральний щодо вимог до технічних вимог. Як зазначає буквар Scrum ,

Продуктові затримки товарів сформульовані будь-яким зрозумілим та стійким способом. На відміну від поширених непорозумінь, Блокування продукту не містить "історій користувачів"; він просто містить елементи. Ці елементи можуть бути виражені у вигляді історій користувачів, випадків використання чи будь-яких інших вимог, які група вважає корисними. Але який би не був підхід, більшість предметів повинні зосереджуватися на наданні цінності клієнтам. *

• Розрізнені специфікації змін та доповнень до продукту називаються товарами продукту (PBI), які разом утворюють Блокування продукту.
• Кожна PBI описує те, що розробники можуть розробити та поставити для збільшення вартості відповідним зацікавленим сторонам після завершення (див. Визначення виконано).
• Найпоширенішим зацікавленим стороною є ринок, або його представник - Власник товару.
• Однак PBI може описати роботу, яка зменшує витрати для підприємства або зменшує зусилля для Команди розвитку, або інструмент, який допомагає Команді власників продукції краще виконувати свою роботу.
• PBI може описати все, що має потенційну цінність для зацікавлених осіб.

Історія (користувач) - це корисний стандартний формат для предметів відставання. Обґрунтування цього - «якщо про це ніхто не піклується, не витрачайте на це час». Це також дозволяє ОП оцінити терміновість предмета, оскільки він визначає, для кого ви будете це робити, і наскільки це погано.

У вашому випадку помилку можна легко відформатувати як історію.

• Як користувач
• Я хочу мати можливість увійти на сторінку X (а не отримати помилку замість цього)
• тому я не втрачу часу, роздратований і втрачу віру в продукт

Це здається, що варто докласти певних зусиль.