Product Backlog

El product backlog del producto en Scrum es una lista de características priorizadas, que contiene descripciones breves de toda la funcionalidad deseada en el producto.

Al aplicar Scrum, no es necesario comenzar un proyecto con un largo esfuerzo inicial para documentar todos los requisitos.

Por lo general, un equipo y su Product Owner comienzan escribiendo todo lo que pueden pensar para la priorización del backlog.

El backlog del producto Scrum se permite entonces crecer y cambiar a medida que se aprende más sobre el producto y sus clientes.

¿Qué puedes encontrar en un Product Backlog?

Un backlog típico de Scrum comprende los siguientes tipos de elementos:

• Características
• Bugs
• Trabajo técnico
• Aprendizajes

Con mucho, la forma predominante para un equipo de Scrum para expresar las características en el backlog del producto es en forma de historias de usuario, que son descripciones cortas y sencillas de la funcionalidad deseada contada desde la perspectiva del usuario.

Debido a que realmente no hay diferencia entre un error y una nueva característica – cada uno describe algo diferente que un usuario quiere – los errores también se ponen en el backlog del producto de Scrum.

El trabajo técnico y las actividades de adquisición de conocimientos también pertenecen al backlog.

Un ejemplo de trabajo técnico sería: “Actualizar todas las estaciones de trabajo de los desarrolladores a Windows 7”.

Un ejemplo de adquisición de conocimientos podría ser un elemento del backlog de Scrum sobre la investigación de varias bibliotecas de JavaScript y hacer una selección.

El Product Owner se presenta en la reunión de planificación del sprint con el backlog del producto priorizado y describe los elementos principales al equipo.

A continuación, el equipo determina qué elementos pueden completar durante el siguiente sprint. Luego, el equipo traslada los elementos del backlog del producto al backlog del sprint.

Al hacerlo, amplían cada elemento del backlog del producto de Scrum en una o más tareas del backlog del sprint para poder compartir el trabajo de forma más eficaz durante el sprint.

Conceptualmente, el equipo comienza en la parte superior del backlog priorizado de Scrum y dibuja una línea después del más bajo de los elementos de alta prioridad que sienten que pueden completar.

En la práctica, no es inusual ver a un equipo seleccionar, por ejemplo, los cinco primeros elementos y luego dos elementos de la parte inferior de la lista que se asocian con los cinco iniciales.

¿Cómo debe estar priorizado un Product Backlog?

Dado que el backlog del producto está priorizado, los elementos más pequeños y de alta prioridad residen en la parte superior de la lista, mientras que los elementos más grandes y menos urgentes caen hacia la parte inferior.

En la parte superior del iceberg del backlog del producto están las características de alta prioridad que el equipo implementará relativamente pronto.

Estos elementos deben ser pequeños y deben contener suficientes detalles para que cada uno pueda ser programado, probado e integrado en un solo sprint.

A medida que miramos más abajo en el iceberg del backlog del producto (y, por tanto, más lejos en el futuro), los elementos del backlog son cada vez más grandes y menos detallados a medida que nos acercamos a la línea de flotación.

Los equipos y los product owners a menudo sólo tienen una vaga idea de lo que se esconde ahí abajo; algunas de esas características sólo se conocen con el suficiente detalle como para poder estimarlas aproximadamente y priorizarlas.

¿Por qué crear una cartera de productos que evolucione con el tiempo?

Algunas personas están acostumbrados a empezar un nuevo proyecto identificando “todos” los requisitos.

Sin embargo, los que están bien versados en la metodología ágil saben que, dado que cada proyecto tiene algunos requisitos emergentes, nunca se pueden definir todos los requisitos por adelantado.

Un enfoque mucho más ágil de los requisitos consiste en crear un backlog del producto en forma de iceberg que se perfeccione progresivamente con el tiempo. La razón es la siguiente.

Las cosas van a cambiar.

A lo largo de un proyecto, las prioridades cambiarán. Algunas características que inicialmente se consideraban importantes dejarán de serlo a medida que el sistema se muestre a los usuarios y clientes potenciales. Se descubrirán otras necesidades y habrá que priorizarlas adecuadamente.

Si reconocemos que el cambio es inevitable, las ventajas de estructurar el backlog del producto como un iceberg se hacen más evidentes.

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

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 así”.

El desarrollo de software es igual. Mis faros no iluminan todo lo que hay entre yo y el horizonte porque no lo necesitan. Iluminan el camino lo suficiente para que yo pueda ver y responder a las velocidades que mi coche puede recorrer con seguridad.

