PBI против пользовательской истории

Недавно один из продуктов был добавлен в Журнал ожидания продукта владельцем, который говорит: «Когда я захожу на страницу входа со страницы x, я вижу ошибку. Я хочу, чтобы эта ошибка была удалена».

Мне кажется, что это не вариант использования и не должен быть PBI (Product Backlog Item). Однако, когда я обсуждал это, scrum master сказал мне, что пользовательские истории не являются PBI, а PBI может быть отчетом об ошибках, заданием, пользовательской историей, чем угодно, и буквально любым элементом, который должен быть адресован первым.

Я не уверен в этом. Также я не могу найти хорошее определение PBI в Интернете . Итак, мой вопрос: какие вещи могут попасть в Журнал незавершенного производства как элементы? Соответствует ли элемент бэклога продукта пользовательской истории? Они одинаковы?

Соответствует ли элемент бэклога продукта пользовательской истории? Они одинаковы?

Не обязательно, но в целом они делают. Как сказал ваш мастер схватки, другие вещи также могут быть отложенными. Тем не менее, это зависит от того, как работает ваш SCRUM. Некоторые команды имеют отдельный журнал ошибок, который учитывается и для спринтов, в то время как другие хранят такие вещи в журнале продуктов.

Из-за двух отдельных журналов владельцу продукта становится труднее определять приоритеты задач, поскольку теперь для следующего спринта необходимо учитывать два журнала. Но они предлагают лучший надзор, и оба могут быть расставлены приоритеты отдельно.

Итак, мой вопрос: какие вещи могут попасть в Журнал незавершенного производства как элементы?

Это может быть что угодно, что является частью видения продукта и пути к продукту, который вы хотите создать. Он в основном содержит требования (пользовательские истории), но также может содержать действия или технические элементы, которые не относятся непосредственно к продукту (например, «Купить новый сервер для команды разработчиков», «Создать рекламу для продукта»). Отставание должно избегать ненужных деталей и не должно пытаться управлять техническими вещами. Журнал ожидания продукта может содержать все, что обеспечивает ценность продукта.

Там не один настоящий Scrum. Иногда отдельные журналы являются лучшим способом управления продуктом, иногда они просто мешают. Узнайте, что работает для вас лучше всего.

Работая над ошибками, мы добавляем их в бэклог и называем их историями ошибок . Таким образом, добавляя исправления ошибок в отставание, становится ясно, что это не просто исправление ошибок. Мы можем добавить другие задачи, чтобы убедиться, что автоматизированные тесты написаны и проверка выполнена. Это также делает более ясным, что DoD следует соблюдать.

Мы никогда не использовали термин PBI (несмотря на то, что наш инструмент их так называет), это всегда пользовательские истории, истории ошибок или просто истории .

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

Все приведенные выше ответы не содержат ссылки на официальный исходный документ для платформы Scrum: Руководство по Scrum .

Резерв продукта

Есть раздел, описывающий Журнал ожидания продукта и элементы, часто называемые PBI, содержащиеся в нем.

Журнал ожидания продукта содержит список всех функций, функций, требований, улучшений и исправлений, которые представляют собой изменения, которые будут внесены в продукт в будущих выпусках.

Но не фиксируется как план проекта.

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

История пользователя

Термин « пользовательская история» никогда не появляется в The Scrum Guide, потому что

это структура, в которой вы можете использовать различные процессы и методы.

Использование пользовательской истории - это всего лишь один из возможных методов записи PBI.

ДОПОЛНИТЕЛЬНО: Хотя обычно встречается формат «Как, я хочу, чтобы», он может противоречить своему первоначальному замыслу . Этот проблемный формат также был рассмотрен на Agile 2017 .

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

Существует распространенное заблуждение, что в журнале работы продукта разрешены только пользовательские истории. Скрам, напротив, нейтрален по требованиям техники. Как утверждает Scrum Primer ,

Журнал незавершенного производства товаров четко и устойчиво сформулирован. Вопреки распространенному заблуждению, в Журнале ожидания продукта не содержится «пользовательских историй»; он просто содержит предметы. Эти элементы могут быть выражены в виде пользовательских историй, сценариев использования или любых других требований, которые группа сочтет полезными. Но какой бы ни был подход, большинство предметов должно быть сосредоточено на предоставлении ценности для клиентов. *

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

(Пользовательская) история - это полезный стандартный формат для элементов отставания. Это объясняется тем, что «если никто не заботится об этом, не тратьте на это время». Это также позволяет PO оценить срочность предмета, потому что он определяет, для кого вы будете его делать и насколько он плох.

В вашем случае ошибка может быть легко отформатирована как история.

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

Это звучит так, как будто стоит потраченных усилий.