Un backlog de producto almacena, organiza y gestiona todos los elementos de trabajo en los que planeas trabajar en el futuro. servicios de formación ágil, consultoría y coaching at Digital.aiAnteriormente conocida como VersionOne, nuestros clientes suelen preguntar cómo estructurar, organizar y gestionar de forma lógica su backlog de producto. También quieren saber cómo priorizar o clasificar las tareas.

Aquí tienes una frase sencilla y fácil de recordar que resume las características clave de una lista de pendientes de producto bien gestionada: La lista de pendientes de producto es PROFUNDA; INVIERTE con prudencia y PROFUNDIZA con cuidado… de lo contrario, por implicación, podrías hundirte (es broma, pero solo un poco).

Las características clave de un backlog de producto bien organizado y gestionado se resumen en la imagen a continuación. DEEP, INVEST y DIVE son palabras significativas. Pueden usarse como acrónimos muy útiles para recordar estas características clave. En este blog, explicaré cómo gestionar un backlog de producto DEEP de forma eficaz mediante la inversión inteligente (INVEST) y la exploración cuidadosa (DIV[E]).

^{Figura 1: Estructura lógica y características clave de un backlog de producto bien gestionado}

La granularidad o tamaño de las tareas debe determinarse en función del horizonte de planificación del producto. Cuanto mayor o menor sea este horizonte, mayores o menores serán las tareas. Esto se debe a que desarrollar, especificar y mantener un gran número de tareas de grano fino requiere mucho más esfuerzo que desarrollar, especificar y mantener un número reducido de tareas de grano grueso. Las tareas más pequeñas, o historias de usuario, se desarrollan generalmente dividiendo tareas más grandes, o épicas. Las historias de usuario son la unidad básica del diseño, el desarrollo y la entrega de valor del software.

Lista de productos pendientes DEEP

Un backlog de producto puede contener cientos o más elementos de trabajo, de ahí el acrónimo DEEP. Los elementos de trabajo pueden incluir historias de usuario, defectos y conjuntos de pruebas. DEEP es también un acrónimo interesante que captura la esencia de la estructura lógica de un backlog de producto.

• Ddetallados adecuadamente: Los elementos de trabajo en el backlog se especifican con un nivel de detalle apropiado, como se resume en la Figura 1 y se explica a continuación.
• EEstimación adecuada: Los elementos de trabajo en la lista de pendientes del producto se estiman adecuadamente como se explica a continuación.
• EEmergente: El backlog de producto no es estático ni estático; evoluciona constantemente en respuesta a la retroalimentación del producto y a los cambios en la competencia, el mercado y el negocio. Se añaden nuevos elementos al backlog, se refinan, mejoran y amplían los existentes, o se eliminan o se les cambia la prioridad.
• PPriorización según necesidad: Los elementos de trabajo en la lista de pendientes se ordenan linealmente según sea necesario, como se explica a continuación.

Horizonte de planificación del sprint, granularidad de los elementos de trabajo, estimación y orden de clasificación.

Si el horizonte de planificación es el próximo, es decir, el futuro sprint o iteración (Normalmente de dos a cuatro semanas), cada elemento de trabajo es lo suficientemente pequeño como para caber en un solo sprint y está completamente listo para ser trabajado, como se indica en la Figura 1 (ver la región superior en rojo). Una historia lista ya ha sido analizada con una definición clara (rol del usuario, funcionalidad y valor de negocio) y los criterios de aceptación asociados. Los elementos de trabajo planificados para el próximo sprint son historias, defectos y conjuntos de pruebas. Estos elementos tienen la mayor prioridad en comparación con los elementos de sprints o ciclos de lanzamiento posteriores. Pronto explicaré cómo se realiza esta priorización. La información de la prioridad se utiliza para decidir el orden en que el equipo abordará los elementos del backlog del sprint y también para decidir qué elementos incompletos se trasladarán al backlog de lanzamiento o de producto al final del sprint.

Las tareas del próximo sprint cumplen en conjunto con los conocidos criterios INVEST; se trata de una palabra en inglés con significado, además de un acrónimo interesante acuñado por Bill Wake (véase su blog). Invierte en historias y tareas inteligentesSus letras representan características importantes de los elementos de trabajo en el backlog del próximo sprint. A continuación, explicaré las letras del acrónimo INVEST. Las historias en el backlog del próximo sprint deben ser:

