Demasiadas veces «la Agilidad» me recuerda al pobre Hodor. Año tras año, temporada tras temporada, diciendo, con un esfuerzo que llegaba a dar ansiedad verlo, algo tremendamente simple, a la vez que transcen
dental para comprenderlo todo… y nadie le entendía. Jamás nadie llegó a interiorizar su mensaje, aquel tan simple, hasta que se murió, e incluso… ni en ese momento.
Pues la Agilidad es una especie de Hodor en el salvaje mundo de la gestión actual. Y ejemplos de sus mensajes simples, pero profundos, que se repiten miles de veces, que nadie entiende, y que son la clave de mucho… tienes los que quieras.
De hecho, venga, vamos con este… ¿qué «cosas» van en un Product Backlog? Product Backlog, sí, ese repositorio cuyo nombre viene de Scrum, priorizado por valor y que gestiona un Product Owner (ahí es nada).
Tendremos claro que nueva «funcionalidad» al producto a añadir va en el Product Backlog, pero… ¿algo por lo que el cliente va a pagar y que no es funcional también va? ¿que me pida que le montemos una BBDD iría? ¿que él me pida el entregable de que le diseñe las pantallas de la aplicación en un Powerpoint y pague por ello… iría? ¿que me pida un estudio – análisis él… iría? ¿y los bugs? ¿y quitar deuda técnica? uff, esto se complica… despacio… vamos a ello…
Qué dice el Shu*
Para los que le gusta profesar, la poco ágil práctica de seguir al pié de la letra un framework, en la guía de Scrum (la oficial, no las otras, si hay que profesar profesemos bien), cuando se menciona al Product Backlog vienen cosas como «list of everything that is known to be needed in the product», «single source of requirements for any changes to be made to the product», «lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases».
Nótese en este punto, volveremos a ello, que si me guío por la guía, pone muchas cosas que van al Product Backlog, pero… siempre acaban en el Producto.
Y otra cosa más antes de empezar la fiesta: Scrum no habla de Historias de Usuario, eso es más de eXtreme Programming, pero todos las usamos con Scrum, representan funcionalidad que se añade al producto, son «end-to-end», pequeñas, tienen valor, etc. En este caso hay poca duda, están en el el Product Backlog, su correcta creación y priorización cae en el ámbito del Product Owner, etc.
Pero dicho esto, que puede ser hasta obvio, vamos ahora con el rock duro, de menos a más heavy, del 1 al 4, que pasa en el caso de…
1 – Entonces, las acciones para la mejora (reducción) de la Deuda Técnica… ¿van al Product Backlog?
Aquí ya hay que mover la sesera. Crear pruebas unitarias, quitar «copy-paste«, mejorar la integración continua, reducir complejidad ciclomática, etc., son cosas a las que hay que dedicarles un tiempo en cada Sprint, recuerda que el ciclo de vida ágil es iterativo e incremental (el ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental). Entonces… ¿Qué hacemos con todo eso? ¿va al Product Backlog?
En ámbitos en los que el Product Owner conoce mucho del negocio, lo lógico, y nada de asuntos técnicos, meter cosas técnicas (necesarias, pero que no ha pedido el cliente) en el repositorio que gestiona el Product Owner suena raro. El Product Owner tendría que priorizar asuntos técnicos (en este caso, repito, que no pide el cliente). Raro.
Para las pruebas unitarias y similares es recomendable dos opciones complementarias:
– Que sean Tareas (que no Historias) derivadas de una Historia (que entren en ese cómo, en vez de el qué, cuyo repositorio a la hora de trabajarlas será un Sprint Backlog, que no un Product Backlog).
– Que estén en un repositorio aparte, cuando no se derivan de una Historia, que ese repositorio gestione el equipo técnico y que se bloquee un porcentaje de tiempo del Sprint a trabajar en ellas.
Ojo, de hecho (lo he vivido), meterlas en el Product Backlog conlleva el riesgo de que el Product Owner nunca les de prioridad («el Cliente no las pidió y no sé ni que son»).
Una cosa más, aquí, en tareas de Deuda Técnica, meto Tareas que no pide el Cliente, ni el Usuario. Si el Cliente nos pidiera algo Técnico, no hablo de funcional, entonces estaríamos en el caso…
.
.
Esto empezó como un post a lo Hodor: breve y conciso… y, de nuevo, se me ha ido de extensión. Y mucho, lo he dividido en dos y hasta cada una de las dos partes ya me parece larga para lo que habitúo.
Así que para mañana me dejo lo bueno, para mañana… 2 – ¿Y qué pasa con las Historias Técnicas?, 3 – ¿Y los bugs van al Product Backlog? y 4 – Y otras cosas que pide el cliente, o que le vamos a facturar… ¿van al Product Backlog?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023