Historias técnicas

He aquí un asunto complejo: historias técnicas. O elementos no-funcionales, o como quieras llamarlos.

Me refiero a cosas que deben hacerse pero que no son un entregable ni están directamente relacionadas con ninguna historia específica, y no son de valor inmediato para el Dueño de Producto.

Las llamamos “historias técnicas”.

Por ejemplo:

Instalar un servidor de compilación continua:
- Por qué debe hacerse: porque ahorra cantidades inmensas de tiempo a los desarrolladores y reduce el riesgo de problemas explosivos de integración al final de la iteración.
Escribir una descripción general del diseño:
- Por qué debe hacerse: porque los desarrolladores olvidan constantemente el diseño general, y entonces escriben código inconsistente. Necesitan una visión global documentada para mantener a todo el mundo en la misma línea de diseño.
Refactorizar la capa de acceso a datos:
- Por qué debe hacerse: porque la capa de acceso a datos se ha vuelto realmente desordenada y le está costando tiempo a todo el mundo debido a la confusión y los errores innecesarios. Limpiar el código ahorraría tiempo a todo el mundo y mejoraría la robustez del sistema.
Actualizar Jira (seguimiento de errores)
- Por qué debe hacerse: la actual versión es demasiado lenta y falla demasiado. Actualizar a una nueva versión ahorrará tiempo a todo el mundo.

¿Son historias en el sentido normal? ¿O son tareas que no están conectadas a ninguna historia específica? ¿Quién las prioriza? ¿Debería involucrarse el Dueño de Producto en estos asuntos?

Hemos experimentado mucho con diferentes maneras de manejar las historias técnicas. Hemos intentado tratarlas como historias de primera clase, como todas las demás. Esto no funcionó bien, ya que cuando el Dueño de Producto priorizaba la Pila de Producto era como comparar peras con manzanas. De hecho, por razones obvias, las historias técnicas obtenían siempre mínima prioridad con razonamientos del tipo “sí, chavales, seguro que la compilación continua es muy importante y todo eso, pero construyamos primero algo que nos permita facturar, ¿vale? Entonces podréis añadir vuestras chucherías técnicas más adelante, ¿OK?”

En algunos casos el Dueño de Producto tiene razón, pero a menudo no es así. Hemos concluido que el Dueño de Producto no siempre está cualificado para manejar estos compromisos. Así que esto es lo que hacemos:

Intentamos evitar las historias técnicas. Busca efusivamente formas de transformar las historias técnicas en historias normales con valor de negocio mensurable. Así el Dueño de Producto tendrá mejores oportunidades para realizar decisiones correctas entre los pros y los contras.
Si no podemos transformar una historia técnica en una historia normal, intentamos ver si es posible hacerla como una tarea dentro de otra historia. Por ejemplo, “refactorizar la capa de acceso a datos” podría ser una tarea dentro de la historia “editar usuario”, ya que esto involucra utilizar la capa de acceso a datos.
Si lo anterior falla, definirla como historia técnica y mantener una lista separada con dichas historias. Permitimos al Dueño de Producto que vea dicha lista, pero no que la modifique. Usamos los factores de dedicación y la velocidad estimada para negociar con el Dueño de Producto y sacar algo de tiempo del Sprint para implementar estas historias.

Ejemplo (un diálogo muy similar a este ocurrió durante una de nuestras reuniones de planificación de Sprint):

Equipo: “Tenemos algunos asuntos técnicos internos que deben hacerse. Nos gustaría presupuestar un 10% de nuestro tiempo para ello, es decir, reducir el factor de dedicación del 75% al 65%. ¿Os parece bien?”
Dueño de producto: “¡Y una leche! ¡No tenemos tiempo!”
Equipo: “Bueno, mira el ultimo Sprint (todas las cabezas se giran hacia la velocidad que está apuntada en la pizarra). Nuestra velocidad estimada fue 80, y la velocidad real fue de 30, ¿correcto?”
Dueño de Producto: “¡Exacto! ¡Así que no tenemos tiempo para asuntos técnicos internos! ¡Tenemos que añadir nuevas funcionalidades!”
Equipo: “Bueno, la razón por la que nuestra velocidad fue tan mala fue que pasamos demasiado tiempo intentando conseguir versiones consistentes para probar”.
Dueño de Producto: “Sí, ¿Y?”
Equipo: “Así que proponemos dedicar un 10% de nuestro tiempo del Sprint para implementar un servidor de compilación continua y otras cosas que nos ayudarán a hacer la integración menos penosa. Esto incrementará nuestra velocidad al menos un 20% para los próximos Sprints, ¡para siempre!”.
Dueño de Producto: “¿En serio? ¿Y por qué no lo hicimos en el último Sprint entonces?”.
Equipo: “Eh…porque no querías que lo hiciéramos…”
Dueño de Producto: “Oh, um, bueno, vale, parece una buena idea hacerlo ahora entonces…”

Por supuesto, la otra opción es simplemente mantener al Dueño de Producto fuera del ciclo o darle un factor de dedicación no negociable. Pero no hay excusa para no intentar llegar a un consenso primero.

Si el Dueño de Producto es un tipo competente y razonable (y nosotros hemos tenido suerte en eso) yo sugiero mantenerle lo más informado posible y permitirle establecer las prioridades generales. La transparencia es uno de los valores principales de Scrum, ¿no es cierto?