Los mejores consejos de expertos en metodología Scrum y Agile sobre la gestión de su backlog del producto

Primero, definamos claramente un backlog del producto. Scrum organiza los proyectos en una serie de períodos de trabajo enfocados llamados Sprints, y cada Sprint suele durar dos semanas. Antes de que comience el sprint, el equipo y el Scrum Master (que funciona como una especie de entrenador) crean su backlog de Sprint, que es una lista de lo que pretenden lograr en el siguiente Sprint. 

El backlog de Sprint se extrae del backlog del producto más general, que es una lista completa de todas las características y funciones que deben agregarse al producto. El Dueño del Producto se encarga de priorizar el backlog del producto. (El Dueño del Producto también representa las necesidades del cliente y otras partes interesadas y guía el trabajo del equipo de desarrollo). El backlog del producto está clasificado verticalmente, por lo que las tareas más importantes aparecen en la parte superior, y el equipo Scrum suele seleccionar elementos del backlog en función de la prioridad. El backlog del producto cambiará y evolucionará con el tiempo en función de las solicitudes de los usuarios, las necesidades empresariales y las tendencias tecnológicas más amplias.

Como nota aparte, también puede usar un backlog del producto en otro marco Agile llamado Kanban. Aunque Kanban se basa en limitar el trabajo en curso (WIP) en lugar de usar sprints de longitud fija (Scrum), la información de este artículo también puede aplicarse a los proyectos Kanban.

Un backlog de producto bien desarrollado garantiza que su trabajo sea productivo y valioso, que el producto satisfaga las necesidades de los clientes y que se alinee con los objetivos de su organización. Al igual que con su lista personal de pendientes, debe gestionar constantemente el backlog de su producto. Este proceso a menudo se denomina refinación o limpieza del backlog del producto. Las prioridades cambian, las tareas se logran y las ideas se descartan. Sin actualizar su backlog, se desorganizará y no le ayudará a mantenerse encaminado.

Para empezar a crear un backlog del producto, algunos expertos en Agile recomiendan comenzar con una hoja de ruta del producto. Este es un plan estratégico que ofrece una perspectiva a largo plazo para su producto.  Roman Pichler, capacitador experto en gestión de productos Agile, señala que muchos dueños y gerentes de productos se centran demasiado en los detalles de las funciones en sus hojas de ruta y no lo suficiente en la visión general. Desarrolló una plantilla de hoja de ruta orientada a objetivos que enfatiza el objetivo del producto y las funciones necesarias para alcanzar el objetivo.
 
Si bien su hoja de ruta puede incluir objetivos a largo plazo para varias publicaciones, el backlog del producto debería centrarse en listar el trabajo para la siguiente versión con mayor detalle. Las futuras versiones deben colocarse más abajo y expresarse con menos detalle. Luego, tome la información de la hoja de ruta y tradúzcala en tareas y elementos de trabajo. 

Cada producto debe tener su propio backlog. Si su producto es bastante grande o forma parte de un conjunto de productos interrelacionados, puede resultar confuso determinar lo que constituye un producto. El experto en metodología Agile Kenneth Rubin, consultor de Innolution, afirma que el objetivo es minimizar la cantidad de equipos de componentes y backlogs de componentes, por lo que prefiere usar un backlog siempre que sea posible. Sin embargo, para proyectos muy grandes con decenas o cientos de equipos, esto no es práctico, y en esos casos los backlogs jerárquicos se pueden usar con un backlog para funciones a gran escala y un backlog separado para cada área de trabajo relacionada.

Los elementos de trabajo del backlog del producto a menudo se expresan en lo que se denominan historias de usuario, una descripción de cómo funcionará la función desde el punto de vista del usuario. Una historia de usuario es lo suficientemente pequeña como para que se pueda lograr dentro de un Sprint. 

Chuck Kroll, un coach de Agile que capacitó a los equipos de Fidelity Investments, recomienda una fórmula tradicional para las historias de usuario:  "Como (tipo de usuario, como cliente), quiero (objetivo) para que (razón)", resume Kroll. "Esto deja en claro quién utilizará la función, qué involucra y qué valor comercial ofrece".

Historia de usuario frente a Epic del usuario: ¿Qué tan detallados deben ser los elementos del backlog?

Una historia mucho más grande se llama "epic" y puede tomar varios Sprints para lograrse. Los epics deben dividirse en historias antes de que comience el trabajo. 

