Cómo participa el backlog de productos en el marco de su proyecto
Primero, definamos claramente un backlog de productos. Scrum organiza los proyectos en una serie de períodos de trabajo enfocado llamados “Sprints” y cada uno suele durar dos semanas. Antes de que comience el sprint, el equipo y el Scrum Master (quien funciona como asesor) crean su backlog de sprint, que es una lista de lo que pretenden lograr en el próximo sprint.
El backlog de sprint se extrae del backlog de productos general, que es una lista completa de todas las características y funcionalidades que se deben agregar al producto. El propietario del producto es quien se encarga de priorizar el backlog de productos. (El propietario del producto también representa las necesidades del cliente y otras partes interesadas, y guía el trabajo del equipo de desarrollo). El backlog de productos se clasifica verticalmente, por lo que las tareas más importantes se enumeran en la parte superior, y el equipo de Scrum generalmente selecciona elementos del backlog en función de la prioridad. El backlog de productos cambia y evoluciona con el tiempo en función de las solicitudes de los usuarios, las necesidades de la empresa y las tendencias tecnológicas generales.
Como nota adicional, también puede hacer uso de un backlog de productos en otro marco de Agile llamado Kanban. Si bien 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 se puede aplicar a los proyectos de Kanban.
Un backlog de productos bien formado garantiza que su trabajo sea productivo y valioso, que el producto satisfaga las necesidades de los clientes y que se alinee con las metas de su organización. Al igual que con su lista personal de “tareas pendientes”, debe administrar su backlog de productos constantemente. A este proceso a menudo se le dice “refinar” o “limpiar” el backlog de productos. Las prioridades cambian, las tareas se cumplen y las ideas se descartan. Si no actualiza su backlog, este se desorganizará y no le servirá para mantenerse en el buen camino.
Cómo crear su primer backlog de productos
Para empezar a crear un backlog de productos, algunos expertos de Agile recomiendan comenzar con una hoja de ruta del producto. Se trata de un plan estratégico que ofrece una perspectiva a largo plazo para su producto. Roman Pichler, un capacitador experto en gestión de productos Agile, afirmó que muchos propietarios y gerentes de productos se centran demasiado en los detalles de las características en sus hojas de ruta y no se enfocan lo suficiente en la visión más general. Desarrolló una plantilla de hoja de ruta orientada a las metas que enfatiza la meta del producto y las características necesarias para alcanzar esa meta.
Si bien su hoja de ruta puede incluir metas a largo plazo para varias versiones, el backlog de productos debe centrarse en la lista de trabajo para la próxima versión con mayor detalle. Las versiones futuras deben colocarse más abajo y expresarse con menos detalle. Luego, tome la información de la hoja de ruta y conviértala en tareas y elementos de trabajo.
Cada producto debe tener su propio backlog. Si su producto es bastante grande o parte de un conjunto de productos interrelacionados, puede ser confuso determinar qué constituye un producto. El experto de Agile Kenneth Rubin, consultor de Innolution, dice que la meta es minimizar el número de equipos de componentes y backlogs de componentes, por lo que prefiere utilizar un backlog de componentes 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 características a gran escala y un backlog separado para cada área de trabajo relacionada.
Las historias de usuario están en el centro del backlog de productos
Los elementos de trabajo en el backlog de productos a menudo se expresan en lo que se llaman historias de usuario, una descripción de cómo funcionará la característica 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 instructor de Agile que capacitó equipos en Fidelity Investments, recomienda una fórmula tradicional para las historias de usuario: “Como usuario (como un cliente), quiero (meta) para (motivo)”, dijo Kroll. “Esto deja en claro quién usará la función, lo que implica y qué valor comercial ofrece”.
Historia de usuario vs. épica de usuario: ¿qué tan detallados deben ser los elementos de backlog?
Una historia mucho más grande se llama una “épica” y puede tomar varios sprints para lograrse. Las épicas necesitan dividirse en historias antes de que el trabajo pueda comenzar.
Mike Cohn, fundador de Mountain Goat Software, quien ofrece capacitación de Agile y Scrum, nos da este ejemplo de una épica: una empresa hotelera quiere un sistema para determinar lo máximo que puede cobrar por una habitación de hotel según variables como las tarifas de la competencia, la temporada, etc. “Como hostelero, quiero establecer la tarifa óptima para las habitaciones de mi hotel”. Eso se divide en historias de usuario como por ejemplo: “Como hostelero, quiero establecer la tarifa óptima para las habitaciones en función de los precios del año anterior” y “Como hostelero, quiero establecer la tarifa óptima para las habitaciones en función de lo que están cobrando los hoteles equiparables con el mío”.
A medida que prepare las historias de usuario para el backlog de productos, los elementos de mayor prioridad deben tener más detalles para ayudar al equipo a ejecutarlos con precisión. Esto puede incluir diagramas que muestren el flujo de trabajo de una característica 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 de productos no necesitan todos el mismo nivel de detalle”, dijo Cohn. “Los elementos que lleguen al próximo sprint deben ser moderadamente detallados. Los elementos para más adelante deben ser progresivamente menos detallados”.
Imagine la siguiente historia de usuario: Como visitante de un sitio web, quiero poder comprar un billete de avión al precio más barato en oferta en el aeropuerto que sea mi primera elección o en aeropuertos cercanos. Debido a que esto se acerca a la parte superior del backlog de productos, debe agregar detalles a la historia del usuario, tales como: la función debe verificar las tarifas para todos los aeropuertos dentro de las 100 millas; debe darme la capacidad de ordenar las tarifas por distancia desde el aeropuerto de primera elección, así como por precio.
Pichler recomienda que el ciclo de vida del producto es importante para decidir qué tan granular debe ser el backlog de productos. 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 usted es más capaz de anticipar cómo evolucionará el producto.
El ciclo de lanzamiento es otro factor en el backlog de productos. A medida que comience a trabajar en un nuevo lanzamiento o en uno importante, hay más incógnitas y lo que aprenda resultará en cambios potencialmente grandes en su backlog. Por lo tanto, un backlog de productos más corto y menos detallado tiene sentido al principio del ciclo de lanzamiento, explicó Pichler.
A Bill Wake, un consultor de Agile que ahora trabaja con Industrial Logic Inc, se le ocurrió un modelo ampliamente utilizado y mnemotécnico para las características de una buena historia de usuario utilizando el acrónimo INVEST (en inglés):
I - Independiente: Las historias no deben solaparse 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 - Valioso: La historia ofrece un claro valor al cliente.
E - Estimable: Usted es capaz de evaluar el esfuerzo involucrado. Esto puede ser una estimación de tiempo o en lo que se llama puntos de la historia, una unidad de medida arbitraria que clasifica la complejidad relativa (como XS, S, M, L, XL o 1, 2, 4, 8, 16).
S - Pequeño: “Las buenas historias tienden a ser pequeñas”, dijo Wake. Esto significa que la historia se debe completar en (como máximo) unas pocas semanas de trabajo de 40 horas por parte de una persona dedicada, o dividida 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.
Otros elementos que pertenecen al backlog de productos
Cohn enfatizó que no todos los elementos en el backlog deben ser una historia de usuario. “Conozco equipos que piensan que cada elemento del backlog de productos debe ser una historia de usuario. Las historias de usuario son geniales, cuando hay usuarios alrededor. Pero algunas cosas que pertenecen a un backlog de productos no son necesariamente directamente para los usuarios. Esos elementos no necesitan ser escritos como historias de usuario”.
Esto incluiría el trabajo administrativo u otras tareas que ocurren lejos de los usuarios. Cohn recomienda describir estas tareas mediante sintaxis de desarrollo basado en características (FDD) (verbo + resultado + objeto, es decir, “Validar la contraseña de un usuario”).
Los cuatro tipos de elementos que se encuentran comúnmente en los backlogs de Scrum son características, errores, trabajo técnico y adquisición de conocimientos. Las características generalmente se prestan a expresarse como historias de usuario, mientras que los otros elementos no.
Si recién está comenzando, no se preocupe: no necesita comenzar su proyecto con un backlog de productos perfecto. Comience por hacer una lluvia de ideas sobre las tareas necesarias, y esto proporcionará suficiente información para su primer sprint. A continuación, puede ampliar su backlog de productos a medida que aprende más sobre el producto, las necesidades del usuario y los comentarios.
“Mi principal consejo con respecto a los backlogs de productos es mantenerlos simples. Se trata solo de una estructura de desglose de productos ordenada”, dijo Laurens Bonnema, consultor de Agile en Xebia en los Países Bajos.
C.J. Boat, un líder de equipo Agile para el mercado de seguros Ensurem, está de acuerdo. “¡Tenga expectativas razonables! Si deja que su backlog se vuelva demasiado masivo, o no organiza adecuadamente su trabajo, el backlog y los sprints pueden llegar a estar tan abarrotados que se desmoronarán”, dijo.
Priorización y orden del backlog de productos
Una vez que haya agregado las tareas, es hora de ordenar el backlog de productos. Coloque el trabajo más importante por encima del trabajo menos importante. Puede hacer esto en función de su clasificación de prioridad, tomando decisiones a medida que avanza sobre cómo clasificar los elementos con la misma clasificación de prioridad.
“A medida que agrega tareas a su backlog, le asigna una clasificación de prioridad inicial”, dijo Kevin Lonergan, consultor principal de gestión de proyectos en PMIS Consulting, Gran Bretaña. “Una simple prioridad de tres niveles funciona: 1 - fundamental para lograr las metas comerciales, 2 - útil, pero no crítica, 3 - sería una ventaja si estos elementos se hacen”.
Algunos profesionales dicen que un mejor método es ordenar la lista con otros criterios, como riesgo, ROI, costo-beneficio, un modelo de cuadrados como MoSCoW (debe tener, debería tener, podría tener, no tendrá), el impacto que una historia tiene en otra, el tiempo estimado para implementarse o las dependencias.
Bonnema de Xebia favorece el método Weighted Shortest Job First (WSJF), escrito por Donald Reinertsen en “The Principles of Product Development Flow” y desarrollado por Dean Leffingwell, creador del marco a escala Agile. Es una fórmula para priorizar el backlog de productos 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 consistentemente los backlogs en todos los niveles correctamente que WSJF”, dijo Bonnema. Las tareas permanecen en el backlog de productos hasta que se completan 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 estandarizada de lo que significa una tarea “hecha”. Este es el criterio de aceptación de una función que garantiza que todos los miembros del equipo sepan lo que se espera del trabajo que realizan. Kelly Waters, autora de All About Agile cree que algo “hecho” debe significar que se puede enviar. Jeff Sutherland, CEO de Scrum Inc., utiliza la popular frase Agile “hecho-hecho”, lo que significa que al final del sprint, la codificación se completó y las pruebas de software se terminan en el nivel de característica sin errores. Cuando se cumple la definición de “hecho” de su equipo, un elemento se puede mover desde el backlog de productos a la columna de completado.
Paso a paso: cómo crear un backlog de productos
Ahora que sabe qué es un backlog de productos, y qué pertenece a uno y qué no, aquí está su lista de verificación para crear su primer backlog de productos:
- El propietario del producto es quien se encarga del backlog de productos. Si ese es usted, es el encargado de crear el backlog de productos, pero no necesita ser la única persona involucrada. Los miembros del equipo de Scrum y otras partes interesadas pueden participar.
- Recuerde que el backlog de productos es la lista completa de todas las historias de usuario y otros elementos de trabajo para el producto.
- Piense en todas las tareas que pueda y anótelas. Sea lo más específico posible y pida información de todas las partes relevantes de su organización y comentarios de los clientes.
- Elabore historias desde el punto de vista del usuario e incluya una acción y un motivo. (Como _, quiero _, para_.) Piense en todos los usuarios diferentes. Escríbalas en las fichas o utilice una herramienta en línea. Aplique etiquetas para que la versión planificada quede clara.
- Incluya correcciones de errores, adquisición de conocimientos y trabajo técnico.
- Como propietario del producto, solo usted califica la importancia de cada elemento para la organización, que va desde muy alto a muy bajo, u otro método. Puede encuestar a los usuarios a fin de tener una base sólida para estas decisiones.
- Para cada elemento de trabajo, también proporcione una estimación de cuánto esfuerzo se requiere.
- Clasifique el backlog de productos.
- El trabajo que el equipo se compromete a abordar en un sprint es el backlog del sprint, y esto es independiente del backlog de productos. El backlog del sprint no cambia durante el sprint. Los elementos se consideran completos y se eliminan de los backlogs de productos y de sprint cuando están “hechos”.
- Cuando aparezca un nuevo trabajo, agréguelo al backlog de productos en la posición correcta. Cuando recopile información nueva, como comentarios, podrá eliminar o reordenar elementos.
Cuando haya terminado, debe terminar con algo parecido a esto:
En este punto, celebramos si redactó con éxito su primer backlog de productos y consiguió que su equipo de Scrum trabajara en un lote de valiosas historias de usuario en un sprint. Pero todavía no es el momento de relajarse.
Cómo mantener actualizado el backlog de productos
Una vez creado, el backlog de productos debe mantenerse y actualizarse continuamente. Este proceso, también conocido como limpieza o refinamiento del backlog de productos, mantiene actualizado el backlog de productos en función de la información del mercado, los usuarios, el equipo de productos y la administración de su organización. Al mantenerse al día con la limpieza del backlog, se asegura de que el equipo de desarrollo siempre esté poniendo su esfuerzo en las cosas correctas, que todo esté listo para el próximo sprint y que está usando bien sus recursos y entrega el mejor producto posible a su cliente.
Una manera fácil de recordar el objetivo del proceso de refinamiento del backlog de productos es el acrónimo en inglés DEEP. Su meta es asegurarse de que su backlog de productos sea siempre DEEP:
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 de productos, o al menos los involucrados en el próximo lanzamiento, debe estimarse por puntos de historia o tiempo. A medida que su equipo termina más trabajo, su velocidad (la rapidez con la que termina los elementos del backlog de productos) se volverá más clara y hará que la estimación sea más fácil.
E: Emergente. Esto significa que el backlog de productos se adapta a los nuevos elementos o información que surgen.
P: Priorizado. Todos los elementos en el backlog de productos se ordenan colocando los más importantes en la parte superior.
Los mejores consejos de los profesionales sobre la gestión de su backlog de productos
Incluso si hace el máximo esfuerzo por mantener su backlog de productos funcionando sin problemas, pueden surgir problemas técnicos. Los expertos de Agile que han trabajado con muchos equipos y en una variedad de proyectos tienen consejos para solucionar problemas y evitarlos.
El instructor de Agile Kroll dijo que los problemas más comunes que ve surgen de la falta de participación de los patrocinadores del proyecto, que necesitan involucrarse 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 vs. real” a un enfoque Agile.
Jonathan Roger, gerente de proyectos y maestro de Scrum para AndPlus, recomienda mantener una “caja de hielo” en la parte inferior del backlog de productos, para las ideas no priorizadas y sin pulir. “Los propietarios de productos pueden realizar un seguimiento de las características deseadas a largo plazo sin la presión de mantenerlas en un orden de prioridad, 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 características de los clientes o las partes interesadas”.
Lonergan de PMIS Consulting recomienda una cuidadosa selección del propietario del producto como clave para el éxito. “Una persona debe desempeñar el papel de propietario del producto, no un comité”, subrayó. “Esa persona está a cargo del backlog de productos. Asegúrese de que el propietario del producto impulse el desarrollo del backlog”.
“El error número uno es sin duda nombrar a la persona equivocada como propietario del producto, debido a su falta de autoridad, conocimiento del dominio, falta de tiempo, etc.”, agregó Lonergan.
Mantenga y gestione fácilmente los backlogs de productos con Smartsheet
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.