Herramienta central del delivery, el backlog de Producto es clave para preparar el desarrollo de las nuevas funcionalidades. Permite tener una visión global sobre lo que constituirá el producto y organizar el delivery de manera incremental. Se requiere un trabajo en equipo para alimentarlo, redactar las Historias de Usuario y asegurarse de que todo esté listo antes de desarrollar.
Qué es el backlog de Producto
Elementos clave del backlog
Un backlog de producto es un conjunto ordenado de elementos a realizar para entregar el producto, es todo el trabajo que el equipo va a tener que realizar. A menudo presentado en forma de lista, el backlog se compone de diferentes elementos:
- La Épica, unidad funcional de valor: una Épica describe una parte de la solución a desarrollar para responder al problema identificado. Contiene las informaciones macroscópicas de contexto, de valor esperado y de criterio de éxito. La Épica es un contenedor de varias Historias de Usuario que, cuando se desarrollan, contribuyen a entregar el valor objetivo.
- La Historia de Usuario, descripción funcional detallada: una Historia de Usuario describe una necesidad del usuario y especifica cómo evolucionar el producto para responder a ella. El objetivo es especificar el desarrollo de una parte de una funcionalidad.
- La Historia Técnica, tema técnico: los requisitos técnicos para el desarrollo de las Historias de Usuario (actualización de versión de un componente técnico, refactorización de un elemento técnico) se formalizan como Technical Stories. Estos elementos contienen la descripción de las tareas técnicas a realizar así como el objetivo buscado. Generalmente son redactados directamente por el equipo de desarrollo.
- El ticket de bug, solicitud de corrección de una anomalía: las anomalías, comportamientos no deseados de tu producto, deben aparecer en el backlog para que su resolución sea priorizada frente a las nuevas funcionalidades.
- La Spike, tema de estudio: cuando una solicitud no es estimable porque hay demasiadas incógnitas, o bien cuando se necesita una fase de investigación antes de decidir sobre la solución a implementar para una funcionalidad dada, es posible crear una Spike. Estos estudios suelen tener un límite de tiempo. Esto permite reservar una parte de la capacidad del equipo para la realización del estudio, controlando el impacto en el resto de los desarrollos. Para maximizar el éxito de la fase de estudio, recomendamos definir de antemano los entregables esperados. Si el objetivo no se ha alcanzado cuando el tiempo asignado ha terminado, puedes decidir prolongar la duración del estudio o posponerlo.
¿Y la feature?
En algunas organizaciones existe un nivel de granularidad adicional entre la Épica y la Historia de Usuario, llamado feature. Añadir este nivel de desglose adicional permite agrupar tus Historias de Usuario en conjuntos funcionales coherentes intermedios, especialmente relevantes si tu producto es complejo o de tamaño considerable. En este caso, tus Épicas se dividen en features que a su vez se dividen en Historias de Usuario. Por ejemplo, se puede tener una Épica «Gestión de la cuenta», dividido en varias features como la «Creación de la cuenta», la «Supresión de la cuenta» y la «Reiniciación de la contraseña», que a su vez se dividen en Historias de Usuario más pequeñas. Lo importante es ante todo definir un marco de referencia que sea claro para tu equipo.
Este artículo es un extracto del libro:
Mantener un backlog activo y prioritario
El backlog debe ser dinámico, ajustándose continuamente a las prioridades del equipo. Las Historias de Usuario más importantes deben estar siempre en la parte superior y claramente definidas.
No dediques demasiado tiempo en añadir y precisar los elementos en la parte baja de backlog. ¿Por qué escribir, discutir, estimar, en resumen, tomar tiempo del equipo si no tiene la capacidad de absorber la carga de desarrollo? Haz que tu backlog sea siempre pequeño y legible, concentrándote en la entrega de funcionalidades de alto valor añadido.
¿Backlog o no backlog?
Un backlog no es un recordatorio, con el riesgo de convertirse en un cajón de sastre ilegible en el que se anotan todas las nuevas ideas.
La metodología Shape Up, desarrollada en Basecamp y explicada en el libro del mismo nombre escrito por Ryan Singer, incluso recomienda no complicarse con un backlog y concentrarse en las soluciones a construir en el próximo ciclo de seis semanas. Las ideas que no fueron seleccionadas se descartan. Considera que si siguen siendo relevantes seis semanas después, surgirán naturalmente. Destaca especialmente la carga mental que representa un backlog demasiado grande, así como el tiempo consumido en el refinamiento del backlog: «Los backlogs son una carga que no necesitamos llevar. Docenas, luego cientos de tareas se acumulan, de las cuales todos sabemos que nunca tendremos tiempo para ocuparnos. Este
montón creciente nos da la impresión de estar siempre atrasados, incluso si no es el caso. No es porque alguien pensó que una idea era importante hace un trimestre que debemos seguir trabajando en ella una y otra vez. Los backlogs también son una gran fuente de pérdida de tiempo. El tiempo pasado revisando, cuidando y organizando viejas ideas impide que todos
avancen en los proyectos que realmente importan.»
Cómo crear tu backlog de producto
Desglosar las Épicas en Historias de Usuario
Durante la fase de Product Discovery, se identifican las Épicas. Estas deben desglosarse en Historias de Usuario más pequeñas y accionables para que el equipo pueda desarrollarlas de manera incremental.
Realizar refinamientos del backlog
El refinamiento del backlog es un ritual colaborativo que reúne en la mesa a todos los participantes en el delivery. Al final de los refinamientos del backlog, debes haber resuelto todas las incertidumbres y poder lanzarte a los desarrollos con tranquilidad.
Por lo tanto, es importante que los temas tratados durante los refinamientos sean compartidos y comprendidos por todo el equipo. Algunos equipos prefieren ritualizar los refinamientos definiendo horarios semanales, otros solicitan intercambios según las necesidades y la disponibilidad del equipo.
Durante las sesiones de refinamiento, debes realizar las siguientes actividades:
- Desglosar Épicas en Historias de Usuario.
- Identificar las reglas de negocio y los criterios de aceptación.
- Detectar los elementos a clarificar.
- Evaluar la complejidad.
Para enmarcar las sesiones de refinamiento, puedes apoyarte en talleres participativos como el Example Mapping o el Tres Amigos.
El Example Mapping te permite abordar durante un tiempo limitado (25-30 min) el alcance de una Historia de Usuario e identificar las reglas de negocio y criterios de aceptación asociados y las preguntas restantes a precisar. Al final del taller, los participantes votan si se sienten cómodos para comenzar el desarrollo o si es necesario continuar precisando los elementos.
El taller Tres Amigos, que reúne en la mesa al Product Manager, desarrollador y tester, ayuda en la escritura de las Historias de Usuario y, en particular, de los criterios de aceptación. Antes del taller, escribes las reglas de negocio de la Historia de Usuario. Estas pueden ser compartidas con antelación para que el equipo prepare las preguntas. Durante el taller, se revisan las reglas y los participantes redactan conjuntamente los criterios de aceptación. El taller generalmente permite aclarar ciertas áreas grises y precisar, si es necesario, las reglas a implementar.
Redacción de Historias de Usuario
Más allá de su estructura y contenido, las Historias de Usuario son ante todo un medio de discusión entre tú y los miembros del equipo, permitiendo intercambiar perspectivas sobre la necesidad y ponerse de acuerdo sobre las soluciones a desarrollar. Ron Jeffries, informático estadounidense de renombre, señala que las buenas Historias de Usuario integran tres aspectos:
- Carta (Card): información sintética y fácil de entender (que puede caber en una tarjeta).
- Conversación (Conversation): discusiones e intercambios que dan lugar a reglas de negocio, no dictadas por los Product Managers.
- Confirmación (Confirmation): una comprensión compartida de las expectativas a través de los criterios de aceptación.
Así, el buen formato de una Historia de Usuario es aquel que funciona para ti y está ideada en función de los temas. En algunos equipos, suficientemente maduros, y para ciertos temas pequeños, de bajo riesgo o técnicos, la Historia de Usuario reducida a una descripción funcional puede ser suficiente.
Enfoque en el framework INVEST
El framework INVEST te proporciona una guía para redactar el contenido de tus Historias de Usuario. Sus seis criterios te permitirán cuestionarte para redactar buenas Historias de Usuario:
- Independiente: tus Historias de Usuario deben, en la medida de lo posible, ser independientes unas de otras para poder ser desarrolladas y entregadas individualmente.
- Negociable: deben fomentar la discusión y pueden ser modificadas hasta que entran en desarrollo.
- Valor: deben aportar valor. Dado que la noción de valor siempre es difícil de evaluar, las Historias de Usuario deben ser expresadas con una visión del objetivo buscado para el usuario y la empresa.
- Estimable: deben ser lo suficientemente claras para que el equipo pueda evaluar su complejidad.
- Pequeña (Small): deben ser de tamaño suficientemente pequeño para evitar los efectos túnel. Intenta, por tanto, desglosar finamente tus Historias de Usuario.
- Testable : las Historias de Usuario deben contar una historia, de la cual los tests se derivan de manera evidente.
Por ejemplo, puedes redactar tus Historias de Usuario de la siguiente manera:
- Un título, expresando el propósito de la Historia de Usuario.
- Una frase narrativa orientada al usuario describiendo el beneficio deseado, a menudo estructurada en la forma «como un/a...», «quiero...», «para poder...».
- Un conjunto de reglas de negocio, detallando el comportamiento esperado para satisfacer la necesidad, así como los criterios de aceptación y condiciones necesarias para la validación de la funcionalidad.
Esta estructura genérica te servirá de base para la redacción de tus Historias de Usuario. Luego puedes completarlas agregando los elementos relevantes para la comprensión de la necesidad y de la solución: maquetas, esquema de arquitectura, plan de etiquetado...
Consejos para organizar el proceso de desarrollo
Organizar el proceso con Kanban Ready
Para organizar las etapas de refinamiento de las soluciones, puedes visualizar las etapas en un tablero Kanban. La visualización te permitirá organizarte con tu equipo y comunicar con transparencia sobre los temas próximos a desarrollarse.
El Kanban Ready es un buen medio para ajustar el ritmo de preparación de las Historias de Usuario, en función de la capacidad del equipo de desarrollo. Puedes aspirar a adoptar un enfoque de corto plazo para el desarrollo de las Historias de Usuario. Se evitará llenar un backlog con elementos que caerán en el olvido unas semanas más tarde.
Tablero Kanban para proyector preparados
Implementar el Definition of Ready
La Definition of Ready (DoR) ayuda a definir cuándo una Historia de Usuario está lista para ser desarrollada.
La DoR es la lista de elementos requeridos que una Historia de Usuario debe cumplir para pasar al desarrollo. Se trata de un contrato establecido con el equipo, que permite explicitar lo esperado de una Historia de Usuario y tener una garantía de calidad antes de los desarrollos.
Puede evolucionar con el tiempo y difiere de un equipo a otro, e incluso de un producto a otro. Para definirla, organiza un taller con todo el equipo.
No temáis al síndrome del backlog vacío. Seleccionar únicamente las Historias de Usuario listas para pasar al desarrollo asegura la entrega y la calidad de sus desarrollos. Y si les falta elementos funcionales, recordad que también existen las Technical Stories, Spikes y tickets de bug.
Nuestros consejos
- Cuando tomes posesión de un backlog existente, tómate el tiempo para hacer limpieza y eliminar los elementos demasiado antiguos, esto permite apropiarse del entorno y validar el valor de cada solución.
- Cuando desgloses tus Épicas en Historias de Usuario, ten en mente que no necesitas implementar la totalidad de la Épica para entregarla a los usuarios. Prioriza las Historias de Usuario que permitan entregar el valor mínimo de cada Épica. Las otras Historias de Usuario identificadas podrán ser priorizadas más tarde, en función de los feedbacks de los usuarios.
- No esperes a un refinamiento para comenzar a recoger opiniones sobre la factibilidad técnica, UX, etc., de una Historia de Usuario. Pueden comenzar a hablar de una Historia de Usuario con su equipo cuando tengan un poco de tiempo antes o después de su reunión diaria, por ejemplo.
Para saber más: descarga nuestro libro Las Claves del Product Management
Foto de rawpixel.com en Freepik
