5 estrategias para perfeccionar tu Product Backlog

5 estrategias para perfeccionar tu Product Backlog

Los equipos Scrum lo hacen todo el tiempo. Ocurre durante el Sprint Review, después de Daily Scrum, en el Sprint Planning y como parte del trabajo de desarrollo. Se discuten el próximo trabajo para obtener un entendimiento compartido y esta discusión incluye:

  • Aclarar los entregables resultantes del trabajo
  • Ordenar el trabajo en el Product Backlog para que los objetivos del Scrum Team y de la organización se logren cada vez mejor al Product Goal
  • Eliminando dependencias dentro del trabajo
  • Estimar el trabajo en tamaño y valor
  • Comprender las suposiciones en el trabajo

Por lo tanto, se trata del trabajo futuro expresado como Product Backlog items en el Product Backlog. Barry Overeem se refiere a estos elementos como recordatorios de conversaciones que deben suceder en el futuro. El refinamiento es simplemente la actividad continua de tener estas conversaciones y, por lo tanto, una actividad esencial de gestión de productos.

¿Por qué es necesario perfeccionar el Product Backlog?

En el refinamiento los Product Backlog Items se discuten hasta que se alcanza un entendimiento compartido. Estos Items se desglosan hasta que los desarrolladores estén bastante seguros de que pueden completarlos dentro de un Sprint. Esto le da al Product Backlog un nivel de transparencia que reduce el riesgo. El riesgo se expone al no completar un ítem dentro de un Sprint y así regalar la oportunidad de generar valor para la organización. Es por eso que el refinamiento es una actividad esencial de gestión de productos que los equipos Scrum exitosos deben dominar.

Los Scrum Teams saben que es eficiente en el tiempo refinar solo los elementos principales en el Product Backlog porque inevitablemente aprenderán cosas nuevas que cambiarán su visión de los elementos más abajo o los harán redundantes. Por lo tanto, los equipos de Scrum refinan solo los elementos que se mueven más arriba en el Product Backlog. Para evitar refinar demasiado antes de tiempo los desarrolladores pueden como recomendación dedicarle un 10% de su tiempo.

5 estrategias para perfeccionar el Product Backlog

Aunque el refinamiento es una actividad esencial de gestión de productos, el 43% de los equipos Scrum no pasan tiempo en el Sprint actual para perfeccionar el trabajo para los próximos Sprints, según en la web de Guía Scrum Zombie . A continuación las 5 estrategias que ayudan a los Scrum Teams a refinar el Product Backlog:

Para obtener conocimientos
Se establece una comprensión compartida del trabajo si el equipo Scrum y los Stakeholders descubren conocimientos de manera conjunta. Hypothesis Canvas y UX Fishbowl son herramientas que puede facilitar ese descubrimiento.
Hypothesis Canvas
Lean UX Canvas

En el desarrollo de productos, se desconoce más de lo que se sabe. Los clientes cambian de opinión y las tecnologías están cambiando. Desafortunadamente, el hábito de manejar esta complejidad con predicciones fijas y planes detallados todavía existe en muchas organizaciones, incluso aquellas que usan Scrum. Cuando se les pide a los Scrum Teams que adivinen las necesidades del producto, el comportamiento del cliente y el ajuste entre el producto y el mercado a menudo están condenados al fracaso. Las organizaciones pueden cambiar esto empoderando a los Scrum Teams como equipos de resolución de problemas, no como fábricas de entrega de funcionalidades.

Los equipos Scrum exitosos no comienzan implementando funciones. Comienzan pensando en los problemas del cliente y haciendo suposiciones sobre las posibles soluciones. El Hypothesis Canvas basado en Lean UX Canvas de Jeff Gothelf alienta a los equipos Scrum a explorar los problemas de manera creativa.

Ayuda a los equipos Scrum y Stakeholders a ver los Product Backlog Items del Product Backlog no como requisitos fijos, sino como sus mejores hipótesis sobre la entrega de valor. Criterios de éxito claros, dígale a sus Scrum Teams qué resultado debe lograr el usuario al usar la función y qué impacto tendrá el uso en el archivo del objetivo del producto.

En el refinamiento, los equipos Scrum trabajan con sus Stakeholders para desarrollar estas hipótesis.

Un UX Fishbowl es una estructura liberadora que permite a los equipos Scrum explorar cómo se vería la implementación del Item del Product Backlog desde la perspectiva de los Stakeholders y qué les permite.

Un UX Fishbowl consta de dos grupos y dos pasos, un grupo son los Stakeholders  y el otro es el equipo Scrum. Los pasos se realizan en una secuencia y tantas veces como sea necesario.

  1. Se invita a los Stakeholders a discutir las preguntas. “Imagina que esta función ya forma parte del producto. ¿Cómo, cuándo y por qué la usarías? ¿Qué pasos implica? ¿Qué te hace útil? ¿Qué podría disuadirte?” El equipo Scrum escucha con atención y toma nota de los conocimientos esenciales.
  2. El equipo Scrum se reúne y formula preguntas de seguimiento basadas en lo que escucharon. Estas preguntas sirven como preguntas para la siguiente ronda.

