Recientemente, Buddha Buck pregunto en la lista de Extreme Programming si existe una media de velocidad que podría ser considerada "buena" para un equipo de siete personas que realiza iteraciones de dos semanas. Sintió que una velocidad de ocho para abajo indicaría que las historias estarían muy grandes. El debate sobre el tema consiguió responder a esta y otras cuestiones que se plantearon también.

La velocidad se utiliza como una herramienta para predecir la productividad futura del equipo. Si todas las historias que el equipo ha trabajado son del mismo tamaño en lo que respecta a la cantidad de trabajo necesario para implementarlas, entonces bastaría con contar el número de historias que el equipo terminó por iteración. Un determinado equipo probablemente terminaría el mismo número de esas "historias del mismo tamaño" en cada iteración, y la gerencia podría hacer planes conforme la capacidad conocida de ese equipo.

En muchos lugares, las historias no son todas del mismo tamaño. Sin embargo, las historias reciben tamaños relativos, a menudo llamados estimaciones. Una historia de tamaño dos tiene el doble del tamaño de una historia de tamaño uno. Una historia de tamaño tres, tiene tres veces el tamaño, y así sucesivamente. Es razonable esperar que las historias de tamaño dos, en promedio, tomen el doble del tiempo en ser completadas en relación con las historias de tamaño uno. Para faciliar estas estimaciones, los tamaños se mide en una unidad llamada "puntos" o "puntos de historia". Por lo tanto, podemos decir que una historia de cinco puntos, probablemente va a demorar cinco veces más que una historia de un punto. En promedio, un equipo es propenso a completar el mismo número de puntos de esfuerzo de trabajo en cada iteración, este número es la velocidad del equipo. Por lo tanto, la velocidad es la capacidad de realización del equipo. Mide la cantidad de trabajo que un equipo puede producir en cada iteración.

Steven E. Newtondiz dice que "Una buena velocidad es aquella que puede dar una idea clara de la cantidad de trabajo que se puede realizar en las siguientes iteraciones".

Kent Beck señaló otro de los beneficios de saber la velocidad del equipo:

Otro propósito de medir la capacidad es mejorar el flujo de entrega. Si planea que puede ofrecer menos, tendrá menos de lo que su equipo podría conseguir. Si planea así, tendrá menos de lo que realmente puede entregar.

Charlie Poole recordó a los participantes que los desarrolladores tienden a pensar en la cantidad de trabajo que será necesaria para implementar las historias, mientras que los gestores y los clientes piensan en la cantidad de valor que se entrega cuando las historias se completan. Es importante señalar que la estimación de la historia y la velocidad están relacionadas con la cantidad de trabajo existente y el tiempo necesario para completarlo.

El aspecto más elemental de la pregunta de Buddha fue respondido, pero continuó la discusión mediante el examen de algunos de los problemas más comunes de esta pregunta. En particular, el Buddha llegó a la conclusión de que las historias de su equipo eran demasiado grandes. Los participantes confirmaron que es mejor historias pequeñass que grandes.

Tim Ottinger comentó que las historias menores proveen puntos de control mas frecuentes y ayudan al equipo y los patrocinadores a conocer la cantidad de trabajo ya hecho en determinado momento.

Por supuesto, ninguna historia debería ser mayor que una iteración. La mayor historia de la iteración corre un gran riesgo de no ser completada. No deseamos entrar en una situación en la que tenemos N puntos o 0 puntos. Sería bueno si tuviera el 40% de los puntos cumplidos en el medio de la iteración.

Steven Gordon también compartió algunos consejos.

• Si no estás seguro de que las historias son realmente pequeñas, entonces probablemente son muy grandes.
• Si las historias fueran demasiado pequeñas, el equipo se dará cuenta que la sobrecarga del seguimiento parece un desperdicio.
• Los problemas derivados de las historias muy pequeñas son inferiores a los derivados de las grandes historias. Así, es mejor errar para menos que para más.
• Si las historias muy pequeñas son el mayor impedimento que un equipo tiene, celebren juntos. Son maestros en XP.

Ron Jeffries dijo que le gusta ver las historias de un tamaño tal que un par de programadores pueden terminarlas en una semana. Fue menos entusiasta con el concepto de puntos:

Creo que los puntos son una tontería y me arrepiento de haberlos recomendado con tanto énfasis. Hacen que nosotros nos distrigamos de lo más importante, que es partir la historia, hasta que ellas sean pequeñas y se puedan hacer casi a un ritmo constante.

¿Cómo tu equipo decide el tamaño que tienen las historias? ¿Usás la velocidad del equipo como un indicador de tamaño?

Basado en Uma Velocidade Boa