La acumulación de productos en forma de iceberg funciona de forma similar. Se proporciona suficiente visibilidad de los próximos elementos para que los equipos vean lo suficientemente lejos en el futuro como para evitar la mayoría de los problemas. Cuanto más rápido vaya un equipo, más lejos tendrá que mirar en el backlog del producto.

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 (el tiempo), tenemos que protegerlo.

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

Cuando esa futura función deba entenderse mejor, ya sea porque ha pasado a ocupar el primer lugar en el backlog del producto o porque esperamos que influya en la implementación de otra función, podemos describirla con más detalle.

Esto no quiere decir que un equipo no pueda elegir dedicar algo de tiempo a entender los elementos que están más abajo en el iceberg del backlog del producto. De hecho, a menudo es necesario hacerlo.

Si el equipo piensa que un elemento más abajo en el backlog del producto puede tener un impacto en los elementos por encima de él, el equipo puede poner algún esfuerzo en la comprensión de la misma. A menudo, esto da lugar a que el elemento se divida en varios elementos más pequeños del backlog del producto.

Sin embargo, dado nuestro historial 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 comprender mejor un elemento antes de poner más esfuerzo temprano en él de lo que se justificaría en base a la posición del elemento en el backlog del producto.

Cómo refinar progresivamente el backlog del producto

Ahora que entendemos por qué es deseable un backlog de producto en forma de iceberg, vamos a dedicar algo de tiempo a hablar de cómo gestionar el backlog de producto.

A medida que los elementos de alta prioridad se incorporan a los sprints para su desarrollo, se eliminan de la parte superior del iceberg de la cartera de productos. De este modo, el iceberg se aplana y empieza a perder su forma.

Para contrarrestar este efecto, los equipos y los Product Owners  deben dedicar tiempo a remodelar el backlog del producto, un proceso conocido como refinamiento del backlog del producto (a veces denominado preparación del backlog del producto).

El refinamiento del backlog del producto puede ser una reunión formal que se realiza regularmente o puede ocurrir de manera más informal y frecuente durante cada sprint.

Una buena regla general parece ser que alrededor del 10 por ciento del esfuerzo en cada sprint debe ser utilizado para refinar el backlog en preparación para futuros sprints.

Este tiempo puede provenir de una persona (tal vez un analista) cuyo papel en el equipo se centra en gran medida en el backlog. O puede representar esfuerzos más pequeños procedentes de cada miembro del equipo.

Las conversaciones sobre el backlog del producto no se limitan a un único momento o reunión; pueden ocurrir en cualquier momento y entre cualquier miembro del equipo. Estas conversaciones permiten a los desarrolladores comprender lo que hay que construir.

Qué sucede cuando un equipo refina su backlog

A medida que los equipos perfeccionan su backlog del producto, ocurren varias cosas.

En primer lugar, a través de conversaciones con el Product Owner, los equipos se aseguran de que los elementos hacia la parte superior del iceberg del backlog se entienden bien, son lo suficientemente pequeños y están lo suficientemente detallados como para ser llevados a un próximo sprint.

Recuerde que las historias cercanas a la parte superior son de alta prioridad, por lo que el equipo y el Product Owner saben que deben ser implementadas en el próximo sprint o dos.

Al refinar estos elementos del backlog del producto, los equipos deben tener cuidado en la forma en que definen bien entendido y suficientemente detallado.

Un buen equipo Scrum no necesita una comprensión perfecta de una característica antes de empezar a trabajar en ella. Más bien, al comienzo del sprint, el equipo necesita saber que tienen una posibilidad razonablemente fuerte de terminar cada característica durante el sprint.

En segundo lugar, el equipo de desarrollo y el Product Owner pueden querer examinar algunos de los elementos de menor prioridad que se han acercado a la cima, pero que todavía están a varios sprints de distancia. Es posible que estos elementos deban dividirse, reescribirse o incluso descartarse en función de lo que el equipo haya aprendido en sprints anteriores.

Por último, el equipo podría echar un vistazo a algunas de las características que han subido recientemente por encima de la línea de flotación. Es probable que estos elementos, 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 ligeramente más detalladas. Es probable que las historias resultantes de esta división sigan teniendo una prioridad relativamente baja, por lo que no es necesario que estén listas para el sprint, pero sí deben contener suficientes detalles para poder estimarlas con mayor precisión y, tal vez, volver a priorizarlas.

¿Qué sucede cuando un equipo refina su backlog?

Tener un backlog de producto en forma de iceberg debería ser un objetivo para cualquier equipo ágil.

Si se estructura el backlog de manera que tenga elementos pequeños y listos para desarrollar cerca de la parte superior y elementos más grandes con menos claridad en la parte inferior, se verá que el equipo pasa menos tiempo en general en el refinamiento del backlog del producto.

Y el tiempo que dediquen se invertirá en los elementos considerados más importantes por el Product Owners.