Mike Cohn, fundador de Mountain Goat Software que ofrece capacitación en Agile y Scrum, ofrece este ejemplo de un epic: una empresa hotelera quiere que un sistema determine lo máximo que puede cobrar por una habitación de hotel dependiendo de variables como las tarifas de la competencia, la temporada, etc. "Como operador del hotel, quiero establecer la tarifa óptima para las habitaciones de mi hotel". Eso se divide en historias de usuario como "como operador de hoteles, quiero establecer la tarifa óptima para las habitaciones en función de los precios del año anterior", y "Como operador de hotel, quiero establecer la tarifa óptima para las habitaciones en función de lo que cobran los hoteles comparables a los míos».

A medida que prepara historias de usuario para el backlog del producto, los elementos de mayor prioridad deben tener más detalles para ayudar al equipo a ejecutarlos con precisión. Esto puede incluir diagramas que muestran el flujo de trabajo de una función o una descripción de sus detalles. 
"El consejo más importante que veo que se pasa por alto es que los elementos del backlog del producto no todos necesitan el mismo nivel de detalle", comenta Cohn. "Los elementos que entran en el próximo Sprint deben ser moderados. Los elementos más detallados deben ser progresivamente menos detallados".

Imagine la siguiente historia de usuario: Como visitante del sitio web, quiero poder comprar un boleto de avión al precio más barato que se ofrece a mi aeropuerto de primera elección o aeropuertos cercanos. Dado que esto se acerca a la parte superior del backlog del producto, debe agregar detalles a la historia de usuario, como: la función debe verificar las tarifas de todos los aeropuertos dentro de una distancia de 100 millas; debería darme la capacidad de ordenar las tarifas a distancia del aeropuerto de primera elección, así como por precio. 

Pichler recomienda que el ciclo de vida del producto sea importante para decidir qué tan granular es hacer el backlog del producto. Los productos jóvenes deben tener backlogs más cortos y menos detallados, que le permitan experimentar con nuevas ideas y cambiar su producto con frecuencia para optimizarlo. Por otro lado, los productos más antiguos y estables se benefician de un backlog más detallado porque es más capaz de anticipar cómo evolucionará el producto.

El ciclo de publicación es otro factor en el backlog de su producto. A medida que empiece a trabajar en una nueva versión o en una gran publicación, habrá más incógnitas y lo que aprenda generará cambios potencialmente importantes en su backlog. Así que un backlog del producto más corto y menos detallado tiene sentido al principio del ciclo de publicación, explicó Pichler. 

A Bill Wake, consultor de Agile que ahora trabaja con Industrial Logic Inc, se le ocurrió un modelo ampliamente usado y mnemónico para las características de una buena historia de usuario utilizando el acrónimo INVEST:

I - Independiente - Las historias no deben superponerse e idealmente se pueden implementar en cualquier orden.
N - Negociable - La historia captura la esencia, pero no los detalles, que son acordados por los participantes.
V - Valiosa - La historia ofrece un valor claro al cliente. 
E - Estimable - Le permite evaluar el esfuerzo involucrado. Puede ser una estimación del tiempo o en lo que se denominan puntos de historia, una unidad de medida arbitraria que califica la complejidad relativa (como XS, S, M, L, XL o 1, 2, 4, 8, 16). 
S - Sucinta - "Las buenas historias tienden a ser pequeñas", afirmó Wake. Esto significa que la historia debe llevarse a cabo en (como máximo) unas pocas semanas laborales de 40 horas de una persona dedicada, o divididas entre los miembros del equipo. 
T - Testeable - La historia de usuario debe ser medible o procesable de alguna manera, según Ulf Eriksson, fundador y propietario del producto de la plataforma de pruebas de TI ReQtest.

Cohn destacó que no todos los elementos del backlog deben ser una historia de usuario. "Me encuentro con equipos que piensan que cada elemento del backlog del producto debe ser una historia de usuario. Las historias de usuario son excelentes, cuando hay usuarios alrededor. Pero algunas cosas que pertenecen a un backlog del producto no son necesariamente directamente para los usuarios. Esos elementos no necesitan escribirse como historias de usuario". 

Esto incluiría el trabajo en el back-end u otras tareas que están distantes de los usuarios. Cohn recomienda describir estas tareas utilizando la sintaxis de desarrollo basado en funciones (FDD) (verbo + resultado + objeto, es decir: "validar la contraseña de un usuario").
Los cuatro tipos de elementos que se suelen encontrar en los backlogs de Scrum son las funciones, los errores, el trabajo técnico y la adquisición de conocimientos. Las funciones por lo general se prestan a expresarse como historias de usuario mientras que los otros elementos no. 

