En cualquier momento dado, una cartera de productos ágiles contendrá una lista priorizada de las características deseadas, cada una de ellas de diferente tamaño y escritas con diferentes niveles de detalle. Debido a que la cartera de productos está priorizada, los artículos más pequeños y de alta prioridad se encuentran en la parte superior de la lista, mientras que los artículos más grandes y menos urgentes se encuentran en la parte inferior.

Como tal, los atrasos de productos tienden a tomar la forma de un iceberg, como se muestra en la imagen de abajo.

Refinar el product backlog

En la parte superior del iceberg de la cartera de productos se encuentran las características de alta prioridad que el equipo implementará relativamente pronto. Estos elementos deben ser pequeños y deben contener suficiente detalle para que cada uno de ellos pueda ser programado, probado e integrado en un solo sprint. A medida que miramos más abajo en el iceberg de la cartera de productos (y por lo tanto más adelante en el futuro), los artículos en la cartera de pedidos se vuelven cada vez más grandes y menos detallados a medida que nos acercamos a la línea de flotación. Los equipos y los propietarios de productos a menudo sólo tienen una vaga idea de lo que se esconde debajo; algunas de esas características sólo se conocen con suficiente detalle como para poder estimar y priorizar cada una de ellas de forma aproximada.

¿Por qué crear Product Backlog  que evoluciona con el tiempo?

A algunas personas les incomoda tener objetos cerca de la línea de flotación o debajo de la superficie que no se entienden bien. Están acostumbrados a iniciar un nuevo proyecto identificando “todos” los requisitos. Sin embargo, aquellos que están bien versados en ágil saben que, debido a que cada proyecto tiene algunos requisitos emergentes, nunca se pueden definir todos los requisitos de antemano.

Un enfoque mucho más ágil de los requisitos es crear una cartera de productos en forma de icebergs que se refina progresivamente con el tiempo. Aquí está el por qué.

Las cosas cambiarán.
En el curso de un proyecto, las prioridades cambiarán. Algunas características que inicialmente se consideraban importantes se irán reduciendo a medida que el sistema se muestre a los usuarios y clientes potenciales. Otras necesidades serán descubiertas y tendrán que ser priorizadas apropiadamente.

Si reconocemos que el cambio es inevitable, las ventajas de estructurar su cartera de productos como un iceberg se hacen más evidentes.

Las características que más probablemente cambiarán son las que se realizarán en el futuro. Para tener en cuenta la mayor probabilidad de cambio, estas características se describen sólo a un alto nivel.

No es necesario.

El novelista E. L. Doctorow ha escrito que “escribir una novela es como conducir de noche en la niebla. Sólo puedes ver hasta los faros, pero puedes hacer todo el viaje de esa manera”.

El desarrollo de software es la misma manera. Mis faros no iluminan todo entre el horizonte y yo porque no es necesario. Ellos iluminan el camino lo suficientemente lejos como para que yo pueda ver y responder a las velocidades a las que mi auto puede viajar con seguridad.

La acumulación de productos en forma de icebergs funciona de manera similar. Se proporciona suficiente visibilidad de los próximos artículos que los equipos ven lo suficientemente lejos en el futuro para evitar la mayoría de los problemas. Cuanto más rápido vaya un equipo, más avanzado estará en la cartera de productos que tendrá que comparar.

El tiempo es escaso.

Casi todos los proyectos tienen limitaciones de tiempo. Queremos más de lo que cabe en el tiempo asignado. Tratar todos los requisitos como equivalentes es un despilfarro.

Con un suministro limitado de uno de los recursos más críticos de un proyecto (tiempo), necesitamos protegerlo.

Si por ahora es suficiente describir una característica futura a un alto nivel, esto es todo lo que hay que hacer.

Cuando esa característica futura necesita ser mejor entendida -ya sea porque se ha movido a la parte superior de la cartera de productos o porque esperamos que influya en la implementación de otra característica- podemos describirla con más detalle.

Esto no quiere decir que un equipo no pueda optar por dedicar algún tiempo a la comprensión de los puntos más abajo en el iceberg de los productos acumulados. De hecho, a menudo es necesario hacerlo.

Si el equipo piensa que un artículo más abajo en la cartera de pedidos puede tener un impacto en los artículos que están por encima de él, el equipo puede hacer un esfuerzo para entenderlo. Esto a menudo da como resultado que el artículo se divida en varios artículos de menor volumen de pedidos pendientes.

