El Product Backlog en Scrum es una lista ordenada por valor de todo lo que queremos hacer en nuestro producto a medio y a largo plazo, agrupada en torno a un Product Goal. ¿Cómo organizamos entonces las dependencias en Scrum, si en muchos casos no tienen valor para el Producto?
En este artículo trataremos la presencia de elementos del Product Backlog que deben ser tratados como dependencias. Si lo que buscas es resolver dependencias entre equipos, al final del artículo tienes un enlace al whitepaper sobre como realizar refinamiento cross-team.
Las dependencias en Scrum no tienen valor
En el caso de Scrum, siempre que hablamos de valor nos referimos a valor medidos en términos de métricas de uso de nuestro producto. Dicho de otra manera, no evaluamos el valor a la organización sino el valor hacia los usuarios.
Cuando realizamos actividades de asignación de valor a elementos del Product Backlog en Scrum, es habitual que cuando llegamos a determinados elementos nos preguntemos como podemos asignarles valor.
Estos elementos pueden incluir varias categorías:
- Requisitos no funcionales: Elementos que necesitamos hacer en nuestro producto pero no van a suponer ningún valor para el usuario. Por ejemplo integrar el servicio de un tercero, responder a un requisito legal o tener que dar de alta un servidor para nuestro producto.
- Decisiones de producto: En este caso se trata de puntos críticos en los que tenemos que tomar decisiones sobre nuestro producto. Esto puede incluir decisiones sobre la arquitectura, librerías de diseño o flujos de usuario.
- Dependencias con otros productos: En el último caso se trata de elementos que tienen que ver con otros productos. Podemos hablar de habilitar una función para un producto de la organización o de integrar un cambio de API en nuestro producto debido a una actualización de un proveedor.
A pesar de que el tratamiento es similar en todos los casos, merece la pena que los exploremos para tener una idea más clara de como abordarlos en cada caso.
Las dependencias en Scrum como requisitos no funcionales
Construir un producto conlleva una serie de actividades que no tienen nada que ver con el valor que se obtiene al usarlo.
Desde constituir una sociedad hasta emitir facturas, pasando por cumplir con las regulaciones de protección de datos, tenemos decenas o cientos de cosas que no tienen nada que ver con el producto.
Sin embargo Scrum está construido sobre las bases del empirismo: Transparencia, inspección y adaptación.
¿Como podemos gestionar todas esas cosas no funcionales -no relacionadas directamente con la funcionalidad- dentro del Product Backlog?
Tratándolas como una dependencia.
Una vez tenemos un Product Backlog con elementos ordenados por valor tendremos que proceder a reorganizarlos en función de las dependencias.
Es probable que el elemento que más valor tenga en mi producto sea su función principal pero antes tenga que hacer muchas otras cosas. En ese caso, tendré que ir desplazando esa función principal hacia abajo hasta tener todos los requerimientos no funcionales (NFRs) aunque inicialmente estuviera situada como número 1.
Dependencias en Scrum como decisiones de producto
Otro de los aspectos clave del desarrollo de un producto son decisiones relacionadas con arquitectura, tecnología, diseño o marketing. Este es uno de los temas en los que los equipos Scrum presentan más dudas.
¿Como damos seguimiento a todas esas decisiones de manera transparente?
De nuevo, la mejor manera es tratar esa dependencia como un elemento del Product Backlog que es necesario completar para abordar otros Product Backlog Ítems (PBIs).
Sabemos que antes de empezar una nueva funcionalidad tenemos que tomar una serie de decisiones de integración y colocamos un PBI indicando que es necesario tomar una serie de decisiones antes de comenzar con ese elemento.
En determinados casos se pueden tratar estas dependencias como elementos a trabajar antes de enfilar un nuevo Product Goal.
Las dependencias con otros productos
Cuando se trata de dependencias con otros productos como la actualización de las integraciones que ya tenemos o desbloquear la forma en que nuestro producto afecta a otros el tratamiento es sutilmente diferente.
En este caso tendremos que valorar el posible impacto negativo de no completar nuestro elemento a tiempo. Puede que el no actualizar a una versión nueva deje a nuestro producto obsoleto o sin soporte. O no terminar un determinado elemento impida que otro producto funcione.
Si este es el caso, entonces recomiendo pensar no solamente en términos de dependencias sino en términos de valor negativo. Completar un elemento fuera de tiempo puede llevar a un coste de retraso importante que conlleve pérdidas de valor para nuestro propio producto.
Aquí tenemos que observar también que pueden producirse dependencias con otros equipos. En ese caso utilizamos refinamientos cross-team como el del Nexus Framework.