Product Owner y gestión del backlog: valor, historias de usuario y priorización

Lo más difícil de construir software no es construirlo. Es decidir qué construir, en qué orden y qué dejar fuera, y hacerlo una y otra vez a medida que se mueven el mercado, los usuarios y la realidad técnica. Esa decisión es justo lo que sostiene la responsabilidad del product owner, y un product backlog no es más que la forma escrita actual de la respuesta.

La mayoría de los backlogs fallan como respuesta. Acumulan cada petición que alguien hizo alguna vez, se ordenan según quién se quejó más recientemente y contienen elementos tan vagos que el equipo tiene que adivinar. Esta guía trata de conseguir que el backlog haga un trabajo útil: qué exige de verdad la responsabilidad, cómo escribir elementos que merezca la pena construir, cómo mantener la lista refinada y cómo ordenarla de forma defendible. La guía del framework Scrum cubre los eventos que consumen el backlog; aquí nos fijamos en lo que los alimenta.

Maximizar el valor es una responsabilidad, no una lista de tareas

El framework dice que el product owner es responsable de maximizar el valor del producto resultante del trabajo del equipo. Dos palabras de esa frase cargan con todo el peso. Maximizar implica elegir entre opciones en las que equivocarse tiene un coste real, lo que significa que un product owner debe poder decir que no, en público y a menudo. Responsable implica que la organización respeta de verdad sus decisiones: si un director puede reordenar el backlog con solo entrar en la sala del equipo, la responsabilidad es nominal.

Tres cosas hacen viable esta responsabilidad en la práctica. La primera es una visión de producto: una declaración breve de a quién sirve el producto, qué problema le resuelve y por qué es diferente. La segunda es un product goal: el siguiente objetivo significativo en ese camino, lo bastante concreto como para saber cuándo se ha cumplido y estable durante más de un sprint. La tercera son las evidencias: datos de uso, volumen de soporte, ingresos, entrevistas, experimentos; cualquier cosa que convierta una discusión sobre el orden en un debate sobre mediciones y no en un concurso de opiniones.

Un product owner sin visión produce un backlog sin forma. Un product owner sin evidencias produce uno ordenado por jerarquía.

Escribir elementos que resistan el contacto con un equipo

El formato de historia de usuario (como <usuario>, quiero <capacidad>, para <beneficio>) es una convención, no una regla de ningún framework. Todo su valor está en la tercera cláusula: obliga a quien la escribe a dar una razón, y una historia cuyo «para» está vacío o es circular normalmente no debería construirse. El formato es un recordatorio de una conversación, no una especificación, y por eso un elemento que nunca se ha discutido con el equipo no está listo por muy bien escrito que esté.

La checklist INVEST es la prueba de calidad habitual para un elemento.

Los criterios de aceptación convierten la última propiedad en algo concreto. Deben describir comportamiento observable, incluidos los caminos de error, y pertenecen al elemento, no a un documento de pruebas aparte. Un estilo por escenarios (dado un estado inicial, cuando ocurre algo, entonces se observa esto) se lee con naturalidad y se traduce directamente en tests automatizados, que es el puente que formaliza BDD con Cucumber. Limítalos a unos pocos; veinte criterios en un solo elemento son una señal de que hay que dividirlo.

Fíjate en la diferencia con la Definition of Done. Los criterios de aceptación son específicos de un elemento y responden a «¿hemos construido lo correcto?»; la Definition of Done se aplica a todos los elementos y responde a «¿lo hemos construido bien?». Confundir ambas cosas produce elementos que cumplen sus criterios y aun así no se pueden poner en producción.

El refinamiento como actividad continua

El refinamiento es el trabajo constante de añadir detalle, estimaciones y orden a los elementos del backlog para que la parte superior de la lista esté siempre lista para seleccionarse. El framework lo describe como una actividad continua y no como un evento, y eso importa: los equipos que lo reducen a una única reunión de noventa minutos por sprint suelen llegar al Sprint Planning con elementos en los que nadie ha pensado.

Lo que produce el refinamiento es una parte superior del backlog lista. Una definición de listo (definition of ready) viable: el elemento se ha discutido con los desarrolladores, tiene criterios de aceptación, no tiene dependencias externas sin resolver, es lo bastante pequeño para terminarse en un sprint y tiene una estimación con la que el equipo está cómodo. Con dos o tres sprints de elementos así basta; refinar más allá es desperdicio, porque el orden de lo que queda por debajo cambiará antes de que llegues ahí.

Hábitos útiles: dedica al refinamiento aproximadamente entre el cinco y el diez por ciento del tiempo del equipo; refina con el equipo completo para que testers y gente de operaciones detecten problemas pronto; pon un timebox a cada elemento y aparca lo que se alargue para una investigación aparte; y divide mientras refinas, no en el Sprint Planning, cuando ya no hay tiempo para pensar.

Ordenar el backlog

Ordenar el backlog es el acto de mayor trascendencia del product owner, y ninguna técnica es la correcta en todas las situaciones.

Valor frente a esfuerzo. Sitúa cada elemento en dos ejes y aborda primero el cuadrante de valor alto y esfuerzo bajo. Es tosco y normalmente basta, sobre todo con un backlog pequeño en el que todo el mundo comparte el contexto.

