Voy a ser muy directo: me da igual. Espera, matizo: tantas historias de usuario como sean necesarias para conseguir el Objetivo del Sprint.

Por cierto, las historias de usuario no son obligatorias en Scrum, puesto que el Product Backlog puede componerse de elementos de naturaleza diversa: errores, experimentos, casos de uso -en desuso-, requerimientos no funcionales, etc. Las historias de usuario son, eso sí, una forma bella de expresar los requerimientos de producto en términos de valor para el usuario. Y valor para el usuario con Scrum debemos crear. ¿Para qué todo este tinglado de ceremonias y palabrejas si no?

Vuelvo a la pregunta del enunciado. Hay gente que dice que en cada Sprint debemos completar entre 6 y 12 historias de usuario (aka elementos del Product Backlog). Gente respetable, como Ralph Jocham. A mí lo de dar un número genérico y utilizarlo como best practise no me convence. No lo veo.

Prefiero hablar de ritmo durante el Sprint, es decir, de cómo gestionamos el trabajo en curso:

– Si hacemos Sprints de un mes -máxima duración que permite Scrum, una eternidad en los tiempos que corren- y en todo el Sprint entregamos una única historia de usuario, esto y no utilizar historias de usuario es lo mismo. Pongo el caso extremo, obvio, pero para que se entienda lo que intento decir.

– Lo conveniente será que, cada día del Sprint, o cada par de días, completemos alguna historia de usuario de las seleccionadas para el Sprint Backlog. O sea, queremos que haya vidilla, alegría.

– Esa cadencia de pedaleo -ya hablaremos de ciclismo y Scrum otro día- es vital. No queremos tener a los testers de brazos cruzados hasta el final del Sprint, y soltarles, de sopetón, una pila de historias de usuario cuasi-terminadas. Ahí es cuando vienen las prisas, los agobios, los errores de última hora, las noches sin dormir. No hay necesidad, es cuestión de ritmo durante el Sprint. Queremos hacer el testing y entregar a lo largo del Sprint.

– Este ritmo nos lo da la experiencia y la forma en que troceemos las historias de usuario. En el Sprint, como regla general, no debemos introducir historias de usuario que no están ready (el otro día hablábamos de la definición de ready aquí). Aquellas historias gigantes, que siguen siendo epics sin desagregar, no nos ayudan a encontrar ritmo. Queremos historias lo suficientemente pequeñas y que sean entendidas por el Equipo de Desarrollo. Masticadas antes de la Sprint Planning, a ser posible. El refinamiento del Product Backlog es clave.

– Cuando tenemos ese ritmo, otras muchas cosas buenas pasan. Además de aumentar la motivación, al sentir que estamos avanzando, podemos empezar a poner funcionalidad en producción tal y como esta se termina, en lugar de esperar al final del Sprint o a la Review. Continuous deployment, we love you so much.

¿Cuántas historias de usuario hace tu equipo por Sprint? ¿Tenéis vuestro número mágico?