Si recién está empezando, no se preocupe: no es necesario que inicie su proyecto con un backlog del producto perfecto. Empiece por hacer una lluvia de ideas sobre las tareas necesarias, y esto proporcionará suficiente información para su primer Sprint. Luego, puede ampliar el backlog de su producto a medida que obtenga más información sobre el producto, las necesidades de los usuarios y los comentarios.

"Mi consejo principal con respecto a los backlogs del producto sería mantenerlos simples. Es solo una estructura ordenada de desglose de productos", commenta Laurens Bonnema, consultora de Agile de Xebia en los Países Bajos.

C.J. Boat, líder de equipo Agile para el mercado de seguros Ensurem, estuvo de acuerdo. "¡Coloquen expectativas razonables! Si deja que el backlog se vuelva demasiado masivo o no organiza su trabajo correctamente, el backlog y los sprints pueden volverse tan atiborrados de cosas que se desmoronarán", advirtió. 

Una vez que haya agregado las tareas, es hora de ordenar el backlog del producto. Coloque el trabajo más importante por encima del trabajo menos importante. Puede hacerlo en función de su calificación de prioridad, haciendo juicios a medida que avanza respecto a cómo clasificar los elementos con la misma calificación de prioridad.

"A medida que agregues tareas a su backlog, asígneles una calificación de prioridad inicial", recomienda Kevin Lonergan, consultor principal de gestión de proyectos de PMIS Consulting en Gran Bretaña. "Una prioridad simple de tres niveles hará lo siguiente: 1 - crítico para alcanzar los objetivos empresariales, 2 - útil pero no crítico, 3 - si estos elementos se hacen, es una bonificación".

Algunos profesionales dicen que un mejor método consiste en ordenar la lista en otros criterios, como el riesgo, el ROI, el costo-beneficio, un modelo de bucket como MoSCoW (debe tener, debería tener, podría tener, no tendrá), el impacto que una historia tiene en otra, el tiempo estimado para implementar o las dependencias.

Bonnema de Xebia favorece el método del trabajo más corto ponderado primero (Weighted Shortest Job First o WSJF), escrito por Donald Reinertsen en "The Principles of Product Development Flow" y desarrollado más adelante por Dean Leffingwell, creador del Marco Agile Escalado. Es una fórmula para priorizar el backlog del producto en función de la duración de la tarea y una ponderación del costo del retraso. "No he encontrado una mejor manera de priorizar los backlogs de manera coherente en todos los niveles correctamente que el WSJF", comparte Bonnema. Las tareas permanecen en el backlog del producto hasta que se finalizan o hasta que el propietario del producto decide que ya no son necesarias. 

Para determinar cuándo se completa una historia de usuario y se puede eliminar del backlog, los equipos deben desarrollar una "definición de completado" estandarizada. Estos son los criterios de aceptación de una función que garantiza que todos los miembros del equipo sepan qué se espera del trabajo que realizan. Kelly Waters, autora de All About Agile cree que "completado" debería significar que se puede enviar. Jeff Sutherland, CEO de Scrum Inc., utiliza la popular frase Agile "completamente completado", lo que significa que al final del sprint, la codificación se ha completado y las pruebas de software se finalizan a nivel de función sin errores. Cuando se cumple la definición de completado de su equipo, se puede mover un elemento del backlog del producto a la columna completado.

Ahora que ya sabe lo que es un backlog del producto y lo que pertenece y no a uno, aquí tiene una lista de verificación para que pueda elaborar su primer backlog de producto:

1. El dueño del producto está a cargo del backlog del producto. Si es usted, significa que es el responsable de crear el backlog del producto, pero no es necesario que sea la única persona involucrada. Los miembros del equipo Scrum y otras partes interesadas pueden participar.
2. Recuerde que el backlog del producto es la lista completa de todas las historias de usuario y otros elementos de trabajo del producto.
3. Piense en cada tarea que pueda y escríbala. Sea lo más específico posible y pida comentarios de todas las partes relevantes de su organización y comentarios de los clientes.
4. Cree historias desde el punto de vista del usuario e incluya una acción y un motivo. (Como _, quiero _, así que_.) Piense en todos los usuarios diferentes. Escríbalas en tarjetas de notas o utilice una herramienta en línea. Aplique etiquetas para que la publicación planificada sea clara.
5. Incluya correcciones de errores, adquisición de conocimientos y trabajo técnico.
6. Como propietario del producto, solo califica la importancia de cada elemento para la organización que va desde muy arriba hasta muy abajo u otro método. Puede realizar encuestas a los usuarios para tener una base sólida para estas decisiones. 
7. Para cada elemento de trabajo, también proporcione una estimación de cuánto esfuerzo involucra.
8. Cómo clasificar el backlog del producto. 
9. El trabajo que el equipo se compromete a abordar en un sprint es el backlog del Sprint, y esto es independiente del backlog del producto. El backlog del sprint no cambia durante el sprint. Los elementos se consideran completos y se eliminan de los backlogs del sprint y del producto cuando están "completamente completados".
10. Cuando llegue el trabajo nuevo, añádalo al backlog del producto en la posición correcta. Cuando recopile información nueva, como comentarios, puede eliminar o reordenar elementos. 

