Artefactos en la Scrum Extension Guide: Refuerzos y novedades alineados a Product Management

Análisis de: Vanessa Amaya

Bien bien bien, llegué a mi parte favorita de la extensión de la Guía de Scrum ¡Porque es donde se habla del Product Backlog! ¿Por qué me gustó esto? Porque en la Guía oficial aparece mencionada 22 veces, considerando que la guía tiene 22 páginas es mucho, también es mucho considerando que se menciona más que al Scrum Master pero solo viene su definición y sus 22 menciones, nada más.

La palabra Sprint por el contrario, se menciona 133 veces en la guía, lo cuál es normal, el Sprint es el corazón de Scrum, pero todo corazón necesita arterias que lo conecten con el resto del cuerpo y esas arterias, para mí, son justo el Product Backlog.

• Porque sin Backlog no se puede trabajar.

• Porque si tenemos Backlog pero no está bien hecho afecta a todo el proceso.

• Porque si no hay un Backlog claro impacta en retrasos por malos entendidos.

• Porque si no hay un Backlog priorizado, arriesgamos la entrega de valor y sobrecargamos a los equipos sacrificando de paso la calidad de lo que se genera.

Se que mi interés en el Backlog es debido a que también es mi corazón, lo que hace latir mi trabajo como Business Analyst en mi mundo de Product Management ágil, pero no me puedes negar que un Backlog es esencial y hacerlo bien es factor determinante de éxito.

Pues bien, en la extensión de la guía de Scrum se profundiza en los elementos del product Backlog o Product Backlog Item, los cuales en la guía oficial solo se mencionaban 2 veces:

“Un elemento del Product Backlog es un elemento potencialmente valioso en el Product Backlog. No tiene necesariamente un formato específico. Su objetivo es abordar un problema u oportunidad. Puede incluir criterios de aceptación que indican cuándo se ha completado el trabajo, además de la definición de resultado finalizado. Un elemento del Product Backlog es una pieza de trabajo que descubre o aporta valor.”

Aunque en ninguna guía se ha hablado del formato que llevan los elementos del Backlog, tampoco se había dicho que no tiene un formato específico. Considero eso valioso porque muchos han supuesto que un Backlog solo contiene Historias de Usuario (práctica usada mucho por equipos Scrum y con frecuencia no saben que esta práctica viene de eXtreme Programming).

No puede ser que un Backlog tenga solo historias de usuario, un Backlog tiene todos los elementos necesarios para crear la solución y que el equipo comprenda lo que necesita hacer y sobre qué necesita colaborar. Los elementos del backlog son las partes de la solución y dichas partes no solo tienen la visión o peticiones hechas desde el punto de vista del usuario sino también incluyen: elementos técnicos derivados que el equipo identifica tendrá que realizar, también puede incluir habilitadores que hagan que el producto cuente con entornos adecuados y elementos que van a ayudar a pasar de “Terminado a entregado” (requisitos de transición).

Un concepto que también aparece y considero muy valioso es el “Criterio de resultado”: Se podría entregar exactamente lo solicitado, pero aún así no obtener los resultados suficientes. Por lo tanto, un elemento del Product Backlog también puede incluir criterios de resultado claramente definidos que indican cuándo se ha entregado suficiente valor, además de lo que ya figura en la definición de resultado finalizado.”

Un concepto que aparece es Definition of Output Done (Definición de Resultado Realizado) que es el tener un compromiso y entendimiento hacia la calidad, describiendo formalmente las medidas de calidad que expresan la debida diligencia para el Incremento, de modo que pueda entregarse a las Partes Interesadas. Este concepto refuerza en no enfocarnos solo en “las salidas” e ir más allá de la Derinition of Done (Definición de Terminado). Ojo, la Definición de Terminado no se sustituye por esta nueva, es complementaria y tiene otro objetivo.

Dentro de esta sección se profundiza también es en el Refinamiento. ¡Ya era hora! porque el refinamiento se menciona en la guía oficial una sola vez y es una práctica necesaria y constante dentro de equipos Scrum (y cualquier equipo) para mantener el Backlog sano: priorizado, claro, dividido, actualizado, transparente y entendido.

“El refinamiento es una actividad. Puede ser formal (un evento adicional) o informal. Es un proceso emergente y continuo que fomenta la claridad y reduce el riesgo; genera suficiente comprensión y confianza para que los elementos del Product Backlog seleccionados o futuros estén listos (puedan completarse, de acuerdo con la Definición de Salida Realizada, en un plazo breve o incluso inferior). Se consideran varios tipos de dependencias.”

Como proceso continuo, recomiendo poner en planes y agendas mínimo una sesión de refinamiento a la semana. Cuando se puede más, lo hago más veces, pero con una vez a la semana ayuda bastante sobre todo cuando se presenta el escenario que se plantea en la extensión de la guía: “El refinamiento puede implicar investigación, incluyendo, entre otros, la validación de problemas u oportunidades, la experiencia del usuario o del cliente y la validación de soluciones.”

Podría hacer más sentido que el refinamiento apareciera dentro de la sección de eventos de Scrum, pero creo que hace sentido que se haga referencia del Refinamiento en la sección de artefactos donde está el Product Backlog Item ya que el insumo del Refinamiento son los elementos del Backlog y la salida del Refinamiento son esos elementos.

Conclusión:

Esta extensión de la guía de Scrum hace un énfasis muy importante en el Product Management, no solo por esta sección de artefactos sino por la importancia que le da al Product Thinking en la sección de Teoría de soporte y complementaría. Esto lo veo muy relevante, porque creo que si hay muchos detractores de Scrum en parte ha sido porque quieren seguir gestionando proyectos cuando lo que necesitan es gestionar productos. No es el mismo tipo de gestión porque los ciclos de vida son muy diferentes e intentar gestionar proyectos cuando lo que se necesita es obtener productos, ocasiona desalineaciones constantes, entregas poco relevantes y una sensación de que 'nada cambia', cuando en realidad lo que falta es un cambio en la forma de pensar el valor.

En ese caso, no es que Scrum falle, lo que falla es seguir aplicando una lógica de inicio-fin cuando se necesita una mentalidad evolutiva y continua para la generación frecuente de valor.

¿Quieres saber más?

Entra a “Roles expandidos: Scrum Guide Expansion Pack”

Entra a “Explorando la Guía Expandida de Scrum 2025”

Entra a “Teoría de soporte y complementaria de la Expansión de la Guía de Scrum”

Entra o descarga la Scrum Guide Expansion Pack

Entra o descarga la Guía oficial de Scrum