Anti-patrones usuales del Product Backlog

Traducción al castellano de un fragmento del artículo “28 Product Backlog and Refinement Anti-Patterns” cuya versión original la puedes encontrar en https://age-of-product.com/28-product-backlog-anti-patterns/

Los anti-patrones que se muestran de manera habitual en la gestión del Product Backlog, son los siguientes:

Priorización a cargo de un Proxy

Un Stakeholder o un comité de Stakeholders es quien prioriza el Product Backlog. (La fortaleza de Scrum se basa en la sólida posición del Product Owner. El Product Owner es la única persona que decide qué tareas se convertirán en ítems del Product Backlog. Por lo tanto, el Product Owner también decide la prioridad. Quita este empoderamiento, y Scrum se convierte en un proceso waterfall 2.0 bastante robusto.)

Estar adelantado al 100%

El equipo de scrum crea un Product Backlog que cubre completamente el proyecto o producto porque el alcance del release es corto. (Pregunta: ¿Cómo puedes estar seguro en conocer qué entregarás en seis meses a partir de ahora?)

Sobredimensionamiento

El Product Backlog contiene más ítems de los que el equipo Scrum puede entregar en los siguientes tres o cuatro Sprints. (De esta manera, el Product Owner crea desechos al acumular problemas que podrían no materializarse nunca).

Issues obsoletos

El Product Backlog contiene ítems que no se han tocado durante seis a ocho semanas o más. (Por lo general, esta es la duración de dos a cuatro Sprints. Si el Product Owner está acumulando ítems de reserva, surge el riesgo de que los ítems más antiguos se vuelvan obsoletos, lo que hace que el trabajo invertido previamente por el equipo Scrum sea obsoleto).

Se estima absolutamente todo

Todas las historias de usuario del Product Backlog son detalladas y estimadas. (Eso es demasiado trabajo inicial y conlleva el riesgo de consumir en demasía el tiempo del equipo de scrum).

Ïtems basados en componentes

Los ítems del Product Backlog se dividen (slice) horizontalmente, basados en los componentes, en lugar de verticalmente, en función de las características end-to-end. (Esto puede deberse a tu estructura organizacional. Entonces lo que se debe hacer es conformar equipos multifuncionales para mejorar la capacidad de entrega del equipo. De lo contrario, el equipo y el Product Owner necesitan un taller para escribir historias de usuarios).

Criterios de aceptación faltantes

Existen historias de usuario en el Product Backlog sin criterios de aceptación. (No es necesario tener criterios de aceptación al inicio del ciclo de refinamiento, aunque facilitarían mucho la tarea. Sin embargo, al final, todas las historias de usuario deben cumplir con la Definition of Ready (DoR), y los criterios de aceptación son parte de eso definición).

Nada más que un título

El Product Backlog contiene historias de usuarios que comprenden poco más que un título.

Issues demasiado detallados

Existen historias de usuarios con una extensa lista de criterios de aceptación. (Este es el otro extremo: el Product Owner cubre cada caso extremo sin negociar con el equipo. Por lo general, entre tres y cinco criterios de aceptación son más que suficientes).

Ni Themes ni Epics

El Product Backlog no está estructurada por Themes o Epics. (Esto hace que sea difícil alinear los ítems individuales con el “panorama general” de la organización. El Product Backlog no se supone que sea una variedad de tareas aisladas o una gran lista de tareas pendientes).

No existe investigación

El Product Backlog contiene pocos o ningún Spike. (Esto a menudo se correlaciona con un equipo que pasa demasiado tiempo discutiendo posibles problemas, en lugar de investigarlos con un Spike como parte de un proceso de creación de historias iterativas de usuarios).

Leave a Reply

Your email address will not be published. Required fields are marked *