Una adecuada gestión del Backlog es crucial para el éxito del trabajo realizado por el equipo. La responsabilidad de dicha gestión es del Product Owner (PO), quien es la última palabra en cuanto a su contenido, al Orden de ejecución y a la definición de cada "pieza de trabajo". En "
Gestión eficaz del Backlog" se indican 14 criterios que en conjunto se podrían utilizar para determinar dicho Orden de ejecución. Normalmente el PO se apoya en el equipo de desarrollo para gestionar el Backlog y para decidir el contenido de cada Sprint pero no deja de ser su responsabilidad. Pero hay un aspecto que muchas veces se pasa por alto o sin cuestionarlo demasiado: ¿Qué tipo de trabajo debería contener un Backlog o Sprint?. La respuesta inmediata podría ser: Historias de Usuario (HU). Scrum denomina "ítems" a los elementos del Backlog y de los Sprints, yo prefiero llamarlas UT (Unidades de trabajo). Pero más allá del nombre lo importante es a qué representa una UT. Es en esto en lo que me centraré en este post.
En el método ágil Extreme Programming (XP) se propone tener un Backlog con Historias de Usuario que a su vez se dividen en Tareas de programación. Es decir, se proponía tener dos niveles de gestión, uno al nivel de HU para la planificación y seguimiento visible para el cliente y otro al nivel de las tareas técnicas para los desarrolladores, llevando en cuenta que el término de todas las tareas asociadas a una HU conlleva el término de la HU.
En la Guía de Scrum solo se habla de "ítems". Sin embargo, se indica lo siguiente: "For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.". Es decir, puede haber una descomposición de los ítems en otros más pequeños pero no se indica explícitamente si se trata de tareas técnicas o si deben ser ítems "legibles" por el PO. Sin embargo, Scrum enfatiza que el PO es responsable de la gestión del Backlog con lo cual dichos ítems deberían ser definidos desde un punto de vista del cliente o usuario (no como tareas técnicas).
En cualquier caso, si trabajamos con dos niveles de descomposición del trabajo (nivel de UT y nivel de las tareas técnicas asociadas a cada UT) podríamos tener la mala tentación de, por ejemplo, preocuparnos de que la estimación de una UT que representa un requisito, se corresponda con las estimaciones de las tareas técnicas en las cuales de descompone. Digo "mala" porque estas estimaciones y registros de tiempo invertido en dos niveles probablemente nos complicarán la gestión del trabajo sin ganar significativamente mayor precisión :-).
Vamos ahora al grano en cuanto al contenido del Backlog y de un Sprint. Podemos identificar al menos cinco tipos de trabajo en el contexto de un equipo encargado al desarrollo y/o mantenimiento de un producto:
- Tipo 1. Cambios en el comportamiento del producto: implementación de Nuevos requisitos, Mejoras en requisitos ya implementados o Correcciones de fallo.
- Tipo 2. Tareas técnicas asociadas al proceso de cada cambio en el comportamiento del producto. Por ejemplo, Especificar requisitos, Diseñar, Programar, Probar, etc., actividades realizadas para cada uno de dichos cambios.
- Tipo 3. Tareas técnicas asociadas a la arquitectura del producto. Por ejemplo, cambios puntuales en el front-end, back-end, o en el esquema de la BD.
- Tipo 4. Tareas técnicas que no cambian el comportamiento del producto pero están en su contexto de trabajo. Por ejemplo, refactorizaciones del código (aquellas que no se asuman dentro de las implementaciones de cambios de comportamiento en el producto), cambios en la infraestructura hardware o software de los entornos de desarrollo o producción, tareas de automatización de procesos, tareas de automatización de pruebas, migraciones de datos, etc.
- Tipo 5. Otras tareas: investigación en nuevas tecnologías, formación del equipo, etc.
Claramente, el trabajo de tipo 1 lo podría solicitar y gestionar el PO (en su perspectiva de cliente del producto), es decir, este tipo de UT debe estar en el Backlog o en Sprint.
El trabajo de tipo 2 es la dimensión ortogonal a la dimensión de los contenedores (Backlog y Sprint), es decir, una UT al mismo tiempo que está en un contenedor estará en una cierta actividad de su proceso (en cierta columna de un tablero kanban). Ver "
Organización ágil del trabajo: Dos dimensiones" Con lo cual, estas actividades
NO tiene sentido incluirlas como UT en el Backlog o en Sprint, pues son las actividades por las cuales pasará una UT en su procesamiento y que son parte de un workflow, plasmado en un tablero kanban.
El trabajo de tipo 3 es una descomposición técnica de lo que conlleva la implementación del trabajo de tipo 1. Estas serían las tareas de programación a las que se refiere XP. Pero este trabajo de tipo 3 no lo debería gestionar el PO, son los desarrolladores quienes al momento de abordar una UT de tipo 1 decidirán la conveniencia de una descomposición desde una perspectiva estrictamente técnica. Estas tareas deberían estar "embebidas" en las UT de tipo 1 para que no compliquen la gestión desde la perspectiva del PO, pero que al mismo tiempo puedan gestionarse por los desarrolladores. Por ejemplo, una UT llamada "Facturas pendientes de pago", que muestra en un formulario la lista de facturas pendientes de pago, puede que cuando llegue a su actividad "Programar" sea descompuesta en tareas en paralelo al estilo: "implementar front-end", "implementar back-end", etc. Incluso en el caso de tener desarrolladores full stack puede que estas tareas técnicas las pueda realizar todas un mismo desarrollador, con lo cual puede que ya no sea tan interesante descomponer el trabajo técnico de programación.
La siguiente figura ilustra el trabajo el trabajo de tipo 1 (en la vista del PO) y tipo 3 (en la vista de los desarrolladores).
Las tareas de tipo 4 y tipo 5 no son gestionables por el PO pero es importante que se vean explícitamente como parte del trabajo del equipo pues al momento de realizarlas le restarán Capacidad, lo cual requerirá un acuerdo con el PO al momento de que se realicen. Bastaría con tener un filtrado sencillo de estas UT para que las pueda visualizar el PO o el equipo cuando estimen conveniente.
He visto con sorpresa en algunos equipos (y en repetidas ocasiones) que trabajan con un Backlog o Sprints donde en su gran mayoría solo hay UT del tipo 3. Los desarrolladores trabajan "cómodamente" con objetivos técnicos, y usualmente muy desconectados del resultado final (el cambio de comportamiento en el producto, el incremento que se espera y el valor aportado). Además, dicho resultado se ve postergado hasta integrar varias UT de tareas técnicas, que en el peor de los casos podría ocurrir después de varios Sprints. Scrum establece que el resultado de un Sprint debe ser un incremento del producto que potencialmente podría pasar a producción, es decir, aunque puede que no esté completa la funcionalidad, lo que ya está implementado debe ser operativo. Cuando esto no se cumple se está perdiendo una de las grandes ventajas que ofrece el trabajar con Sprints: la validación continua y frecuente del PO. Por ejemplo, si en un Sprint solo se ha conseguido implementar una parte back-end del producto el PO no puede validar nada. O si solo se ha conseguido implementar parte front-end pero no está operativa porque falta implementar e integrar con una parte back-end tampoco permitiría hacer una validación completa. Pienso que estos escenarios suelen darse en contextos donde el PO básicamente es un Jefe de Proyecto tradicional embestido de PO :-), el cual sigue repartiendo faena técnica a los desarrolladores y él lleva aparte la gestión de los compromisos con el clientes o los usuarios, probablemente en otro Backlog y Sprints :-).
Para terminar y asociado a la anomalía antes comentada os dejo un texto extraído desde https://www.scrum.org/about
Fighting “Flaccid Scrum”
By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of "Flaccid Scrum." Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.
Patricio Letelier
www.tuneupprocess.com
