Cuento largo corto para los lectores impacientes, las principales características de un backlog saludable son: limpio, estimado y priorizado.  

¿Qué es un backlog? 

El backlog es una lista que ayuda a mantener en control las prioridades de un producto de software. El propósito del backlog es que sirva de mapa para la entrega de un producto o una solución. Una vez se hace entrega de uno o varios features del producto, debe servir para documentar la retroalimentación (feedback) de los usuarios y con estos nuevos datos se debe reorganizar nuevamente el backlog.  

Debe ser la única fuente de la verdad donde vivan los requisitos del producto ya que esto facilitará la exploración y el análisis de cualquier cambio a realizarse a lo largo del desarrollo del mismo. Si el backlog y el equipo de desarrollo no está orientado a cumplir este propósito (usar el backlog como mapa y barómetro para para el beneficio de todos), es muy probable que sientan que el backlog es un estorbo en vez de una herramienta de ayuda. El backlog siempre debe usarse para beneficio de todo el equipo y no solo para el uso exclusivo de los desarrolladores. Siendo el backlog una de las herramientas principales para tener visibilidad del producto de software, debemos reconocer que la responsabilidad de promover las características de un backlog saludable es de todo el equipo y no debe recaer exclusivamente en el Product Owner o en el Developer Lead del proyecto.  

¿Product Backlog y Sprint Backlog? 

La intención de este breve artículo es poder compartir tres ideas que podamos aplicar a ambos, al Product Backlog y al Sprint Backlog. La definición simplificada para diferenciar ambos tipos de backlogs es la siguiente: el product backlog es la lista de cosas que necesitamos desarrollar y el sprint backlog es la lista de cómo realizaremos el desarrollo de un incremento. ¿Qué podemos hacer para mantener un backlog saludable? 

Los tres pasos o ideas que deseo compartir son inspirados en el enfoque de Roman Pichler y Mike Cohn con su propuesta «Make the Product Backlog DEEP»:  

• Detallado apropiadamente
• Estimado
• Emergente y 
• Priorizado 

Ya que el backlog por defecto debe ser considerado un documento emergente o documento vivo, quiero utilizar como base los tres enfoques restantes para explorar las características de un backlog saludable.  

Un backlog saludable debe estar limpio 

Existe una gran diferencia entre un vaso con agua limpia versus un vaso con agua turbia. Al momento de necesitar entender las prioridades del producto debemos procurar tener un backlog que provea esa claridad que estamos buscando. ¿Están las tareas debidamente identificadas? ¿El equipo tiene claro los criterios de aceptación y lo acordado para dar por terminada la tarea (definition of done)? Cada user story tiene su complejidad definida (story points).  

¿Cómo logramos esto? Aquí es donde los líderes deben tener un total entendimiento de la meta y el propósito del producto, no solo a corto plazo, sino también a futuro. Tener una visión clara ayudara grandemente a mantener el agua lo menos turbia posible. Sin esta claridad no podemos efectivamente remover bugs (elementos) que no son prioridad o remover user stories que no serán trabajados en el sprint actual. La idea de alcanzar la mayor claridad posible es poder remover toda distracción que no aporte al cumplimiento de las tareas (o metas) establecidas para el sprint o para el lanzamiento propuesto.  

Un backlog saludable debe estar apropiadamente estimado 

Estimar es algo que no podemos hacer a lo loco. Ha sido un problema que hemos discutido anteriormente en el artículo: “The Problem with Software Estimation Today”. Por tal razón, debemos perseguir una disciplina y rigor que sea estable y efectiva. Es importante tener identificado claramente cuál es nuestro sistema para proveer una estimación adecuada. Y utilizo la frase «estimación adecuada» con toda intención ya que es un grave error al momento de estimar pensar que estamos creando un contrato o un compromiso irrevocable. Esto es totalmente incorrecto. La misma palabra es clara y nuestro deber es ser extremadamente claros y honestos al momento de realizar la estimación. Si no tomamos en serio este proceso, nuestras proyecciones y credibilidad quedaran cuestionadas y con mucho propósito. Por eso es importante el rigor al momento de realizar este ejercicio.  

