PBI vs historia de usuario

14

Recientemente, el propietario del producto ha agregado un elemento al Product Backlog 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 Backlog Item). Sin embargo, cuando lo comenté, scrum master me dijo que las historias de los usuarios no son PBI y que un PBI podría ser un informe de errores, una tarea, una historia del usuario, cualquier cosa y, literalmente, cualquier elemento que deba tratarse 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 el Product Backlog como elementos? ¿Un artículo de la cartera de productos se asigna a una historia de usuario? ¿Son los mismos?

    
pregunta Saeed Neamati 20.08.2011 - 12:04

5 respuestas

16
  

¿Se asigna un artículo de la cartera de productos a una historia de usuario? ¿Son los mismos?

No necesariamente, pero en general lo hacen. Como dijo su maestro scrum, otras cosas también pueden ser elementos de la cartera de productos. Sin embargo, depende de cómo funciona su SCRUM. Algunos equipos tienen una acumulación de errores separada que también se toma 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 las tareas, ya que ahora se deben tener en cuenta dos registros para el próximo sprint. Pero ofrecen una mejor supervisión y ambos pueden priorizarse por separado.

  

Entonces, mi pregunta es, ¿qué tipo de cosas pueden entrar en el Producto?   La acumulación como elementos?

Esto puede ser cualquier cosa que sea parte de la visión del producto y del viaje hacia el producto que desea crear. En su mayoría contiene requisitos (historias de usuario), 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 anuncio para el producto"). El retraso debe evitar los detalles innecesarios y no debe tratar de microgestionar los aspectos técnicos. La acumulación de productos puede contener cualquier cosa que ofrezca valor al producto.

No existe el único Scrum verdadero. A veces, los retrasos separados son una mejor manera de gestionar el producto, a veces son un obstáculo. Averigua qué funciona mejor para ti.

    
respondido por el Falcon 20.08.2011 - 12:26
3

Cuando trabajamos en errores, los agregamos al registro y los llamamos historias de errores . Al agregar correcciones de errores a la acumulación de esta manera, queda claro que no es solo la corrección de errores. Podemos agregar otras tareas para asegurarnos de que las pruebas automáticas 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 (a pesar de que nuestra herramienta de copia de seguridad lo llama), siempre es historias de usuarios, historias de errores o simplemente historias .

Es principalmente la elección de terminología de tu equipo y siempre que tengas claro lo que realmente no importa.

    
respondido por el Hugo 20.08.2011 - 16:30
2

@Falcon lo ha explicado bien. Una página que tiene una definición formal es: enlace Lo que ha descrito no debe colocarse en el registro de productos como mínimo de acuerdo con esa descripción.

    
respondido por el NoChance 20.08.2011 - 13:07
2

Existe un malentendido común de que solo se permiten las historias de usuario en un Product Backlog. Por el contrario, Scrum es neutral en las técnicas de requisitos. Como indica el Scrum Primer ,

  

Los elementos de la cartera de productos se articulan de forma clara y sostenible. Contrariamente a la mala interpretación popular, el Product Backlog no contiene "historias de usuario"; simplemente contiene elementos. Esos elementos se pueden expresar como historias de usuario, 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 deben centrarse en brindar valor a los clientes. *

    
respondido por el user666 25.03.2017 - 10:49
2

Todas las respuestas anteriores no hacen referencia al documento fuente autorizado para el marco de Scrum: The Scrum Guide .

Product Backlog

Hay una sección que describe la acumulación de productos y los elementos, a menudo denominados PBI, contenidos en ella.

  

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

Pero no es arreglado como un plan de proyecto.

  

El Product Backlog evoluciona a medida que evoluciona el producto y el entorno en el que se utilizará. El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto debe ser apropiado, competitivo y útil.

Historia de usuario

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

  

es un marco dentro del cual puede emplear varios procesos y técnicas.

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

ADICIONALMENTE: Aunque es común ver el formato "Como, quiero, así que", puede ser contrario a su intención original . Este formato problemático también se abordó en Agile 2017 .

    
respondido por el Alan Larimer 19.03.2018 - 13:43

Lea otras preguntas en las etiquetas

Comentarios Recientes

Configuración Estos son algunos consejos que aprendí al tener un sitio de más de 20 años en el que se basó en los usuarios existentes y la experiencia de los planificadores centrales que llevaron a cabo proyectos a largo plazo rigurosos procesos de selección. Uno de los temas más importantes es el intercambio de datos, que es un lugar ideal para una plataforma de datos digitales heredada. Entrenado como científico de datos por mi mentor Howard Stern, llevo más de veinte años aprendiendo a medir la "suerte".... Lee mas