28 Antipatrones comunes del Product Backlog en Scrum

28 Antipatrones comunes del Product Backlog en Scrum

Scrum es un marco práctico para crear productos siempre que identifique de antemano qué construir. Pero, incluso después de una fase exitosa de descubrimiento de productos es posible que tenga dificultades para hacer lo correcto de la manera correcta si el Product Backlog no está a la altura del trabajo. Basura ingresa, basura sale, como dice el refrán. Este artículo señalaremos 28 de los antipatrones del Product Backlog más comunes, incluido el proceso de refinamiento de este Product Backlog que limitan el éxito de su equipo Scrum.

Los 28 Anti-patrones comunes del product backlog es un trabajo realizado por el PST Alemán Stefan Wolpers trainer de Scrum.org.

Publicado en Age of Product una marca registrada en Berlin con el nombre de Product People GmbH.

https://age-of-product.com/

Un proceso típico de refinamiento del Product Backlog
Según la Guía de Scrum, un proceso típico es el siguiente:

El Product Owner prioriza el Product Backlog por adelantado, por lo que refleja el mejor uso posible de los recursos de los developers:

  • El Product Owner crea y rellena previamente los dos próximos sprints con historias de usuario o PBIs utilizando el software de gestión de proyectos del equipo (o una hoja de cálculo o cualquier otra herramienta organizativa que aplique el equipo)
  • El Product Owner  mantiene este patrón de forma continua.
  • El Product Owner también agrega nuevas historias de usuario que puede haber identificado desde la sesión de refinamiento anterior

El Product Owner y los developers están trabajando conjuntamente en las historias de usuario.

  • El Product Owner proporciona la respuesta a la pregunta “por qué” (propósito de negocio),
  • El equipo responde a la pregunta ‘cómo’ (implementación técnica),
  • Y ambos colaboran en la pregunta del ‘qué’: ¿Qué alcance es necesario para lograr el propósito deseado?
  • Todo el equipo está de acuerdo con las discusiones dentro del Timebox. Un timebox típico por historia de usuario sería de alrededor de cinco minutos en promedio por ciclo.
  • El Product Owner proporciona los criterios de aceptación de las historias de usuario.
  • Los developers define lo que se requiere para considerar que una historia de usuario está lista para convertirse en un elemento de la lista de trabajos pendientes.
  • El Product Owner aclara las preguntas del equipo o invita a expertos en la materia a sesiones de refinamiento que pueden responder las preguntas del equipo.
  • Los ciclos de refinamiento consecutivos duran hasta que cada historia de usuario cumple con la definición de listo.
  • Por último, el equipo puede estimar las historias de usuarios disponibles que cumplen con los criterios de “definición de listo”. El Product Owner ahora puede elegir entre esas historias de usuario para formar parte de un próximo sprint.

A pesar de ser relativamente sencillo, el proceso de creación y perfeccionamiento de un Product Backlog a menudo adolece de varios anti-patrones. Aquí identificamos cinco categorías diferentes para los anti-patrones del Product Backlog:

También puedes descargarlo en formato .pdf para leerlo después 👇

Antipatrones del Product Backlog
En General
  1. Priorización por poder: una sola parte de stakeholders o un comité de stakeholders 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 convierten en Items del Product Backlog. Por lo tanto, el Product Owner también decide la prioridad. Quite ese empoderamiento y Scrum se convierte en un proceso de cascada 2.0 bastante robusto.
  2. 100% por adelantado: el Scrum Team crea un Product Backlog que cubre el proyecto completo o el producto por adelantado porque el alcance del lanzamiento es limitado. (Pregunta: ¿Cómo puede estar seguro de saber hoy qué entregar en seis meses a partir de ahora?).
  3. Sobredimensionado: el Product Backlog contiene más elementos de los que el equipo Scrum puede entregar en tres o cuatro Sprints. (De esta manera, el Product Owner genera desperdicio al acumular problemas que tal vez nunca se materialicen).
  4. Problemas desactualizados: el Product Backlog contiene elementos que no se han tocado durante seis a ocho semanas o más. (Por lo general, esa es la duración de dos a cuatro Sprints. Si el Product Owner está acumulando Product Backlog Items del Product Backlog surge el riesgo de que los elementos más antiguos se queden obsoletos, lo que hace que el trabajo previamente invertido del equipo Scrum sea obsoleto).
  5. Todo es estimado: todas las historias de usuarios del Product Backlog están detalladas y estimadas. (Eso es demasiado trabajo inicial y conlleva el riesgo de asignar mal el tiempo del Scrum Team).
  6. Items basados ​​en componentes: los items del Product Backlog se dividen horizontalmente en función de los componentes en vez de la horizontalidad o en función de las características de un extremo a otro también conocido End to End. (Esto puede deberse a su estructura organizativa. Luego, cambie a equipos multifuncionales para mejorar la capacidad de ejecución del equipo. De lo contrario, el equipo y el Product Owner necesitan un taller sobre cómo escribir historias de usuarios).
  7. Faltan criterios de aceptación: hay historias de usuarios en el Product Backlog sin criterios de aceptación. (No es necesario tener criterios de aceptación al comienzo del ciclo de refinamiento aunque facilitarían mucho la tarea. Al final, todas las historias de usuario deben cumplir con el Definition de Terminado (Definition Of Done) y los criterios de aceptación son parte de esa definición.)
  8. No más que un título: el Product Backlog contiene historias de usuarios que forman parte de poco más que un título.
  9. Hay historias de usuarios con una extensa lista de criterios de aceptación. (Este es el otro extremo: el Product Owner cubre cada caso límite sin negociar con el equipo. Por lo general de tres a cinco criterios de aceptación son más que suficientes).
  10. Ni temas ni epopeyas: el Product Backlog no está estructurada por temas o epopeyas. (Esto hace que sea difícil alinear los elementos individuales con el “panorama general” de la organización. No se supone que el product backlog sea una variedad de tareas aisladas o una gran lista de tareas pendientes).
  11. Sin investigación: el Product Backlog contiene pocos spikes o ninguno. (Esto a menudo se correlaciona con un equipo que dedica demasiado tiempo a discutir posibles problemas, en lugar de investigarlos con un spikes como parte de un proceso iterativo de creación de historias de usuario).