Esta UX Fishbowl abre oportunidades para que los equipos Scrum desglosen los Product Backlog Items grandes del Product Backlog en otros más pequeños que aún son valiosos para los Stakeholders .

Ordenando el Product Backlog
Los Product Owners saben que ordenar el Product Backlog no es algo que deban hacer solos. Cuando los equipos Scrum solicitan la colaboración del Product Backlog con los Stakeholders obtienen nuevos conocimientos sobre lo que puede ser valioso para el producto. Técnicas como Buy a Feature y 20/20 Vision ayuda a los Scrum Teams ordenar el Product Backlog.

Los equipos Scrum involucran a los posibles usuarios de los Product Backlog Items para determinar qué Items son importantes. La estrategia de Comprar una función (Buy a feature) del libro Innovation Games habilita esto de la siguiente manera:

  1. Los items de la Lista de Producto que se pueden comprar tienen un precio y se enumeran.
  2. El dinero se divide en partes iguales entre los Stakeholders.
  3. Los Stakeholders compran los Product Backlog Items (PBIs) que son más importantes para ellos. Cada PBI solo se puede comprar una vez. Los Stakeholders pueden combinar su dinero al comprar.
  4. Cuando se gasta todo el dinero, los PBI comprados en la lista reflejan los artículos colectivamente importantes para los Stakeholders.
    Para alentar a los Stakeholders a colaborar, el precio de algunos PBIs debe ser lo suficientemente alto como para que ninguno de los Stakeholders pueda comprarlos solo. Con la cantidad total de dinero, solo debería ser posible comprar la mitad de los Items.

Tener una visión 20/20 significa ver perfectamente sin tener que usar anteojos o lentes de contacto. Los equipos Scrum pueden utilizar los siguientes pasos para ver el orden del Product Backlog a la perfección a través de los ojos de sus Stakeholders:

  1. Cada Product Backlog Item es una tarjeta separada.
  2. Las cartas se barajan y se forma una pila boca abajo.
  3. La carta superior se utiliza como referencia y se coloca boca abajo junto a la pila.
  4. Después de revelar la siguiente tarjeta, los Stakeholders deciden si es más o menos importante para ellos y la colocan encima o debajo de la tarjeta de referencia según corresponda.
  5. El proceso de agrupar las cartas restantes en la nueva lista se repite hasta la última carta de la pila. Se crea una visión 20/20 del orden del Product Backlog que muestra lo que es importante para los Stakeholders.
Estimación de los PBIs (Product Backlog Items) del Product Backlog
El objetivo de la estimación es obtener una comprensión compartida del trabajo en el Product Backlog, no para tener una certeza absoluta sobre el esfuerzo de implementación necesario. Los equipos Scrum estiman los Product Backlog Items haciendo que los desarrolladores les asignen un tamaño. El tamaño no expresa el tamaño absoluto del Product Backlog Item, sino el tamaño en relación con los otros elementos. Los equipos Scrum usan tamaños relativos porque las personas pueden determinar las relaciones más fácilmente. La estimación mágica y el póquer de planificación son prácticas de estimación basadas en el tamaño relativo.
Estimación mágica
La estimación mágica permite a los equipos Scrum estimar los Product Backlogs en tan poco tiempo que parece mágico. Se requieren los siguientes pasos:
  • Los números 1,2,3,5,8,13,21 y el signo ? de la serie Fibonacci forman posibles valores de tamaño.
  • A un Product Backlog Item del Product Backlog se le asigna conjuntamente un tamaño y sirve como referencia para la asignación de los PBIs restantes.
  • Los PBIs restantes del Product Backlog se distribuyen entre los desarrolladores.
  • Los desarrolladores asignan un tamaño a cada uno de los PBIs de su Product Backlog en relación con la entrada de referencia. Si no comprenden un Item de estos se les asigna el signo de interrogación. El proceso de asignación se realiza en silencio.
  • Una vez asignados todos los PBIs del Product Backlog los desarrolladores inspeccionan las asignaciones realizadas por otros. Se asignará un nuevo tamaño si no está de acuerdo con el tamaño actual del Item.
  • Si no se puede asignar un tamaño único a un PBI del Product Backlog se le asigna un tamaño entre los dos valores. Si se ha asignado un signo de interrogación a un PBI se necesitan más aclaraciones con la participación del Produc Owner hasta que se pueda asignar un tamaño único.

El resultado es un Producto Backlog estimado en relación con un PBI de referencia.

Planning Poker
Que se remonta a James Grenning, ayuda a los equipos de Scrum a comprender los Items del Product Backlog y a obtener una comprensión compartida de su tamaño. El modelo de esta técnica de estimación es un juego de póquer. El procedimiento es el siguiente:

