Los sprints, la herramienta para cumplir los objetivos en el mundo Scrum

Los sprints, la herramienta para cumplir los objetivos en el mundo Scrum

Antes de entrar en los aspectos técnicos de cómo definir un sprint veamos su origen, más allá del símbolo deportivo. A los inicios de los 90, con el alumbramiento de Internet, Media Lab, situada cerca del MIT, hacían proyectos de todo tipo, desde robots a tinta electrónica usada tiempo más tarde para los e-books. Media Lab contrataba los alumnos que salían del laboratorio, personas llenas de ideas y con mucha capacidad.

Media Lab seguía siempre la misma política para cada uno de los proyectos. Cada tres semanas el equipo de trabajo debía hacer una demostración abierta del proyecto en el que estaba trabajando. Cualquier persona de la empresa podía asistir y preguntar en las demos. En el caso que la demo no funcionara o no gustara al público los directores eliminaban el proyecto. Esta política obligaba a los alumnos a realizar los proyectos de una forma brillante y a gran velocidad. Los alumnos recibían feedback muy rápidamente por parte de gente de distintas disciplinas. De este modo evitaban que un proyecto avanzara en una dirección incorrecta.  

Moraleja: Cuanto antes se entregue al cliente, antes nos dirán si hacemos lo que necesitan.

Una parte muy importante en el Scrum es la definición del Sprint. Es un momento sagrado, se deciden los objetivos del equipo en base al contenido del backlog durante un espacio de tiempo. Un sprint, como concepto, tiene una duración determinada y constante, no varía en el tiempo. Los sprints duran entre una y cuatro semanas. Las tareas que entran en un sprint son sólo las que se pueden realizar en el periodo de tiempo. Al final de cada sprint debemos conseguir tener alguna cosa terminada, que pueda utilizarse. Podemos afirmar que la reunión de definición del sprint y la reunión diaria son los momentos más importantes de la semana.

Ventajas: Trabajar con entregables del producto en espacios pequeños de tiempo nos proporciona el feedback por parte del cliente para avanzar en la buena dirección y tener un producto siempre funcionando.

Inconvenientes: Debemos plantear la evolución del proyecto en base a tener siempre el producto funcionando. Cuando debemos abortar un sprint? Esto quizás será un post en el futuro.

La herramienta para definir el sprint es una reunión del equipo completo, en le que de forma conjunta por todos los integrantes del equipo, se decidirá que se puede realizar durante el sprint que se define. El método apropiado para el calculo de la estimación de cantidad de trabajo es mediante el poker plan (puedes leer como funcióna en este post) y la velocidad de trabajo, gracias a su cálculo el equipo tendrá una media de puntos por sprint, de modo que será fácil estimar la cantidad de trabajo que se realiza en este espacio de tiempo. A parte, es un momento de cohesión de grupo muy importante, puesto que de forma colectiva y horizontal todo el equipo ha marcado los objetivos de la semana.

El equipo decide también las prioridades? No. El responsable (en el desarrollo de software sería el product owner) es quien tiene la obligación de ordenar las tareas en el backlog, de modo que cuando el equipo empieza a definir el sprint siempre empezará por arriba del backlog e irá bajando a medida que se vaia vaciando.

Los expertos recomiendan que la definición del sprint no se puede hacer el lunes por la mañana, el equipo no está con ritmo suficiente y suele ser el día con más ausencias por enfermedad estadísticamente. Tampoco es una buena opción los viernes, y menos por la tarde, el equipo está cansado y pensando en el fin de semana. De modo que se recomienda considerar el inicio y el fin del sprint entre martes y jueves.

Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast - CEO at Pease Networks

CEO en Please Networks. Fullstack developer y believer en la vida real. Me gusta el trabajo en equipo y conseguir objetivos colectivos. Desarrollando con PHP y AngularJS. AWS para la infraestructura. Amante del agile y el TDD. Training Cloud y Scrumízate mis proyectos personales.