La visibilidad y el carácter previsible de los productos desarrollados con métodos ágiles es un tema muy en boga hoy en día.
Ahora que ha pasado la «novedad» de estos métodos, los responsables de la toma de decisiones, y las partes interesadas quieren ver acciones concretas. ¿Cuándo se entregará el producto? ¿Cuánto cuesta una funcionalidad aproximadamente? Estas son algunas de las muchas preguntas que se plantean.
Por el papel que ocupa en un equipo ágil, el Product Owner pone sobre la mesa algunos indicadores para garantizar el backlog (la lista de funcionalidades previstas para el producto).
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Por lo tanto, debe ser capaz de conocer el estado del producto en cualquier momento. Sin lugar a dudas, el backlog es el principal elemento de un equipo ágil y permite organizar la entrega del producto de forma incremental e iterativa, pero también representa una mina de oro de información.
¿Cuándo estará terminado mi producto?
Existen varias prácticas de proyección sobre tendencias que se pueden utilizar dentro del framework Scrum como el diagrama Burndown:
Este gráfico permite calcular una fecha final teórica a partir de la pendiente. Los límites de esta representación se alcanzan, no obstante, con bastante rapidez. ¿Qué hay de los cambios en el alcance? Es preferible seguir el siguiente gráfico:
Este diagrama Burn Up modificado permite seguir el progreso del producto en relación con los cambios de alcance del proyecto. Así, la fecha de finalización prevista es más fiable. Esta gráfica puede ir acompañada de los siguientes indicadores:
- fecha de finalización prevista;
- fecha de entrega inicial;
- diferencia entre ambas fechas;
- tendencia (¿aumento, disminución o mantenimiento de la diferencia durante el último sprint?).
El equipo estará al tanto en todo momento del estado del producto y de la fecha de entrega prevista.
¿Cuándo podemos entregar un producto mínimo viable?
El plazo de entrega de una primera versión del producto, definida en la fase inicial, raramente coincide con la fecha prevista cuando se revisa tras unas pocas semanas de desarrollo.
El alcance de la aplicación no solo evoluciona según la necesidad, sino también según los errores generados por cada funcionalidad. Durante un proyecto ágil, el Product Owner se enfrenta al siguiente triángulo de decisión.
Está claro que la calidad no es negociable, de modo que solo se puede ajustar el coste, el plazo y el alcance:
- cambiar la fecha de entrega tanto como sea necesario para cumplir con el alcance y los costes iniciales;
- negocia un aumento del presupuesto para cumplir con el plazo y entregar en el alcance inicial;
- redefinir el alcance con el fin de entregar a tiempo y dentro del presupuesto.
En la práctica, el Product Owner suele negociar el alcance, ya que es sobre lo que tiene un mayor control. Dos gráficos le facilitarán la toma de decisiones.
Este primer histograma pone de manifiesto una posible dispersión de los equipos (si todos los MMF —es decir, Minimum Marketable Feature o Producto Mínimo Comercializable— se iniciaran en paralelo) y permite tener en cuenta los MMF prioritarios y, a su vez, la prioridad de las historias de usuario asociadas. El Product Owner puede apoyarse en él para volver a establecer las prioridades de su backlog.
Este gráfico de radar ofrece una visión complementaria del histograma y puede utilizarse como soporte para un producto mínimo. Basta con definir todos los MMF que forman parte del producto mínimo, y luego colocar el progreso de la versión en este gráfico.
¿Qué indicadores ofrecen estos gráficos?
La parte más visual de los gráficos descritos anteriormente permiten al Product Owner comprobar de un vistazo el estado de salud de su producto. También es fácil hacer un seguimiento de los siguientes indicadores con la ayuda de gráficos actualizados:
- fecha final proyectada, plazo inicial, diferencia entre ambas y tendencia de esta diferencia;
- número de historias finalizadas en el último sprint y tendencia.
Conclusión
A partir del backlog, el Product Owner puede seguir fácilmente los gráficos e indicadores. De este modo, puede mostrar a los responsables de la toma de decisiones, y a las partes interesadas, el estado del producto en cualquier momento, así como coordinar y controlar el desarrollo del producto con claridad.
Por último, también ayuda a conocer su posición, por lo que puede progresar y contribuir a que el equipo también lo haga en un entorno de mejora continua. Para ello, la cultura de la medición es una de las claves.
Para completar la visión del desarrollo del producto, también se pueden comprobar otros indicadores relacionados con la capacidad del equipo, la calidad del producto de software o incluso el presupuesto. El Product Owner podrá hacer un seguimiento de estos aspectos.
Foto por Kaleidico en Unsplash
