No quiero ponerme demasiado meta, pero estaba a punto de escribir una historia para agregar "requerir una justificación de prioridad cuando se cambia" al software Scrum de nuestra empresa. Y estaba pensando, como Scrummaster, que esa no es una de las dos cosas que necesitamos explicar para hacer las cosas (es decir, la historia del usuario y los criterios de aceptación). Pero me gustaría agregarlo a algunas historias para que el PO pueda saber por qué creo que podría ser una prioridad más alta aunque no soy yo quien hace la priorización final.
Entonces, ¿es información útil en Scrum para que la persona que escribe la historia diga por qué cree que la necesita más temprano que tarde o esta información simplemente se pierde en la maleza por lo general?
La respuesta a su pregunta se encuentra en las "3 C de las historias de usuarios". La primera C de la historia de usuario es la tarjeta (lo que estás escribiendo) que actúa como una especie de recordatorio y marcador de posición para la segunda C, la conversación. Muchas de las personas que introdujeron y popularizaron las historias de usuarios han dicho que la razón por la que usaron tarjetas de índice fue porque específicamente no había suficiente espacio para escribir todo lo necesario en la tarjeta y te obligaba a tener la conversación.
Entonces, para sus preguntas específicamente, la parte "para que" de la historia de usuario canónica en la tarjeta puede insinuar la necesidad, pero gran parte de la explicación de por qué debe priorizarse proviene de la conversación con el propietario del producto.
Consultemos la Guía de Scrum .
El propietario del producto es responsable de la cartera de productos, incluido su contenido, disponibilidad y pedidos.
Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones. Las decisiones del propietario del producto son visibles en el contenido y el orden de la cartera de productos.
El deseo de "requerir una justificación de prioridad cuando se cambia" viola el marco Scrum.
Veamos también los principios del Manifiesto para el desarrollo ágil de software.
El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara.
Aunque especificando el equipo de desarrollo , también se aplicaría a
Me gustaría agregarlo a algunas historias para que el PO pueda saber por qué creo que podría ser una prioridad más alta
Registrar el por qué de cambiar el orden (no la prioridad) podría ser algo que el Propietario del producto quisiera rastrear, pero probablemente no debería ser un requisito.
También tenga en cuenta que, aunque se usa comúnmente, la historia del usuario no es un aspecto del marco Scrum.
Pedro Turner
Daniel