• IIndependencia entre sí: A nivel de especificación, las historias son independientes; ofrecen funcionalidades claramente diferentes y no se superponen. Además, a nivel de implementación, estas historias también deberían ser lo más independientes posible entre sí. Sin embargo, en ocasiones, ciertas dependencias a nivel de implementación pueden ser inevitables.
• NNegociable: Las historias del próximo sprint siempre están sujetas a negociaciones y aclaraciones entre el propietario del producto (representante del negocio) y los miembros del equipo de desarrollo ágil.
• VValorable: Cada historia del próximo sprint ofrece un valor o beneficio claro, ya sea para usuarios o clientes externos (ajenos al equipo de desarrollo), para el propio equipo o para un interesado. En la mayoría de los productos y proyectos, la mayoría de las historias ofrecen valor a usuarios o clientes externos.
• EEstimación: A partir de la especificación de la historia, un equipo ágil debería poder estimar el esfuerzo necesario para su implementación. Esta estimación se realiza en términos de tamaño relativo (puntos de historia) y, opcionalmente, también puede expresarse en unidades de tiempo (como horas o días ideales del personal para todo el equipo). Por lo tanto, las historias se estiman en puntos de historia y, a menudo, también en unidades de tiempo ideales.
• Sadecuadamente: Una interpretación más sencilla de este criterio es que cada historia es Slo suficientemente pequeño como para ser completado y entregado en un solo sprint. La letra “S” puede interpretarse como SLas historias deben dimensionarse adecuadamente; específicamente, cada historia no debería requerir más de N/4 semanas de trabajo del equipo para un sprint de N semanas (véase «Scaling Lean and Agile Development» de Larman y Vodde, 2009, pág. 120). Por lo tanto, para un sprint de dos semanas, cada historia no debería requerir más de 2/4 semanas de trabajo = 0.5 semanas de trabajo = 20 horas de trabajo. Una historia considerablemente mayor a 20 horas de trabajo totales debe tratarse como una épica y dividirse en historias más pequeñas. Para un sprint de cuatro semanas, cada historia no debería requerir más de 4/4 semanas de trabajo = 1 semana de trabajo = 40 horas de trabajo. Si el backlog del sprint contiene una mezcla de historias pequeñas, medianas o grandes (su promedio supera con creces N/4 semanas de trabajo), el tiempo de ciclo promedio de todas las historias aumentará drásticamente, reduciendo la velocidad del equipo.
• Testable: Cada especificación de historia es muy clara para poder desarrollar todos los casos de prueba a partir de sus criterios de aceptación (que forman parte de la especificación).

Las historias de usuario pueden dividirse en tareas de implementación, como análisis, diseño, desarrollo de código, pruebas unitarias, desarrollo de casos de prueba, ayuda en línea, etc. Estas tareas deben ser SMART:

• S: Específico
• M: Medible
• A: Alcanzable
• R: Importante
• TCon plazos definidos (normalmente lo suficientemente cortos como para completarse en un solo día).

Si una historia requiere como máximo N/4 semanas de trabajo en equipo (por ejemplo, 20 horas de trabajo para sprints de dos semanas), la suma de todas las tareas SMART de la historia no debería superar las N/4 semanas de trabajo en equipo. Si hay cinco tareas, cada una debería requerir, en promedio, cuatro horas o menos de tiempo ideal. Vale la pena invertir en las historias y sus tareas SMART para el próximo sprint, ya que el retorno de la inversión es alto porque se programan para ser desarrolladas y entregadas como software funcional en el mismo sprint.

Release horizonte de planificación, granularidad de los elementos de trabajo, estimación y orden de clasificación

Si el horizonte de planificación corresponde a un próximo ciclo de lanzamiento (normalmente de ocho a veintiséis semanas, o de dos a seis meses, compuesto por varios sprints), los elementos de trabajo son de «grano medio», como se muestra en la región amarilla central de la Figura 1. Generalmente, muchos de estos elementos son épicas; sin embargo, deben ser lo suficientemente pequeñas como para caber en un ciclo de lanzamiento y pueden completarse en dos o más sprints. Estas épicas se denominan normalmente funcionalidades o épicas de funcionalidad. Estas épicas de funcionalidad deben especificarse con el formalismo de rol de usuario, acción, valor y criterios de aceptación que se utiliza para especificar historias, pero en este caso se captura una funcionalidad mayor representada por una épica de funcionalidad. Las épicas de funcionalidad se dividen en historias —lo suficientemente pequeñas como para caber en un sprint— antes del sprint en el que se implementará cada historia.

En el horizonte temporal de todo un ciclo de lanzamientoInvertir en historias para un ciclo de lanzamiento completo tiene bajos rendimientos porque se requiere mucho esfuerzo para asegurar que los criterios de INVEST se cumplan correctamente para una gran cantidad de historias que cubren un ciclo de lanzamiento completo, y es mucho más probable que esas historias cambien durante el ciclo de lanzamiento que abarca varios sprints; por lo tanto, este tipo de INVEST puede no producir los resultados esperados, ya que es muy probable que las historias cambien durante todo un ciclo de lanzamiento después de haber sido especificadas.

Las funcionalidades épicas en un ciclo de lanzamiento pueden y deben estimarse en términos de tamaño relativo, sin necesidad de desglosarlas en historias individuales. Esta estimación a nivel de épica se realiza comparando sus tamaños relativos. Este método garantiza que todas las épicas e historias se estimen en una unidad común de "puntos de historia normalizados", que representa la misma escala para toda la organización en todos los proyectos, sprints, ciclos de lanzamiento y equipos. No es necesario estimar las épicas en "unidades" o "números de tamaño", que no tienen relación con los puntos de historia.