¿Cómo logramos cuantificar y estimar adecuadamente? Hay varios elementos que debemos tener presentes; Story Points: están debidamente registrados? Tenemos claro cuál es nuestro sistema para determinarlos. Antes de contestar estas preguntas, tenemos que entender que no importa que escala se use, los story points son siempre "relativos entre si" y no simbolizan un tamaño de horas, si no, una combinación de tamaño, complejidad, riesgo, nivel de conocimiento, entre otras cosas. Aquí podemos aprovechar las diferentes estrategias disponibles para documentar estos valores, por ejemplo: utilizar una sucesión de Fibonacci modificada o la analogía al tamaño de una prenda de ropa, lo importante es tener claro cuál es el sistema y que significa. Otro elemento importante es la velocidad del equipo. Mucho ojo con esta medida. Aunque no haya prisa por determinar la velocidad del equipo ya que mínimo para esta métrica la obtenemos luego del segundo o tercer sprint, es importante que se use correctamente como parte del proceso de estimación y no para determinar el rendimiento del equipo, para esto ya tenemos un libro entero con las métricas ideales. La velocidad, la usamos como pronóstico de cuando el equipo podría terminar un numero de story points o cuantos story points el equipo podría completar en cierto tiempo. Un backlog debidamente estimado provee el terreno fértil para poder tener esas discusiones complejas al momento de escoger las prioridades del equipo y a la hora de pronosticar cambios al proyecto. 

Un backlog saludable debe estar priorizado 

Esta es quizás la destreza de mayor peso dentro de estas tres características. No obstante, si tenemos claro las dos características anteriores, lograr este balance puede resultar en un proceso llevadero. ¿Porque es extremadamente importante priorizar? Esta es ese tipo de pregunta que dependiendo a quien se le realice, obtendremos una contestación diferente. En un proyecto con un enfoque de desarrollo de alto rendimiento o elite, no hay nada más valioso que el tiempo de cada integrante del equipo. Si no tenemos claro entendimiento de cuáles son las prioridades, estaremos desaprovechando el potencial de nuestros diseñadores e ingenieros. No hay nada más dañino a la hora de mantener o crear un producto que no saber dónde invertir adecuadamente el tiempo de desarrollo del equipo.  

Priorizar se puede considerar una danza entre Product Owner, Team Lead y el equipo. Es un ejercicio continuo que debe ocurrir con cada nueva información que obtenemos del producto. Requiere extrema comunicación entre todos los participantes, pero sobre todo se necesita tener claro cuál es el sistema para determinar la prioridad de los elementos en el backlog, sea la metodología MosCow o el uso matriz de Value vs Effort. Parece obvio pero las prioridades se establecen antes de que comience el trabajo. Debe haber un espacio que sea intencional y disciplinado para discutir cabalmente las prioridades. Es casi imperativo realizar este ejercicio con una mentalidad iterativa e incremental, ya que a la hora de priorizar es importante esa retroalimentación del cliente (la parte iterativa) que logramos mediante el desarrollo de ese feature o funcionalidades críticas (la parte incremental) para que el cliente pueda ir explorando y refinando su idea o producto; proceso ampliamente elaborado por Steven Thomas en su artículo, “Revisiting the Iterative Incremental Mona Lisa” . El foro adecuado pudiera ser parte del sprint planning, pero de igual forma puede ocurrir en el backlog refinement. Lo importante es que el equipo sea disciplinado con el proceso, y los participantes claves estén presentes. Se debe fomentar la honestidad absoluta durante este proceso y habrá momentos en que la priorización debe ser despiadada, donde las prioridades serán solo hacer la mejor de las ideas para poder lanzar adecuadamente el producto o feature. 

En conclusión 

Establecer las características de un backlog saludable puede considerarse toda una disciplina en el universo de desarrollo de productos. No solo aplicable a productos de software sino a cualquier proceso que cuente con la intención de crear algo donde personas y grupos puedan usar para el bienestar humano. Al final, la idea es poder usar el backlog, como herramienta para beneficio de todos y lograr claridad del proyecto a través un método estructurado, que sea óptimo y fácil de utilizar para crear espacios de comunicación y discusión entre todos los participantes.  

Referencias 

• Sprint Backlog en SCRUM: ¿Qué es y cómo organiza tus tareas? (ES) 
• Make Your Product Backlog DEEP (romanpichler.com) (EN) 
• Scrum Guide | Product Backlog (EN) 
• The Most Popular Prioritization Techniques and Methods: MoSCoW, RICE, KANO model, Walking Skeleton, and others (EN) 

• The Story Point Controversy The Value of Story Points and Why They Create Contention (EN)