WSJF (weighted shortest job first). Un modelo de puntuación popularizado por los frameworks de agilidad a escala. Se estima el coste del retraso (cost of delay) como la suma de tres puntuaciones relativas (valor para el usuario o el negocio, criticidad temporal y reducción de riesgos o habilitación de oportunidades) y se divide por el tamaño del trabajo. Una comparación con números:

La corrección de la búsqueda gana pese a ser el elemento de menos valor, porque es barata y se puede hacer ya. Esa es la gracia de la técnica: favorece los trabajos cortos con un coste del retraso significativo y deja el trade-off lo bastante explícito como para discutirlo. Su punto débil es la falsa precisión: las entradas son estimaciones relativas, así que trata el resultado como una pista de clasificación y no como un cálculo.

MoSCoW. Must, should, could, won't-this-time (imprescindible, deseable, opcional, esta vez no). Útil ante una fecha límite fija en la que el alcance tiene que flexibilizarse, y por la disciplina que impone la cuarta categoría. Su modo de fallo es bien conocido: todo acaba siendo imprescindible. Una regla habitual es que los «must» no superen aproximadamente el sesenta por ciento de la capacidad disponible.

Kano. Clasifica las funcionalidades según cómo responde la satisfacción ante ellas: expectativas básicas, cuya ausencia enfada pero cuya presencia pasa desapercibida; funcionalidades de rendimiento lineales; y factores de entusiasmo. Es un buen correctivo para backlogs llenos de factores de entusiasmo mientras una expectativa básica, como el restablecimiento de contraseña, está rota.

Usa una como técnica principal y las demás para cuestionar el resultado. Ordenar es también el momento en que entran las dependencias y el riesgo: un elemento con una dependencia de plazo largo puede tener que empezar antes de lo que justificaría su valor por sí solo, lo que conecta directamente con la estimación y planificación.

Dividir elementos grandes

Dividir es la habilidad que más mejora el flujo, porque los elementos pequeños se terminan, y terminar es lo que genera feedback. La regla es cortar en vertical (cada rebanada atraviesa todas las capas y entrega algo observable) y no en horizontal por componente, lo que produce cuatro elementos y ningún software que funcione hasta que llega el último.

Patrones de división fiables:

• Por paso del flujo. Primero el camino feliz de principio a fin; la validación, los casos límite y la administración, después.
• Por regla de negocio. Primero una moneda, un país, un tipo de cliente; generaliza después.
• Por interfaz. Una API que funcione antes que la pantalla pulida, o una tabla sencilla antes que el gráfico interactivo.
• Por variación de datos. Gestiona ahora la forma de registro habitual y después los formatos heredados poco frecuentes.
• Por operación. Crear y leer antes que actualizar y borrar, si ese orden coincide con el uso real.
• Spike y luego construcción. Cuando un elemento no es estimable, separa una investigación con timebox, con una pregunta definida y una respuesta por escrito como resultado.

Si una rebanada no se puede describir como algo que un usuario notaría, probablemente sea una tarea y no una historia, y su sitio está dentro de otro elemento.

Stakeholders y roadmaps

Un product owner pasa una parte sorprendente de la semana fuera del equipo. Mapea a los stakeholders según su influencia e interés, acuerda cómo se mantiene informado a cada grupo y canaliza las peticiones hacia el backlog, no hacia la bandeja de entrada del equipo. La Sprint Review es el principal canal programado y funciona mejor cuando se parece más a una conversación de trabajo sobre qué hacer a continuación que a una demostración para obtener aprobación.

Los roadmaps son donde más a menudo se pierde la honestidad. Un roadmap de funcionalidades con fecha se convierte en un conjunto de promesas que nunca fueron estimaciones, y cada retraso se convierte en un problema de credibilidad. Hay dos alternativas que aguantan mejor los cambios: un roadmap basado en objetivos, que nombra el resultado de cada horizonte en lugar de las funcionalidades, y un roadmap now-next-later, en el que solo la columna «now» lleva fechas. Ambos te permiten cambiar el mecanismo sin romper el compromiso. Uses el que uses, mantenlo visible en el mismo sistema que el backlog para que no pueda divergir en silencio; consulta las herramientas de gestión de proyectos para ver los trade-offs que hay en ese terreno.

Ideas clave

• La responsabilidad es maximizar el valor, lo que exige autoridad para decir que no y una organización que respete el orden.
• Un product goal da dirección al backlog; sin él, las discusiones sobre el orden no tienen con qué medirse.
• Los elementos son recordatorios de conversaciones: INVEST y unos criterios de aceptación concretos los mantienen pequeños, valiosos y testables.
• El refinamiento es continuo, cuesta aproximadamente entre el cinco y el diez por ciento del tiempo del equipo y debe mantener arriba dos o tres sprints de trabajo listo, no más.
• WSJF, MoSCoW, Kano y valor frente a esfuerzo exponen cada uno un trade-off distinto; elige uno como principal y usa los demás para cuestionar el resultado.
• Divide en vertical para que cada rebanada entregue algo observable, y pon los defectos y el trabajo técnico en la misma lista ordenada que las funcionalidades.