La importancia de un backlog sano en el desarrollo de producto: patrones y antipatrones

A la hora de desarrollar un producto de datos por medio de metodologías Agile, un factor determinante es el Product Backlog. El Product Backlog es la representación conceptual del producto en desarrollo y, por lo tanto, hay que cuidarlo, tenerlo siempre bien ordenado, cambiarlo y revisarlo constantemente porque un fallo puede disparar los costes y generar problemas inesperados.

Parece que todo el mundo conoce como definir y construir un producto. La realidad es que al trabajar con Agile aparecen muchos errores causados por viejos hábitos que ocasionan más problemas de definición de los esperados, llegando algunos a convertirse en antipatrones de producto. A continuación os detallo algunos casos en los que sucede esto.

1. Priorización por un proxy Product Owner

Uno de los errores que se puede observar en las empresas que deciden desarrollar sus producto con un framework Agile, es que no existe un Product Owner (PO) empoderado en la toma de decisiones. El rol de PO se asocia muchas veces con el de Analista de Negocio y esto hace que mucha gente piense que su trabajo es sólo definir requisitos. Esto ocasiona que el rol sea ejercido por una persona sin capacidad de tomar decisiones de manera autónoma. Es el famoso Proxy Product Owner. Normalmente la toma de decisiones se retrasa ya que, cuando surge un problema, este tipo de PO debe consultar las decisiones a otra persona, más empoderada, y luego volver a comunicarlas al equipo. Y así una y otra vez, lo que nos hace perder un tiempo muy valioso.

2. Pensar 100% por adelantado

Otro error común es la tendencia que arrastramos de formas de trabajo previas de definir todo por adelantado. Normalmente los modelos de facturación no están preparados para abordar proyectos Agile, sino proyectos cerrados. La prioridad de las empresas cuando hablan de trabajar con metodologías Agile no es la de cambiar sus procesos internos de pedidos, facturación, pago, etc. La prioridad es que el trabajo salga más rápido.

Debido a estos procesos las empresas suelen necesitar tener todo “planteado” por adelantado para poder iniciar ciertos procesos burocráticos necesarios: compras, pedidos, ofertas, facturas, etc. Aquí surge el problema. Al hacer este planteamiento por adelantado, se genera un contrato implícito difícil de cambiar. Como las decisiones parecen estar ya tomadas desde ese momento, en el futuro costará realizar cualquier cambio.

3. Sobredimensionado

Otra consecuencia de pensar todo por adelantado es que se genera un backlog gigantesco de cosas por hacer. Esto hace que muchas veces se ponga foco en cosas que no tienen por qué acabar desarrollándose, con la consecuente pérdida de foco en el desarrollo actual. También se produce una sensación de poco avance debido a este backlog demasiado grande. Cuanto más grande sea el backlog más estático será y más difícil de revisar en su totalidad.

4. PBIs desactualizados

Otra consecuencia de tener un backlog sobredimensionado o de intentar reflejar al detalle todo lo que hay que hacer en el proyecto, es que muchos PBIs (Product Backlog Items) quedan desactualizados y obsoletos. Un planteamiento Agile indicará que los elementos más antiguos deben desaparecer del backlog. Es posible que hayan dejado de tener sentido tal y como se planteó en su momento o la necesidad que cubrían ya está extinguida. El mercado está en constante cambio, lo que es necesario hoy, dejará de ser necesario en cuestión de pocos meses. Entonces, ¿cuánto tiempo debe estar un elemento en el backlog? Pues depende, pero pensar que si un PBI no se actualiza en dos meses hay que plantearse si tiene sentido o si sigue teniendo importancia.

5. Todo estimado por adelantado

Tener un backlog estimado puede ser una gran ayuda a la hora de planificar o incluso para priorizar unos PBIs frente a otros, en base al esfuerzo, complejidad, etc. Sin embargo hay que tener mucho cuidado ya que no siempre la inversión que hacemos al estimar es recuperable. Siempre hay que estimar un backlog de manera liviana para no invertir demasiado esfuerzo. Si se trabaja en una metodología Agile, es posible que el entorno y el mercado sean muy cambiantes. En este caso realizar un esfuerzo muy grande de estimación puede ser contraproducente, porque puede cambiar su alcance, y por ende su complejidad, en apenas unos días.

Otro problema es pensar que esa tasación del esfuerzo es inamovible. La experiencia dice que seguramente todo haya cambiado desde el momento en que se estimó. Además, si el backlog es muy grande, es decir está sobredimensionado, puede ser un gran esfuerzo para luego tener que descartar muchos de los PBIs.

6. Trabajo basado en componentes o partes

Este es otro de los clásicos de un producto mal planteado. A veces se desglosan los productos por partes, capas o componentes que permiten ver fácilmente la arquitectura, el diseño, etc.

