Y eso es lo queremos conseguir, saber nuestra velocidad de avance de producto. Es lo que reflejaremos en nuestros digramas de burndown de proyecto. El problema es cuando mezclamos otras métricas con esta.
Y así en algunos equipos, se ven las historias de usuario como el mecanismo de reflejar el trabajo que se realiza. Y por tanto, surge la pregunta de cómo especificar tareas o trabajos que hacer como: montar el sistema de integración continua (“como desarrollador quiero…”), realizar una documentación para el departamento de marketing (“Como marketing quiero…”), etc. Cuando tenemos historias de este estilo puede significar varias cosas:
- Se ha perdido el objetivo de las historias de usuario: Que es descomponer un producto en partes más pequeñas que agregan valor.
- Hemos confundido el objetivo de una herramienta como las historias de usuario con nuestra necesidad de que nuestro trabajo esté reflejado en algún sitio.
El trabajo de un equipo que no queda reflejado directamente en historias de usuario, y por tanto no suma velocidad de avance real, no significa que no agregue valor o no sea necesario. Simplemente es otra cosa. No todo son historias de usuario.