Algunos maestros de scrum se preocupan por "aumentar" la velocidad de un equipo durante un sprint, como si una velocidad más alta fuera mejor. Pero los puntos son una medida relativa del trabajo que un equipo debe hacer para la característica X; no son altos o bajos, simplemente son más o menos que alguna otra característica que el equipo eligió arbitrariamente como punto de referencia. Lo importante es que sepas cuál es tu velocidad, por muchos puntos que sean.
Si los puntos son esfuerzo, no haces un mayor esfuerzo con el tiempo. Haces el mismo esfuerzo, pero es más productivo. Entonces, una historia que se estimó en cinco puntos cuando se formó el equipo por primera vez, podría eventualmente estimarse en tres o dos puntos a medida que el equipo aumenta sus habilidades.
¿Es eso correcto? No veo un consenso sobre si los puntos miden la complejidad o el esfuerzo, pero de cualquier manera me parece que a medida que pasa el tiempo, el esfuerzo percibido o la complejidad de una tarea disminuirá y podrá incluir más de ellos en un Sprint, manteniendo así su velocidad constante.
¿Debe aumentar la velocidad con el tiempo?
La respuesta simplista es que la velocidad de un proyecto solo debe aumentar hasta que el equipo haya desarrollado una cadencia estable y predecible que pueda mantenerse a lo largo del tiempo. Hay algunas advertencias, por supuesto, pero es una regla general sólida.
Apuntar a una tendencia ascendente indefinida en la velocidad es un "olor a proyecto" de que la métrica de velocidad se está usando mal o se malinterpreta. Esperar tal tendencia es a menudo un síntoma del deseo de la gerencia de presionar el botón "ir más rápido" sin respetar los límites de capacidad sostenible de un proyecto o equipo.
La velocidad es una medida de la capacidad histórica de un equipo, en lugar de una medida directamente relacionada con la velocidad o la productividad del equipo. Debe usarse principalmente durante la Planificación de Sprint para pronosticar la capacidad de Sprint Backlog para el próximo Sprint.
La capacidad de un equipo ciertamente puede cambiar con el tiempo: la capacidad puede disminuir durante los períodos de vacaciones o reorganizaciones, o aumentar a medida que los equipos adquieren conocimiento del dominio, aprovechan las mejoras iterativas en sus diseños basados en pruebas o pagan la deuda técnica.
Sin embargo, es una falacia suponer que la capacidad puede o debe tener una tendencia al alza. Aunque el cono de incertidumbre se reduce más adelante en un proyecto, el costo de la deuda técnica y las refactorizaciones generalmente aumentan, y estos factores también consumen la capacidad del equipo. Además, no es raro que la complejidad de las historias de los usuarios aumente con el tiempo a medida que se recoge la fruta madura del Product Backlog. Una vez más, esta complejidad adicional consumirá una cantidad proporcional de capacidad del equipo.
El objetivo de Scrum (y el desarrollo ágil iterativo en general) es tener una cadencia de desarrollo sostenible y predecible. Como tal, generalmente es mejor apuntar a una velocidad constante a lo largo del tiempo en lugar de aumentar la velocidad.
Los Story Points miden una combinación de Complejidad y Esfuerzo, que es lo que los hace difíciles de entender para las personas. El riesgo y la incertidumbre también son componentes probables que forman parte de la estimación.
Al final, la velocidad es una medida de lo que has entregado en los últimos (pocos) sprints. Es un indicador de lo que puede esperar entregar el próximo sprint cuando nada cambia mucho.
Vemos que los equipos de Scrum mejoran con el tiempo, sin embargo, mejoran en lo que hacen, automatizan cosas que consumen mucho tiempo en cada sprint, aumentan su conocimiento del dominio y comienzan a poder reutilizar el código. elementos de sprints anteriores para construir sobre ellos.
Como tal, es normal ver equipos aumentar su velocidad con el tiempo. A menudo, esa velocidad alcanza un techo, su capacidad máxima dadas las circunstancias actuales, y no podrán comenzar a escalar nuevamente sin un evento importante. Ese evento podría ser capacitación, cambios en la forma de trabajar, un nuevo miembro del equipo con un conjunto de habilidades clave o un cambio de una tecnología a otra (o simplemente una actualización de vold a vnew).
La mayoría de los equipos eligen un par de historias de referencia. Algunos simplemente eligen su 1, 5 u 8. Otros equipos eligen un 5 y un 20. Realmente no importa lo que elijan. Dados estos puntos de referencia, compara las otras historias con la solicitud original. Como tal, la cantidad de puntos de historia entre dos historias suele ser igual, aunque la cantidad exacta de esfuerzo se haya reducido drásticamente con el tiempo. Es por eso que un equipo puede aumentar su velocidad de 40 a 200 con el tiempo.
Cuando un equipo no siente que tiene suficiente granularidad en los tramos inferiores de sus puntos de historia, puede optar por elegir un nuevo 5 y ajustar todos los demás elementos en el trabajo pendiente en consecuencia.
Recuerde que aumentar la velocidad no es algo que debamos alentar todo el tiempo, tratar la velocidad como una métrica no ayudará a los equipos a comprender lo que realmente pueden hacer y, por lo general, conduce a un mal comportamiento cuando se trata de estimar. En su lugar, como experto en scrum, debe centrarse en eliminar los residuos y aumentar el valor entregado por sprint. Si el equipo tiene el mismo enfoque, su velocidad aumentará como resultado.
Los puntos de la historia son una medida relativa del esfuerzo. Con el tiempo, un equipo puede mejorar en hacer las cosas. Pero eso no significa necesariamente que una historia de 5 puntos se convierta en una historia de 3 puntos. Aquí hay un ejemplo:
La historia X implica escribir una función de búsqueda en una página web y el equipo la estima en 5 puntos. Story Y es una configuración para ocultar imágenes en una página web y el equipo lo estima en 3 puntos porque, en relación con Story X, es más pequeño.
Ahora digamos que el equipo mejora enormemente el próximo año, de modo que pueden hacer tanto la Historia X como la Historia Y en la mitad del tiempo que les tomó originalmente. Pero tenga en cuenta que el tamaño relativo de las dos historias no ha cambiado. Por esta razón, el equipo aún podría estimarlos como 5 puntos y 3 puntos respectivamente.
Sin embargo, si el equipo mejoró su habilidad para hacer la Historia X pero no mejoró su habilidad para hacer la Historia Y, entonces los tamaños relativos cambiarían. Ambos podrían, quizás, convertirse en historias de 3 puntos.
Un equipo puede decidir restablecer su línea de base para lo que es un punto de la historia. La desventaja de esto es que perderán algo de valor de su historial de velocidad, ya que ya no será una buena guía de cuál es su capacidad para futuros sprints. Pero no hay nada que impida que un equipo haga esto .
Lo importante a recordar es que la velocidad se trata simplemente de medir la capacidad de futuros sprints. Los números en sí son arbitrarios, pero los tamaños relativos de los números son importantes.
Tienes razón: los puntos de la historia son esencialmente sobre el esfuerzo. Al tomarlos como una medida del rendimiento de su equipo, y dado un equipo estable y un entorno estable, debe esperar que la velocidad se estabilice con el tiempo, no que aumente (aunque un aumento podría ser un efecto de dicho proceso).
Los puntos de la historia no tratan sobre la complejidad de desarrollar una característica; se refieren al esfuerzo requerido para desarrollar una función.
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity