3 Ejemplos de Backlog de Producto Bien Hechos (+ Qué No Hacer)
¿Alguna vez has mirado tu backlog y has querido borrarlo todo para empezar desde cero? Bueno, he sentido eso más de una vez, ya que construir y mantener los backlogs de producto no es tarea fácil. Pero, para mostrarte cómo hacer los backlogs correctamente e inspirarte a limpiar el tuyo, permíteme compartir contigo cuatro ejemplos excepcionales de backlog de producto.
¿De Qué Se Trata El Backlog De Producto En Ágil Y Scrum?
El backlog de producto es un documento vivo que contiene todos los elementos en los que el equipo de producto, el scrum master y el equipo de ingeniería planean trabajar para construir su producto.
Consiste en todo lo necesario para construir y mantener tu producto, incluyendo nuevas funcionalidades, tareas de deuda técnica, mejoras en los procesos técnicos de tu última retrospectiva, tareas de automatización QA y más.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
La característica principal de un backlog de producto es que es una lista priorizada donde los elementos en la parte superior tienen la máxima prioridad y el equipo debe tomarlos primero al planificar sus sprints (o cuando tienen espacio libre en su tablero kanban).
Backlog de Producto vs Sprint Backlog vs Hoja de Ruta del Producto: ¿Cuál Es la Diferencia?
En la gestión de proyectos ágil y la metodología Scrum, en particular, un backlog de producto no es la única lista de elementos que el Product Owner crea para tu equipo de desarrollo. También existen el Sprint Backlog y la Hoja de Ruta del Producto. Pero, ¿en qué se diferencian? Vamos a entenderlo.
Sprint Backlog: Es un subconjunto del backlog más grande y solo contiene los elementos que el equipo scrum ha incluido en el siguiente sprint u otro tipo de iteración como resultado de una reunión de planificación de sprint. Los elementos aquí suelen estar bien refinados e incluyen puntos de historia.
Hoja de Ruta del Producto: Es un documento de alto nivel y de visión global que muestra las funcionalidades principales y los hitos principales del producto. A diferencia del backlog, que es más táctico y contiene descripciones de funcionalidades, la hoja de ruta del producto es estratégica y sirve para mostrar a los miembros del equipo y a las partes interesadas hacia dónde se dirige el producto y cuáles son las áreas de enfoque prioritario.
Ahora que ya has conocido los conceptos clave, permíteme pasar directamente a explicar cómo gestionar tu backlog de producto (y cómo, ejem, no hacerlo).
Cómo NO Hacerlo Bien: Aquí Un Horrible Ejemplo de Backlog de Producto
Entender los antipatrón de crear y gestionar backlogs de producto es probablemente tan importante como aprender las mejores prácticas. La razón es que si no sabes que algo es un antipatrón, corres el riesgo de tenerlo en tu backlog y pensar que es algo normal y común.
Para repasar algunas de las prácticas que pueden disminuir significativamente la calidad de tu backlog, veamos el siguiente ejemplo.
Volviendo al ejemplo. Por favor, tómate tu tiempo para examinarlo detenidamente.
Parece horrible, ¿verdad? De hecho, al ver este backlog, la mayoría de nosotros experimentará dos emociones:
- Asco por el desorden de los elementos en este backlog.
- Culpa, porque admitámoslo, todos hemos tenido un backlog que se veía así (yo también, por supuesto).
Ahora descompongamos los problemas encontrados en este backlog.
Sobrecarga de elementos en el backlog de producto
¿Notaste que había 665 incidencias en este backlog? Bueno, el backlog más grande que tuve el “placer” de gestionar tenía más de 2.500 elementos.
El problema de un backlog sobrecargado es que casi con total certeza no podrás recordar qué es cada elemento ni por qué lo has colocado en cierta posición/prioridad en tu backlog. Como no tienes idea de qué tratan estas tareas, es poco probable que las lleves a tu próxima sesión de refinamiento, discutas sus detalles e incluyas una en el siguiente sprint.
Así que terminas con un enorme desastre inmanejable que sigue acumulándose infinitamente.
Priorización Incorrecta del Backlog
Otro problema que podrías haber notado en esta lista de backlog es que hay elementos de trabajo con prioridades “Mínima” y “Baja” colocados en la parte superior, por encima de elementos con prioridad “Máxima”.
Esto representa el caso típico cuando tu backlog no está correctamente priorizado. Puede haber muchas razones para esto, pero lo más probable es que hayas despriorizado un elemento de prioridad “Alta” bajándolo de posición en el backlog, pero olvidaste cambiar el campo de prioridad.
Falta de Detalle
¿Notaste el elemento que dice “Quiero integración fluida con todas las plataformas de redes sociales”? Jajaja. Ni siquiera es una historia de usuario adecuada, considerando el enorme alcance que pretende cubrir. El alcance es tan grande que, en la práctica, deberías tener varios épicos que lo abarquen, y cada épico tendría las historias para una plataforma de red social.
Aparte del alcance tan amplio, el problema de este elemento (en realidad, con todos los elementos de este backlog) es su vaguedad. Las historias de usuario deben describir una experiencia o acción específica de usuario.
Imagina llevar esta historia a la reunión de refinamiento de backlog con tu equipo Ágil. Te enfrentarías a una avalancha de preguntas sobre casi todos los aspectos de la historia.
“¿Qué quieres decir con fluida?” “¿Cómo se ve la integración?” “¿Con qué plataformas de redes sociales vamos a integrarnos?!”
“Lo quiero todo, y ahora”
Otra señal de alerta que quizá notaste en el backlog fue que el 70% de los elementos tenía prioridad “Máxima”. Esta es otra situación típica cuando dependes únicamente de las opiniones de tus partes interesadas para definir prioridades (y cada stakeholder considera importante su propio elemento) sin intentar evaluarlas objetivamente y comparar su importancia con la de otros ítems en la lista.
Ahora que hemos definido cómo se ve un mal backlog, vamos a arreglarlo y a hablar de cuatro buenos ejemplos de backlog... para que puedas hacer que el tuyo sea excelente.
3 Ejemplos de Backlogs Bien Hechos
Antes de mostrarte estos ejemplos, quiero señalar que no existe una sola forma correcta de crear un gran backlog. La forma en que se vea tu backlog dependerá de la naturaleza de tu producto, su madurez, el tamaño de tu empresa/equipo, etc.
En realidad, un gran backlog es aquel que logra aportar claridad y alineamiento a todos con respecto al alcance actual y futuro de tu producto.
Sin embargo, existen formas generales de gestionar tu backlog que lo harán más organizado y más fácil de usar para todos. Cada uno de los ejemplos a continuación representa una de estas buenas prácticas.
Ejemplo #1: Un Backlog con Secciones
Casi nunca está bien tener un backlog con cientos o miles de elementos. Sin embargo, tener cerca de 100 elementos suele ser bastante común y normal. Pero incluso con cien elementos en el backlog, es fácil olvidar de qué trata cada uno o dejarlos sin tocar durante mucho tiempo sin añadirlos a tus próximos sprints.
Para que tu backlog sea más organizado, puedes considerar dividirlo en secciones.
Algunos Product Managers prefieren usar secciones para agrupar los elementos según sus áreas de enfoque o hitos. Yo personalmente prefiero usar etiquetas de Versión, Épico y Componente en las tareas para esto y dividir mi backlog en secciones basadas en el alcance de los próximos sprints.
Esta es una excelente forma de asignar un sprint (o al menos una línea de tiempo aproximada de implementación) para la gran mayoría de los elementos del backlog y asegurarte de que ninguna tarea quede desatendida.
Otra forma común de gestión del backlog mediante secciones es agrupar los elementos según su estado de refinamiento/flujo de trabajo (esto es algo con lo que la IA en la gestión del backlog puede ayudar). En este caso, facilitas tu proceso con las siguientes secciones:
- Sprint actual
- Listo para planificación
- Listo para refinamiento
- Backlog
Lo que haces en este caso es trabajar en añadir requisitos de producto y descripciones a los elementos del backlog. Cuando los requisitos están listos, los envías a la sección “Listo para refinamiento”, que sirve como alcance para la próxima reunión de refinamiento.
Después de refinar un elemento, lo mueves a la sección “Listo para planificación”, lo que indica que está preparado y el equipo puede incluirlo en su próximo sprint.
Ejemplo n.º 2: Un backlog con componentes, épicas y versiones correctamente ubicados
Segmentar tu backlog sin duda lo hará más limpio y organizado. Pero la limitación de usar solo la segmentación es que solo puedes organizar tu backlog en función de un solo criterio (por ejemplo, los sprints, el estado de refinamiento, etc.).
Por suerte, las modernas herramientas de gestión de backlog de producto te ofrecen una gama más amplia de opciones para organizar tu lista de tareas de desarrollo de producto según varios criterios. Solo mira esta maravilla de backlog.
¿No parece bien organizado y agradable a la vista? En este caso concreto, hemos aprovechado las siguientes características para que nuestro backlog sea más gestionable:
Componentes
Este campo/característica tradicionalmente describe el área del producto donde deseas añadir la funcionalidad en cuestión. En el ejemplo anterior, los componentes son los distintos productos que conforman Grammarly.
Otra forma habitual de usar los componentes es organizar historias/tareas según la tecnología necesaria para crear la funcionalidad. Para las aplicaciones web, por ejemplo, puedes tener componentes de Frontend/Backend para ayudarte a organizar el trabajo y las dependencias entre ingenieros especializados en el desarrollo del lado del cliente o del servidor.
Versiones/Lanzamientos
Con esta característica, documentas todas las funcionalidades y correcciones de errores que tu equipo scrum lanzará con una determinada versión de tu producto. El control de versiones en el backlog tiene dos beneficios muy valiosos.
- Ayuda a planificar los sprints y lanzamientos. Por ejemplo, si planeas un lanzamiento en 2 semanas, durante la reunión de planificación deberías asegurarte de incluir todas las tareas previstas para esa versión del lanzamiento en el sprint.
- Puedes documentar todo lo que tu equipo ha incluido en una determinada versión y rastrear fácilmente problemas cuando surja algo en producción.
Por ejemplo, imagina que la gente empieza a recibir errores de Captcha en tu flujo de registro en la última versión 1.3.2. Al buscar la tarea en base a la cual tu equipo hizo cambios en las configuraciones de captcha, ves que pertenece a la versión 1.3.1. Significa que tendrás que retroceder a la versión 1.3.0 o hacer un hotfix.
Épicas
Bueno, no creo que sea necesario explicar qué es una épica ni los beneficios de usarla. Pero, si quieres profundizar en las mejores prácticas y detalles minuciosos de las épicas, puedes consultar nuestra guía épica (juego de palabras intencional) sobre el tema.
Ejemplo n.º 3: Un backlog con el nivel adecuado de detalle para cada sección
Esta es una buena práctica con la que tal vez te hayas topado en muchos libros y escritos teóricos sobre Ágil y gestión de productos. Aunque tendemos a volvernos un poco más escépticos con los conceptos teóricos a medida que ganamos experiencia, este en realidad es útil en la práctica.
La idea es que los elementos en la parte superior deben tener muchos detalles y, idealmente, deben haber pasado por un proceso de refinamiento del backlog de producto al menos una vez. Por otro lado, los elementos al final del backlog deberían tener pocos detalles, ya que es probable que aprendas algo nuevo sobre tu producto y usuarios finales y este elemento quede obsoleto.
Esto significa que si el elemento en la parte superior de tu backlog se ve así (o incluso más detallado):
Tus historias en la parte inferior de tu backlog deben tener muchos menos detalles y verse así:
Y cualquier historia e iniciativa que tengas en el medio de tu backlog tendrá un nivel de detalle intermedio.
Ejemplo #4: Sé que es obvio, pero... un backlog limpio
Sé que no es fácil mantener tu backlog limpio. He estado ahí muchas veces y sé que se siente como una tarea pesada. Sin embargo, no revisar todo en tu backlog y olvidar deshacerte de los elementos desactualizados son factores clave que determinan la calidad de tu backlog.
No siempre es fácil eliminar cosas de tu backlog. Hay funcionalidades realmente buenas que esperas hacer algún día (principalmente cosas "buenas de tener") y a veces realmente no quieres deshacerte de ellas. Pero en cierto punto, seamos sinceros, sabes que nunca las vas a implementar. Y aunque lo hagas, significaría que te has quedado sin funcionalidades de alta prioridad, lo cual no es una buena señal en general.
A veces son tus partes interesadas quienes han creado estos elementos desactualizados en tu backlog. Antes de eliminarlos, intentas preguntarles si su solicitud sigue siendo vigente y casi siempre su respuesta es sí. Bueno, si la solicitud tiene más de 6 meses y ellos ya se habían olvidado, simplemente convéncelos de que no es algo urgente (si lo fuera, habrían hecho seguimiento varias veces) y elimínalo.
Un gran backlog es el que mejor funciona para ti
Si tomaras en cuenta todas las mejores prácticas aquí compartidas, ¿tendrías un gran backlog? Bueno, te ayudarán, pero no garantizarán la excelencia.
No olvides que el propósito del backlog es ser una fuente única de verdad para todos. Así que, además de estas buenas prácticas, debes considerar las necesidades y el estilo de trabajo de tu equipo y las partes interesadas y construir tu backlog de una manera que les ayude a estar en sintonía.
Esta guía sobre excelentes backlogs es parte de una serie más amplia sobre todo lo relacionado con Agile. ¡Suscríbete a nuestro boletín para recibir más guías e información como esta en tu bandeja de entrada cada dos semanas!