Sin embargo, dada nuestra historia de favorecer la comprensión inicial de todas las características, los equipos deben tener cuidado de asegurarse de que hay una necesidad real de entender mejor un artículo antes de poner un esfuerzo más temprano en él de lo que de otra manera se justificaría en base a la posición del artículo en la cartera de pedidos del producto.

¿Cómo perfeccionar progresivamente el Product Backlog?

Ahora que entendemos por qué es deseable una cartera de productos en forma de icebergs, dediquemos un poco de tiempo a hablar de cómo gestionar la cartera de productos.

A medida que los artículos de alta prioridad se introducen en las carreras de desarrollo, se eliminan de la parte superior del iceberg de productos acumulados. Como tal, el iceberg desarrolla un punto plano y comienza a perder su forma.

Para contrarrestar este efecto, los equipos y los propietarios de los productos deben dedicar tiempo a remodelar la cartera de productos, un proceso conocido como refinamiento de la cartera de productos (a veces denominado preparación de la cartera de productos).

El refinamiento de la cartera de productos puede ser una reunión formal y regular, o puede ocurrir de manera más informal y frecuente durante cada sprint.

Una buena regla empírica parece ser que alrededor del 10 por ciento del esfuerzo en cada sprint debe dedicarse a refinar el trabajo atrasado en la preparación para futuros sprints.

Esta vez puede provenir de una persona (quizás un analista) cuyo papel en el equipo se centra en gran medida en el trabajo atrasado. O puede representar esfuerzos más pequeños que provienen de cada miembro del equipo.

Las conversaciones sobre la cartera de productos no se limitan a una sola vez o reunión, sino que pueden tener lugar en cualquier momento y entre cualquier miembro del equipo. Estas conversaciones permiten a los desarrolladores entender lo que se necesita construir.

¿Qué sucede cuando un equipo refina su Product Backlog?

Algunas cosas suceden a medida que los equipos perfeccionan sus icebergs de productos acumulados.

En primer lugar, a través de conversaciones con el propietario del producto, los equipos se aseguran de que los artículos que se encuentran en la parte superior del iceberg acumulado sean bien comprendidos, lo suficientemente pequeños y detallados como para ser llevados a un próximo sprint.

Recuerde, que las historias cerca de la cima son de alta prioridad, por lo que el equipo y el propietario del producto saben que necesitan ser implementadas en el próximo sprint o dos.

Al refinar estos productos, los equipos deben tener cuidado en cómo definirlos bien entendidos y suficientemente detallados.

Un buen equipo de Scrum no necesita un perfecto conocimiento de una característica antes de empezar a trabajar en ella. Más bien, al comienzo del sprint, el equipo necesita saber que tiene una probabilidad razonablemente alta de terminar cada característica durante el sprint.

En segundo lugar, el equipo y el propietario del producto podrían querer ver algunos de los artículos de menor prioridad que se han acercado a la cima, pero que todavía están a punto de salir a toda prisa. Estos elementos pueden necesitar ser divididos, reescritos, o incluso descartados en base a lo que el equipo ha aprendido en sprints anteriores.

Por último, el equipo podría echar un vistazo a algunas de las características que se han elevado recientemente por encima de la línea de flotación. Es probable que estos artículos, que antes estaban al acecho bajo la superficie, sean grandes y carezcan de detalles.

El equipo puede elegir uno o dos de estos elementos para dividirlos en historias más pequeñas y un poco más detalladas. Es probable que las historias que resulten de esta división tengan una prioridad relativamente baja, por lo que no necesitan estar listas para ser publicadas, pero sí deben contener suficientes detalles para que puedan ser estimadas con mayor precisión y tal vez puedan ser reordenadas en cuanto a sus prioridades.

¿Qué sucede cuando un equipo refina su Product Backlog?

Tener una cartera de productos en forma de icebergs debería ser una meta para cualquier equipo ágil. Si usted estructura su cartera de pedidos para tener artículos pequeños y listos para desarrollar cerca de la parte superior y artículos más grandes con menos claridad, encontrará que su equipo gasta menos tiempo en el refinamiento de la cartera de productos. Y el tiempo que pasan será invertido en los artículos considerados más importantes por el propietario del producto.