Introducción
El Product Backlog es uno de los artefactos con los cuales trabaja el Product Owner pero no es de propiedad exclusivamente suya, de hecho cualquier miembro del Scrum Team debe tener acceso al Product Backlog pero el Product Owner es quien decide el orden de los items.
Si el backlog fuese secreto provocaría poca visibilidad por parte del Equipo de Desarrollo y lo que es peor no permitiría que todos los miembros del equipo contribuyan con ideas y opiniones recortando así la creatividad.
El Product Backlog, al igual que los demás artefactos, es propiedad del Scrum Team y para que éste lo pueda usar en su trabajo diario. Al ser un artefacto ligado con la táctica es necesario que todos en el equipo puedan verlo y sentirlo presente en el día a día.
Además de lo anterior el Product Backlog tiene otras características, tales como: ser finito, contener items que son diferentes entre sí en valor y nivel de especificación, ser dinámico, y ser alcanzable en un horizonte de tiempo corto.
Como tal el trabajo del Product Owner consiste en tener el Product Backlog ordenado incorporando el conocimiento más actual que viene del aprendizaje y la retroalimentación de los clientes. El trabajo del Scrum Mater será guiar al Product Owner y los desarrolladores para que el Product Backlog mantenga las características descritas en el párrafo anterior.
Producción versus Resultado
La producción es medible y observable, aun cuando el software es un elemento abstracto, pues esta ligada a la cantidad de algo que se produjo dentro de un Sprint.
Por ejemplo podemos decir que en un Sprint cualquiera se implementaron X cantidad de items, se escribieron Y lineas de código, se escribieron Z pruebas automatizadas, o el porcentaje de cobertura de pruebas es del W%.
El resultado es más intangible y subjetivo pero aun así puede ser apreciado aunque no necesariamente se mida numéricamente.
El mejor ejemplo de resultado es la percepción de si el equipo Scrum está construyendo el producto correcto que resolverá los problemas y necesidades de los clientes. Ligado a lo anterior está la percepción de los clientes que gustan del producto y lo compraran cuando este terminado.
Si bien es cierto que no se puede llegar al resultado sin la producción es económicamente mas conveniente tratar de alcanzar el mayor resultado con la menor cantidad de producción posible. La clave para esto es que el Product Owner pueda identificar que items del Product Backlog implementar primero.
Existen varios atributos que pueden tener los items del Product Backlog que permiten ver si contribuyen mayor resultado, por ejemplo:
- items que tienen un componente visual, es decir que los usuarios finales pueden ver en el producto e interactuar con el
- items que al verlos en el producto los usuarios finales los conectan inmediatamente con una posible solución a un problema o necesidad que ellos tienen
- items que un gran número de usuarios potencialmente utilizaran
Demás esta decir que cualquier item que se espere que produzca resultados positivos tiene que tener insertada la calidad.
Definiendo Valor
El valor de los items puede definirse desde diferentes perspectivas pero es importante no perder de vista que siempre debe estar conectado a algo que los clientes puedan ver y pagar por él.
Muchas veces los desarrolladores tienden a pensar que primero deben hacer todo el trabajo de las capas más inferiores, que tiene valor solo técnico, para en varios Sprints posteriores recién empezar a implementar items que los clientes puedan ver.
En este punto es frecuente que los clientes hayan cambiado de opinion o pidan cambios en los items pero estos cambios ahora son costosos pues hay que bajar varias capas y tocar mucho código. La consecuencia natural es que los desarrolladores se resistirán lo mas posible a hacer cambios restringiendo de esta manera la adaptabilidad del producto.
Por el contrario sí el abordaje arquitectónico permite desde el principio ver el producto y realizar cambios rápido se tiene dinamismo y adaptabilidad. Precisamente es en este escenario en el cual se puede tener items con mejor definición de valor, items como por ejemplo:
- items que permitan realizar operaciones o flujos completos
- items que permitan aprender como interactuaran los clientes con el producto
- items que permitan descubrir nuevos clientes o descartar clientes que se consideraba que iban a utilizar el producto
- items que ayuden a reducir el riesgo de que algún item no se vaya a usar una vez implementado completamente
- items que permitan descubrir que tan frecuentemente serán utilizados
Un otro factor importante es considerar que en un producto están involucrados diferentes grupos y cada uno puede percibir el valor de manera diferente. Así por ejemplo:
- Los stakeholders del negocio pueden pensar que el valor se conecta a vender el producto a la mayor cantidad de gente al mejor precio
- Los usuarios y clientes perciben el valor de un producto que resuelve sus problemas y necesidades
- El Equipo de Desarrollo ve el valor de implementar items que los desafíen técnicamente o por el contrario puedan implementar con su conocimiento actual
La labor del Product Owner consiste en balancear estos intereses para que los items acaben contribuyendo valor para todos los grupos involucrados.
El valor también puede conectarse con indicadores econométricos como por ejemplo estos:
- costo total de propiedad es decir cuánto le constara al cliente adquirir y operar el producto a lo largo de su vida útil. Aquí es importante hacer notar que un producto con baja calidad sera muy costoso de operar y su horizonte de vida es mas corto.
- costo de retraso que tiene que ver no solo con llegar tarde a un mercado con el riesgo de ser sustituidos por competidores, sino también con el costo interno de pagar salarios y otros gastos por un tiempo extendido.
- margen entre cuento dinero esta costando desarrollar el producto y cuanto se espera recuperar y en cuanto tiempo
Ordenando Items
Ordenar los items del Product Backlog no es una tarea que debe considerarse tomando solamente una única perspectiva, por ejemplo ordenarlos tomando en cuenta el tiempo estimado de implementación de los items.
Pensando sistemicamente [Senge90] el Product Owner deberá identificar cuales son las variables relevantes y luego analizar si prioriza una por encima de las otras cual será el impacto. Por ejemplo, un item puede tomar poco tiempo para implementarse pero una vez implementado produce poco impacto en los usuarios.
Estos son algunos ejemplos de variables o criterios relevantes:
- alineamiento estratégico con el objetivo que persigue el producto, es decir items que nos acerca mas a alcanzar la vision del producto
- valor de negocio percibido a través de items que harán que por ejemplo el producto se vaya distinguiendo de la competencia y el negocio mejore su imagen
- valor para el usuario final determinado por el grado en que el item ayude a resolver un problema o mitigar un dolor
- el tiempo de comercialización que se conecta a la noción de cuanto tiempo total pasa desde que se construye un item, se distribuye y se empieza recuperar la inversion
Creando y Refinando Items
Los items como tal pueden provenir de fuentes diversas como por ejemplo estas:
- Grupos de clientes que manifiestan sus necesidades y problemas que originan ideas de solución traducidas en items
- Requerimiento regulatorios como leyes y políticas de gobierno que fuerzan a que el producto incluya ciertas características
- Aprendizaje a través de validación de supuestos que derivan en items que si se deben incluir en el producto
- Defectos que se acarrean de Sprints pasados o peor aun de una versión previa del producto que ya esta en producción
- Cuestiones técnicas como componentes, librerías, parches de seguridad, plataformas, etc. que si bien tienen un valor técnico presentan un riesgo de tiempo y desvío de enfoque importante
Una forma dinámica e iterativa de crear nuevos items es utilizar el concepto de un estudio de diseño en el cual se dibuja y se hablar acerca del item, como si se estuviese diseñando alguna parte de una casa en el estudio de un arquitecto. Bajo este enfoque se dibuja cómo debería lucir el item dentro del producto, se habla de porque y quién lo utilizara, se exploran alternativas, y se comentan riesgos y desafíos.
Las conversaciones pueden quedar registradas en videos y los dibujos en fotografías, todo este material puede ir a un wiki interno. El titulo de el item es el que se anota en una tarjeta que ira dentro del Product Backlog, si se una una herramienta en linea como Google Spreadsheet la lógica es la misma, el titulo del item ira en una celda de una hoja llamada Product Backlog [Larman17].
Para incrementar el envolvimiento y contribuciones de los clientes en el Product Backlog es posible, y de hecho recomendable, tener reuniones semanales o aun mejor tener a los clientes sentados cerca del equip para poder comunicación y retroalimentación fluida
Para refinar los items del Product Backlog resulta muy util realizar juegos colaborativos en los cuales intervendran clientes y el Scrum Team y cuyo objetivo es entender mejor no solo los items sino el porque son necesarios.
El refinamiento de los items debe realizarse como una actividad recurrente para ir incorporando descubrimientos y conocimiento a medida que se adquiere. Tratar de hacer un solo refinamiento para todo el Backlog consume demasiado tiempo y no necesariamente aportara valor pues los items no prioritarios cambiaran y necesitaran de todas maneras ser refinados posteriormente.
El propósito del Product Backlog a veces puede ser mejor comunicado a través de herramientas como: hojas de ruta del producto, wireframes y mapas de historias de usuario [Patton14].
Un producto enorme aun puede ser trabajado a través de un backlog pequeño pero que provea valor siempre y cuando este backlog corresponda al lanzamiento de un producto minimamente viable, un lanzamiento para aprender (globo de ensayo), o un producto con el mínimo de características que lo hagan comercializable.
Conclusiones
El Product Backlog debe ser un elemento de uso cotidiano y que sirva para centralizar el trabajo y la discusiones del Scrum Team. Mas aun, debe reflejar el entendimiento actual del orden en el cual se quieren implementar los items para producir el mayor impacto posible.
Como tal este artefacto puede tomar formas diferentes pero en esencia no se debe perder de vista que es solamente una lista de cosas por hacer en un horizonte de tiempo finito.
Finalmente, el Product Backlog debe poderse ver, idealmente debe poderse tocar, para que cumpla mejor su función de elemento integrador y facilitador de la comunicación.
Bibliografia
Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill
Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday
Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley
Patton14 Patton J., 2014, User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media
