PBI vs Historia del usuario

Recientemente, el propietario del producto ha agregado un elemento al Backlog del producto que dice "Cuando voy a la página de inicio de sesión desde la página x, veo un error. Quiero que se elimine ese error".

Me parece que este no es un caso de uso, y no debería ser un PBI (Producto de la Lista de Producto). Sin embargo, cuando lo discutí, scrum master me dijo que las historias de usuarios no son PBI y, un PBI podría ser un informe de error, una tarea, una historia de usuario, cualquier cosa y, literalmente, cualquier elemento que deba abordarse primero.

No estoy seguro de esto. Además, no puedo encontrar una buena definición de PBI en la web . Entonces, mi pregunta es, ¿qué tipo de cosas pueden entrar en la cartera de productos como elementos? ¿Un elemento de la cartera de pedidos del producto se asigna a una historia de usuario? ¿Son lo mismo?

¿Un elemento de la cartera de pedidos del producto se asigna a una historia de usuario? ¿Son lo mismo?

No necesariamente, pero en general, lo hacen. Como dijo su scrum master, otras cosas también pueden ser elementos de la cartera de productos. Sin embargo, depende de cómo funcione su SCRUM. Algunos equipos tienen una acumulación de errores por separado que también se tiene en cuenta para los sprints, mientras que otros mantienen esas cosas en la cartera de productos.

Dos registros separados hacen que sea más difícil para el propietario del producto priorizar tareas, ya que ahora se deben tener en cuenta dos registros para el próximo sprint. Pero sí ofrecen una mejor supervisión y ambos pueden priorizarse por separado.

Entonces, mi pregunta es, ¿qué tipo de cosas pueden entrar en la cartera de productos como elementos?

Esto puede ser cualquier cosa que sea parte de la visión del producto y el viaje hacia el producto que desea crear. En su mayoría contiene requisitos (historias de usuarios) pero también puede contener acciones o elementos técnicos que no pertenecen directamente al producto (por ejemplo, "Comprar un nuevo servidor para el equipo de desarrollo", "Crear publicidad para el producto"). El trabajo atrasado debe evitar detalles innecesarios y no debe tratar de gestionar las cosas técnicas. La acumulación de productos puede contener cualquier cosa que ofrezca valor al producto.

No existe el único Scrum verdadero. A veces, los trabajos atrasados ​​separados son una mejor manera de administrar el producto, a veces solo están en el camino. Descubra lo que funciona mejor para usted.

Cuando trabajamos en errores, los agregamos a la cartera de pedidos y los llamamos historias de errores . Al agregar correcciones de errores al trabajo acumulado de esta manera, queda claro que no es solo la corrección de errores. Podemos agregar otras tareas para asegurarnos de que las pruebas automatizadas se escriban y se realice la verificación. También hace más explícito que se debe seguir el DoD.

Nunca hemos usado el término PBI (aunque nuestra herramienta de registro de pedidos los llama así), siempre son historias de usuarios, historias de errores o simplemente historias .

Es principalmente la elección de la terminología de su equipo y siempre que tenga claro qué es lo que realmente no importa.

Todas las respuestas anteriores no hacen referencia al documento fuente autorizado para el marco de Scrum: la Guía de Scrum .

Pila de Producto

Hay una sección que describe la cartera de pedidos del producto y los elementos, a menudo denominados PBI, contenidos en ella.

El Backlog del producto enumera todas las características, funciones, requisitos, mejoras y correcciones que constituyen los cambios que se realizarán en el producto en futuras versiones.

Pero no se arregla como un plan de proyecto.

La cartera de productos evoluciona a medida que evoluciona el producto y el entorno en el que se utilizará. La cartera de productos es dinámica; cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil.

Historia del usuario

El término historia de usuario nunca aparece en The Scrum Guide porque

Es un marco dentro del cual puede emplear diversos procesos y técnicas.

Usar una historia de usuario es solo una técnica posible para registrar los PBI.

ADICIONALMENTE: Aunque es común ver el formato "As a, I want, So that", puede ser contrario a su intención original . Este formato problemático también se abordó en Agile 2017 .

@Falcon lo ha explicado bien. Una página que tiene una definición formal es: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog Lo que ha descrito no se debe colocar en la cartera de productos al menos de acuerdo con esa descripción.

Existe un malentendido común de que solo las historias de usuarios están permitidas en una Cartera de productos. Por el contrario, Scrum es neutral en las técnicas de requisitos. Como dice el Scrum Primer ,

Producto Backlog Los artículos se articulan de manera clara y sostenible. Contrariamente a los malentendidos populares, la cartera de productos no contiene "historias de usuarios"; Simplemente contiene artículos. Esos elementos pueden expresarse como historias de usuarios, casos de uso o cualquier otro enfoque de requisitos que el grupo considere útil. Pero sea cual sea el enfoque, la mayoría de los artículos deberían centrarse en entregar valor a los clientes. *

• Las especificaciones distintivas de cambios y adiciones al producto, se denominan Elementos de la Lista de Producto (PBI), que juntas forman la Lista de Producto.
• Cada PBI describe algo que los Desarrolladores pueden desarrollar y entregar para agregar valor a las partes interesadas relevantes cuando se hace (ver Definición de Hecho).
• La parte interesada más común es el mercado, o su representante, el propietario del producto.
• Sin embargo, un PBI puede describir el trabajo que reduce el costo para la empresa o el esfuerzo para el Equipo de Desarrollo, o una herramienta que ayuda al Equipo del Propietario del Producto a hacer mejor su trabajo.
• Un PBI puede describir cualquier cosa que tenga un valor potencial para una parte interesada.

Una historia (de usuario) es un formato estándar útil para los elementos acumulados. La razón detrás de esto es "si a nadie le importa, no pierdas el tiempo". También permite que la OP evalúe la urgencia del artículo porque define para quién lo hará y qué tan malo es.

En su caso, el error puede formatearse fácilmente como una historia.

• Como usuario
• Quiero poder iniciar sesión desde la página X (y no obtener un error en su lugar)
• así que no perderé tiempo, me molestaré y perderé la fe en el producto

Parece que vale la pena un esfuerzo.