Uno de los pilares sobre los que se sustenta SCRUM es la Transparencia y una de las recomendaciones principales para alcanzar esta Transparencia es asegurarse que cuando decimos que una funcionalidad o tarea ha sido terminada, todos los involucrados (Scrum Master, Product Owner, equipo e interesados) esperan y entienden lo mismo.
En el ámbito de Scrum existen dos iniciativas: Scrum Alliance (Scrum Master) y Scrum.org (Scrum Manager). Resumiendo mucho, la primera está orientada a la "procedimentación" de la aplicación de Scrum, definiendo prácticas, roles y reuniones, mientras que la segunda, sin embargo, es menos "académica" y se centra en la aplicación práctica de Scrum y está orientada a garantizar la flexibilidad del proceso (tenéis más información al respecto en el siguiente artículo: Scrum Manager y Scrum Alliance: dos estilos diferentes de hacer Scrum).
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?