Fuente imagen: https://www.mountaingoatsoftware.com/

  • El Product Owner explica el PBI del Product Backlog que se va a estimar.
  • Cada desarrollador estima individualmente el PBI asignándole un tamaño. Todas las opciones permanecen ocultas hasta que todos hayan estimado el PBI. Luego, los desarrolladores comparan su elección.
  • Si no hay acuerdo sobre el tamaño, los Desarrolladores entablan una conversación sobre las diferencias y vuelven a estimar (paso 2). Este ciclo se repite hasta que se llega a un acuerdo. Este acuerdo refleja el entendimiento compartido del PBI del Product Backlog.

Los posibles valores para el tamaño incluyen dedos, ositos de goma o tallas de camiseta.

[smartslider3 slider=”2″]
Desglose de los Product Backlog Items
Los equipos Scrum desglosan los Items del Product Backlog para que la implementación de cada Item sea utilizable de inmediato. Este desglose vertical asegura valor para el usuario. Los desgloses horizontales de los elementos del Product Backlog solo ocurren en el Sprint Planning cuando se crea un plan para el próximo Sprint.

Desglose los Product Backlog Items del Product Backlog por pasos del flujo de trabajo

Si los items del Product Backlog contienen un flujo de trabajo, se pueden dividir en pasos individuales. El Item o el PBI que describe que un cliente puede pagar los productos en su carrito de compras se puede dividir en los siguientes artículos:

  • Como cliente, puedo iniciar sesión con mi cuenta.
  • Como cliente, puedo pagar mi pedido.
  • Como cliente, recibo un correo electrónico de confirmación con mi pedido.

Desglose los Items del Backlog de productos por caminos felices e infelices

La funcionalidad a menudo incluye un camino feliz y un camino infeliz. El camino feliz describe cómo se comportará la funcionalidad si todo sale como se desea. Si hay desviaciones, excepciones u otros problemas se invocan rutas no felices.

El Product Backlog Item que describe que el cliente puede iniciar sesión con su cuenta, puede dividirse en dos partes.

  • Como cliente, puedo iniciar sesión con mi cuenta. Esto describe el camino feliz.
  • Como cliente, puedo restablecer mi contraseña si falla el inicio de sesión. Esto describe el camino infeliz.

Se pueden encontrar más estrategias de desglose 👉 aquí

Eliminando dependencias
Aunque los equipos Scrum son multifuncionales, trabajan en un entorno complejo. Esto podría dar lugar a dependencias imprevistas. Las dependencias pueden impedir que el Product Owner pueda maximizar el valor. Las dependencias aumentan el riesgo de retrasos y dificultan que el Scrum Team cree un incremento utilizable en el Sprint.

Hay una variedad de dependencias:

  • Dependencias internas: los Product Backlog Items dependen unos de otros. Por ejemplo, cuando los pasos del flujo de trabajo se complementan entre sí, cuando ciertos Items del Product Backlog deben ser parte de un release o cuando los Items del Product Backlog entregan un valor mayor de manera coherente.
  • Dependencias externas: los Item del Backlog del producto dependen de factores externos. Los artículos pueden depender de procesos de negocio, como procesos de lanzamiento o procesos de compra. Pueden depender de sistemas de terceros. El trabajo requiere cambios técnicos en un área del sistema que está fuera del control del Scrum Team. La finalización de un artículo puede requerir experiencia o el apoyo de alguien con conocimientos específicos.

Los equipos Scrum hacen que las dependencias sean visibles en el Product Backlog para que puedan eliminarse temprano. Posibles pasos para hacer visibles las dependencias:

  1. Identifique las dependencias en el Product Backlog.
  2. Resalte las dependencias con flechas para aclarar cómo los elementos dependen unos de otros o de factores externos.
  3. Cree un gráfico utilizando todos los elementos como nodos y con las flechas de dependencias como bordes.

El gráfico resultante proporciona información que permite al Equipo Scrum eliminar dependencias. La eliminación puede implicar el desglose de los Items del Backlog del producto, reordenar el Backlog, encontrar nuevas soluciones técnicas que no requieran un sistema externo, colaborar con otros equipos por adelantado o adquirir el conocimiento faltante dentro del equipo.

El refinamiento del Product Backlog es esencial
Obtener información sobre el trabajo futuro, ordenarlo en el Product Backlog, estimarlo, desglosarlo y eliminar las dependencias existentes ayuda a los Scrum Teams y sus Stakeholders a refinar el trabajo para establecer un entendimiento compartido. En Scrum, esta actividad de gestión de productos se denomina refinamiento (Refinement) del Product Backlog. Es fundamental porque reduce el riesgo de no completar el trabajo en el Sprint y futuros Sprints..
¿Quieres aprender más?
Quizás este artículo te ha sido útil. El refinamiento es uno de los temas que se durante el Professional Scrum Foundations y 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.

There are no upcoming events at this time

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 Simon Flossmann.

Leave your Comment

Únete a nuestro canal telegram Scrum y DevOps Profesional

Próximos eventos