Antipatrones del Product Backlog
A nivel de Portafolio y a nivel de hoja de ruta del producto (Roadmap)
  1. ¿Y el Roadmap? el Product Backlog no refleja su roadmap. (Se supone que el Product Backlog debe detallarse solo para los primeros dos o tres Sprints. Más allá de ese punto el Product Backlog debe centrarse en temas y aspectos épicos de su Roadmap. Si no está disponible es probable que ese Product Backlog sea granular
  2. Roadmap anuales: el plan del Product Backlog de la organización así como el plan de release o el roadmap se crean una vez al año por adelantado. (Si el Product Backlog se mantiene alineada con estos planes se esta introduciendo la planificación en cascada a través de la puerta de atrás. La planificación ágil siempre es “continua”. A nivel de Portafolio el plan debe revisarse al menos cada tres meses).
  3. Las roadmaps se mantienen en secreto: la planificación del Portafolio y el plan de release o el roadmap del producto no son visibles para todos. (Si no sabe a dónde va, cualquier camino lo llevará allí. Esta información es crucial para cualquier Scrum Team y debe estar disponible para todos en cualquier momento).
  4. China en sus manos: la planificación del Portafolio y el plan de release o el roadmap del producto no se consideran factibles ni creíbles. (Si esto se refleja en el Product Backlog probablemente sea un desperdicio trabajar en las historias de los usuarios)
Antipatrones del Product Backlog
Con el Product Owner
  1. Almacenamiento de ideas: el Product Owner utiliza el Product Backlog como depósito de ideas y requisitos. (Esta práctica está obstruyendo Product Backlog y puede conducir a una sobrecarga cognitiva y dificulta la alineación con el “panorama general” y a nivel de gestión del portafolio y planificación del roadmap).
  2. Orden de compra a tiempo parcial: el Product Owner no trabaja a diario en Product Backlog. (El Product Backlog debe representar en un momento dado el mejor uso de los recursos de los developers. Actualizarlo una vez a la semana antes de la próxima sesión de refinamiento no es suficiente para cumplir con este requisito).
  3. Copiar y pegar PO: el Product Owner crea historias de usuarios dividiendo los documentos de requisitos recibidos de las stakeholders en partes más pequeñas. (Ese escenario ayudó a acuñar el apodo de “mono de entradas” para el Product Owner. Recuerde: la creación de historias de usuario es un ejercicio de equipo).
  4. Product Owner dominante: el Product Owner crea historias de usuarios proporcionando no solo el “por qué”, sino también el “cómo” y el “qué”. (El equipo responde a la pregunta ‘cómo’ (la implementación técnica), y tanto el equipo como el Product Owner colaboran en la pregunta del ‘qué’: qué alcance es necesario para lograr el propósito deseado).
  5. ¿INVEST? El Product Owner no está aplicando el principio INVEST de Bill Wake a las historias de los usuarios.
  6. Problemas demasiado detallados: el Product Owner invierte demasiado tiempo por adelantado en las historias de los usuarios, haciéndolas demasiado detalladas. (Si una historia de usuario parece completa, es posible que los miembros del equipo no vean la necesidad de involucrarse en un mayor refinamiento. De esta manera, una historia de usuario “amplia” reduce el nivel de participación del equipo, lo que compromete la creación de un entendimiento compartido. Por cierto, esto no sucedió en los días en que usábamos tarjetas de índice debido a su limitación física).
  7. ¿Qué equipo? El Product Owner no está involucrando a todo el Scrum Team en el proceso de refinamiento y, en cambio, está confiando solo en el “Líder Técnico” (o cualquier otro miembro del equipo independientemente de los demás).
  8. ‘Lo sé todo’: El Product Owner no involucra a los stakeholders ni a los expertos en la materia en el proceso de refinamiento. (Un Product Owner que cree ser omnisciente o una puerta de enlace de comunicación es un riesgo para el éxito del equipo Scrum).
Slide 1

Simulador para PSM I de Scrum.org (580 preguntas)

Evalúe su conocimiento previo al examen de certificación como Professional Scrum Master I de Scrum.org

Slide 2

Workshop para Profesionales Product Owners

Este curso es el entrenamiento si necesitas mayor comprensión de cómo colaborar con los equipos autoorganizados, ser Product Owner no es fácil y puede llevar algún tiempo llegar allí, ser Product Owner requiere habilidades, rasgos específicos y conocer de técnicas de gestión de productos

Product Owner
Slide 3

Workshop Scrum para Developers

Entrenamiento ideal para quienes quieren experimentar como las prácticas de ingeniería modernas en Scrum ayudan a la creación de incrementos de producto potencialmente desplegables y usables.

Scrum Developer
previous arrow
next arrow
Antipatrones del Product Backlog
Con los Developers
  1. Equipo sumiso los que conforman como developers en el Scrum Team sigue sumisamente las demandas del Product Owner. (Desafiar al Product Owner si su selección de problemas es el mejor uso del tiempo de los Developers es la obligación más noble de cada miembro del equipo preguntar: ¿Por qué debemos hacer esto?)
  2. ¿Qué deuda técnica? los Developers no exige los recursos adecuados para abordar la deuda técnica y los errores. (La regla general es que el 25% de los recursos se asignan en cada sprint para corregir errores y refactorizar el código base).
  3. Sin holgura: los Developers no exige un 20% de tiempo de holgura al Product Owner. (Esto se superpone con la planificación del sprint y el pronóstico del equipo. Sin embargo, no se puede abordar con la suficiente antelación. Si la capacidad de un equipo se utiliza siempre al 100%, su rendimiento disminuirá con el tiempo. Todos se centrarán en realizar sus tareas. Habrá menos tiempo para apoyar a los compañeros de equipo o para emparejarse. Los pequeños problemas ya no se abordarán de inmediato. Y, en última instancia, la actitud de “estoy ocupado” reducirá la generación de un entendimiento compartido entre todos los miembros del equipo por qué hacen lo que están haciendo).
Antipatrones del Product Backlog
Con el Scrum Team
  1. No hay tiempo para el refinamiento: el equipo no tiene suficientes sesiones de refinamiento, lo que resulta en un Product Backlog probablemente de baja calidad. (Prueba con dedicarle hasta un 10% del tiempo del equipo Scrum al refinamiento del Product Backlog, será una decisión de negocio sólid0, nada es más caro que entregar una función que no ofrece ningún valor).
  2. Demasiado refinamiento: el equipo tiene demasiadas sesiones de refinamiento, lo que resulta en un Product Backlog demasiado detallado. (Demasiado refinamiento tampoco es saludable).
  3. No tener un DoD: El Scrum Team no ha creado una ‘definición de terminado’ que los Product Backlog Items del Product Backlog deben coincidir antes de ser seleccionables para un sprint. (Una lista de verificación simple como la ‘definición de terminado’ puede mejorar significativamente el trabajo del Scrum Team. Aumentará la calidad tanto de las historias de usuario resultantes como de la forma general de trabajar en equipo).
¿Quieres aprender más?
Probablemente este artículo te ha sido útil. Los antipatrones del Product Backlog son temas que se discuten en el curso de preparación para la certificación como Professional Scrum Product Owner I de Scrum.org. Si desea unirse al curso consulta abajo las próximas fechas planificadas.
Más información
Este es un artículo curado y traducido al español extraído del blog de Scrum.org, escrito por el PST Alemán Stefan Wolpers.

Leave your Comment

Únete a nuestro canal telegram Scrum y DevOps Profesional
Acerca de QuizScrum.com

El mejor lugar para aprender Scrum y DevOps Profesional en idioma español e inglés a pocos clicks de distancia.

Próximos eventos

Professional Scrum Foundations (Presencial)

January 28, 2022 - January 29, 2022
Caracas
9460457
DD days
HH hours
MM min
SS sec