El objetivo del cálculo de la velocidad es determinar la capacidad de trabajo del equipo para un Sprint y, para este fin, se basa en la información recopilada de los Sprint anteriores.
La velocidad está relacionada con el método de estimación del tamaño de las historias. En el post anterior hablamos sobre cómo estimar el tamaño de las historias con "Puntos" y en este post seguiremos en esta misma línea.
Después de un par de post "teóricos" vamos a empezar con cuestiones prácticas. Uno de los aspectos que más quebraderos de cabeza nos dio al empezar a trabajar con Scrum fueron las estimaciones de las historias. Hemos probado varios mecanismos y, por fin, hemos encontrado uno que resulta manejable, útil y satisfactorio.
En mi opinión el Product Owner es el rol más crítico dentro de Scrum porque sobre él recae la responsabilidad de que el producto desarrollado cumpla con lo esperado y de que se adapte a las necesidades de quien lo va a utilizar. Es por esto que la elección del encargado de asumir este rol es uno de los aspectos más importantes a la hora de lanzar un nuevo proyecto Scrum.
Fuente: un artículo muy recomendable Top 10 failure modes of a Product Owner
El rol más difícil de asumir por los equipos que empiezan a utilizar Scrum es el Scrum Master. Probablemente este hecho se debe a que este rol no tiene equivalencia directa con los roles de las metodologías clásicas: equipo e interesados (stakeholders) siempre existen y para el Product Owner, la asociación más sencilla es la de "cliente" (en un post futuro trataremos el tema de cómo seleccionar un buen Product Owner). Pero ¿qué ocurre con el Scrum Master?