Cuando haya terminado, debería terminar con algo como esto:

En este momento, las felicitaciones están en orden si redactó con éxito el primer backlog del producto y consiguió que el equipo Scrum trabajara en un lote de valiosas historias de usuario en un sprint. Pero aún no es el momento de relajarse. 

Una vez creado, el backlog del producto debe mantenerse y actualizarse continuamente. Este proceso, también conocido como limpieza o refinamiento del backlog del producto, mantiene su backlog actualizado en función de la información del mercado, los usuarios, el equipo del producto y la gestión de su organización. Mantenerse al tanto del trabajo pendiente, le asegura de que el equipo de desarrollo siempre esté poniendo su esfuerzo en las cosas correctas, que está listo para el siguiente Sprint y que utiliza bien sus recursos y entrega el mejor producto posible a su cliente. 

Una forma sencilla de recordar el objetivo del proceso de refinamiento del backlog del producto es el acrónimo DEEP. Su objetivo es asegurarte de que el backlog de su producto siempre sea DEEP (profundo): 

D - Detallado adecuadamente para que los elementos en la parte superior de la lista tengan más detalles que los de la parte inferior. 
E- Estimado- Cada elemento del backlog del producto, o al menos los involucrados en la próxima publicación, deben estimarse según los puntos de historia o el tiempo. A medida que su equipo se carga de más trabajo, su velocidad (la velocidad a la que termina los elementos del backlog del producto) se volverá más clara y facilitará la estimación.
E- Emergente - Esto significa que el backlog del producto se adapta a los nuevos elementos o información que surjan.
P- Priorizado- Todos los elementos del backlog del producto se ordenan con los más importantes en la parte superior. 

Incluso con los mejores esfuerzos para mantener el backlog de su producto funcionando sin problemas, pueden surgir fallas. Los expertos en metodología Agile que han trabajado con muchos equipos y en diversos proyectos tienen consejos para solucionar problemas y evitarlos.

El coach Kroll señala que los problemas más comunes que ve surgen de la falta de participación de los patrocinadores del proyecto, quienes necesitan participar a diario, y una tendencia a presionar al equipo para que cumpla con los objetivos de tiempo que no están impulsados por el rendimiento real del equipo. La solución es que los gerentes cambien de una mentalidad tradicional de proyecto "planificado frente a real" a un enfoque Agile. 

Jonathan Roger, gerente de proyectos y Scrum Master de AndPlus, recomienda mantener un "icebox" en la parte inferior del backlog del producto para las ideas no priorizadas y sin refinar. "Los dueños del producto pueden realizar un seguimiento de las funciones deseadas a largo plazo sin la presión de mantenerlos en un orden prioritario, y los equipos pueden agregar sus ideas potenciales para la revisión del propietario del producto. También sirve como un buen punto de partida para las solicitudes de funciones de clientes o grupos de interés". 

Lonergan de PMIS Consulting recomienda una cuidadosa selección del dueño del producto como clave para el éxito. "Una persona debe desempeñar el rol de dueño del producto y no un comité", resaltó. “Son los dueños del backlog del producto. Asegúrese de que el dueño del producto impulse el desarrollo del backlog". 

"El (error) n.° 1 es sin duda nombrar a la persona equivocada como dueño del producto debido a una falta de autoridad, de conocimiento, de tiempo, etc", agregó Lonergan. 

De la administración básica de tareas y de proyectos hasta la administración compleja de recursos y portafolios, Smartsheet lo ayuda a mejorar la colaboración y acelerar el trabajo. Esto lo empodera para lograr más. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas clave y obtenga visibilidad en tiempo real acerca de trabajo gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en menos tiempo. Pruebe Smartsheet gratis hoy mismo.