Aún tiene sentido priorizar las funcionalidades épicas en un ciclo de lanzamiento para decidir cuáles se programarán en el sprint uno, dos, tres, etc. Sin embargo, esta asignación puede cambiar a medida que se completa cada sprint y se obtiene más información y aprendizaje.

Horizonte de planificación del producto, granularidad de los elementos de trabajo, estimación y orden de clasificación

Si el horizonte de planificación del producto abarca varios ciclos de lanzamiento (normalmente de seis a veinticuatro meses) y se extiende más allá del ciclo de lanzamiento actual, las tareas se presentan con un nivel de detalle mayor, como se muestra en la región gris inferior de la Figura 1. Estas grandes épicas o superépicas requieren dos o más ciclos de lanzamiento para su finalización. Estas superépicas pueden describirse en lenguaje sencillo (texto con viñetas), mediante maquetas de pantalla, vídeos, prototipos o cualquier otra forma de expresión que permita transmitir su propósito y valor. Estas superépicas se dividen en épicas de funcionalidad (lo suficientemente pequeñas como para caber en un solo ciclo de lanzamiento) antes del ciclo de lanzamiento en el que se implementará cada épica de funcionalidad.

En el horizonte temporal de múltiples ciclos de lanzamiento, invertir en historias ofrece rendimientos aún menores en comparación con invertir en historias para un solo ciclo de lanzamiento. Este tipo de inversión no producirá los resultados esperados, ya que es muy probable que las historias cambien a lo largo de un periodo mucho más extenso, que abarca múltiples ciclos de lanzamiento.

Las grandes epopeyas o superepopeyas que requieren varios ciclos de lanzamiento para su implementación pueden y deben estimarse en términos de tamaño relativo, pero sin invertir el esfuerzo necesario para descomponerlas en epopeyas de características y, a su vez, en historias. Esta estimación puede realizarse comparando los tamaños relativos de las grandes epopeyas.

Puede que no tenga mucho sentido jerarquizar grandes épicas en un horizonte de planificación de producto con múltiples ciclos de lanzamiento, ya que esta asignación muy probablemente cambiará en un horizonte temporal mayor; además, no importa si una gran épica que se desarrollará dentro de seis a veinticuatro meses se jerarquiza en el puesto 125.^th o 126^thEse nivel de precisión en el orden de clasificación no es necesario.

Utilizo la estrategia de INVERTIR en historias y tareas SMART únicamente para el backlog del próximo sprint, pero no para el backlog de lanzamiento ni el del producto. INVIERTE justo a tiempo en el próximo sprint, según lo planifiques. INVERTIR en historias y tareas a largo plazo dará resultados poco satisfactorios.

Analiza detenidamente el backlog del producto.

Rara vez hay tiempo o recursos suficientes para hacerlo todo. Por lo tanto, los equipos ágiles deben priorizar (o, más precisamente, ordenar por rango) en qué historias centrarse y cuáles, con el menor rango, podrían quedar fuera del alcance al acercarse el final del sprint. En los proyectos de desarrollo ágil, se recomienda ordenar el backlog de forma lineal, en lugar de usar una priorización general donde las historias y épicas se agrupan en un número reducido de categorías de prioridad, como baja, media, alta y crítica. El ordenamiento lineal (es decir, 1, 2, 3, 4… n) evita la inflación de prioridades, fomenta la honestidad y obliga a tomar decisiones sobre lo que realmente importa. Además, desalienta la actitud desmedida que se produce cuando el área de negocio insiste en que todo es de alta prioridad o de igual importancia.

Cabe señalar que las epopeyas y los relatos son conceptualmente diferentes y no deben mezclarse ni agruparse al elaborar una clasificación. La clasificación de las epopeyas es independiente de la clasificación de los relatos.

La responsabilidad de la priorización ágil se comparte entre todos los miembros del equipo; sin embargo, el esfuerzo de priorización lo lidera el propietario del producto. Al igual que DEEP, INVEST y SMART, DIVE es una palabra significativa en inglés, y también un acrónimo. Los elementos del backlog del producto deben ser orden lineal basado en la BUCEO criterios, lo que requiere una consideración cuidadosa de los cuatro factores recogidos en el acrónimo DIVE:

• DDependencias: Incluso después de minimizar las dependencias entre historias o épicas (lo cual siempre es recomendable), aún pueden existir algunas dependencias inevitables que afectarán la prioridad. Si la tarea A depende de B, B debe tener una prioridad mayor que A.
• IProtéjase contra los riesgos: riesgos empresariales y técnicos
• Empresa Value
• Estimado Eesfuerzo

_{Tabla 1: Resumen para gestionar un backlog de producto PROFUNDO con INVESTING inteligente y DIV[E]Ing cuidadoso}

Espero que la frase “El backlog del producto es PROFUNDO; INVIERTE con sabiduría y PROFUNDIZA con cuidado” te resulte una regla mnemotécnica útil para recordar las características clave de un backlog de producto bien gestionado.

Obtenga más información sobre cómo la agilidad puede ayudar a su empresa a alcanzar el éxito con Digital.ai Agility.