Un buen backlog debe estar basado en necesidades de cliente, usuario, mercado, etc. De esta forma se puede explotar al máximo el potencial de trabajar con metodologías Agile. Cuando el backlog está basado en partes, capas o componentes va a aparecer un problema conocido: las dependencias. Trabajar en modo componentes genera dependencias innecesarias que no pueden solucionarse dentro del equipo y el desarrollo se ralentiza: hay que definir APIs, hay que esperar a que otro equipo acabe, hay que integrar la solución, etc.

Además, al trabajar basados en componentes surge otro problema que ataca al Agile Manifiesto, y es que la arquitectura tiende a dejar de ser emergente, a lo que añadimos que, al existir dependencias ya no es tan sencilla la autoorganización.

7. PBIs “no” bien definidos

Una de las obsesiones de muchos POs es que las historias estén en formato historia de usuario. No hay que olvidar que el concepto de Historia de Usuario solo es un formato posible, pero no el único. Mucha gente cree que una ventaja de Agile radica en que no hay que definir las cosas, que todo emerge; algunos hasta llegan a decir que con una sencilla frase basta para definir una necesidad. A veces lo que se olvida es que para que una definición liviana sea realmente útil hay que definir unos mínimos. Tiene que quedar muy claro que se espera conseguir con esa funcionalidad, independientemente de en qué formato está escrito: historia de usuario, requisito, feature, etc.

Lo que nunca puede faltar como mínimo para definir un elemento del backlog son los criterios de aceptación. ¿Qué es lo que espero conseguir y cómo espero que funcione algo? Parece mentira, pero la mayoría de las veces con esto basta y a partir de aquí si que las cosas emergen.

8. PBIs demasiado definidos

Por contra al punto anterior, podemos caer en el lado opuesto, definir demasiado un PBI. Esto provocaría el concepto de parálisis por análisis, es decir no avanzar por definir absolutamente todo. La clave es buscar el equilibrio entre la información que se necesita tener escrita y la que se necesita entender. Un PBI tiene que generar una conversación y quedar validado por ella, no sustituirla. Cuando tenemos un PBI muy definido parece que no es necesario hablar ni preguntar. Esto puede generar una desconexión entre el PO y el equipo de desarrollo.

9. Falta de visión inicial única

Como consecuencia de que negocio y desarrollo no estén trabajando juntos desde el primer momento es la falta de visión única compartida. A veces se cree que teniendo todo definido la visión está clara, sin embargo hablar de cuáles son las necesidades del producto y su visión puede ayudar a evitar muchos problemas. Para hablar de esa visión única es importante hablar de los objetivos del producto. Si estos no están bien definidos y no son compartidos por todos, el sistema acaba fracasando. La toma de decisiones se ve afectada y se toman decisiones erróneas. Además, al no estar alineados con los objetivos, los refinamientos no funcionan correctamente. Tienden a ser más ambiguos y a divagar sin llegar a trabajar para cumplir con los objetivos compartidos.

Buenas prácticas para un buen backlog

Así que, si queremos tener un producto de buena calidad y salud hay que intentar seguir estas pautas:

• Debe existir un Product Owner real, con capacidad de priorización. Debe tener toda la información necesaria así como el poder y potestad completa de lo que ocurre en el producto. Solo de esta manera puede tomar las decisiones adecuadas desde la perspectiva de negocio.
• Trabajar desde la necesidad actual y no expandir todas las posibilidades permite aportar el mayor valor en cada momento.
• Poner foco en el corto plazo. En el backlog solo deberían estar los elementos que se tiene pensado ejecutar en los próximos 3-4 sprints. Se puede hacer uso de un Roadmap, un User Story Mapping, etc, pero no debe mezclarse con el corto plazo.
• Cumplir con el punto anterior y, además, ejecutar muchos refinamientos para limpiar el backlog de manera frecuente.
• Usar estimaciones ligeras solo como herramienta de decisión. Las estimaciones no deben tomarse como algo inmutable, sino que deben revisarse como parte de los refinamientos.
• Conceptualizar el producto entorno a funcionalidades completas para evitar dependencias innecesarias. El tiempo que invertimos en solucionar dependencias es un desperdicio que podemos evitar.
• Definir claramente los criterios de aceptación de los elementos del backlog. Algo que pueda ser validado y observable.
• Buscar el equilibrio entre definir poco y demasiado.
• Trabajar siempre el backlog con los objetivos de negocio en la cabeza. Esto hará que nuestro Backlog esté siempre priorizado correctamente y orientado a aportar el mayor valor posible conforme a esos objetivos que queremos conseguir.
• Tener siempre presente el manifiesto Agile y hacer uso de él durante toda la vida del producto.

Imagen: unsplash | @irfansimsar