Scrum proviene de la forma en que en el rugby se pone en marcha el juego después de una infracción en las reglas del juego.

Más que una metodología de desarrollo define un marco de gestión para proyectos de desarrollo ágiles. Su principal objetivo es que cada entrega después de cada iteración maximice el valor del negocio para el que el software ha sido construido. Se basa en la realización de iteraciones cada 15 á 30 días (4 semanas típicamente), que en la jerga del modelo se denominan Sprints.

Los equipos de desarrollo son autoorganizados. Esto significa que el plan se desarrolla en base a un objetivo o conjunto de objetivos definidos para el Sprint y no a las tareas concretas que inicialmente pueden haber sido previstas. El equipo elige el orden más adecuado en reuniones de 10 a 15 minutos diarias (Scrums) donde se informa de lo avanzado, de las dificultades encontradas y se determinan las acciones a realizar durante el día para cumplir con los objetivos del Sprint.

El equipo se constituye de 4 a 8 persones con los roles siguientes:

• Product Owner: Representa al cliente o al usuario del producto que construye el equipo. Puede ser el mismo cliente, pero cuando no es posible, vela por los intereses del cliente y es el nexo de unión entre el equipo de desarrollo y el cliente.
• Scrump Master: Desempeña el rol de jefe de proyecto. Es el encargado de informar de las prioridades del cliente al equipo y orientarlo en el desarrollo de las tareas que mejor cumplan los objetivos del proyecto. También es el encargado de eliminar los obstáculos que se puedan presentar y que impiden los avances del equipo.
• Team Member: Cualquier otro integrante del equipo. Programadores, arquitectos, testers, administradores de bases de datos, etc.

Scrums emplea el término “backlog” para definir a un conjunto de elementos que están relacionados. Define tres backlogs en el proceso:

• Product backlog: Representa todos los requisitos que el producto entregado debe cubrir. Los requisitos se recogen definidos muy alto nivel e incluyen una estimación de coste de desarrollo que serán usadas en la definición de los Sprint Backlogs.
• Release backlog: es una lista ordenada por prioridad de los requisitos que aparecen en el Product backlog. No hay prioridades duplicadas y la estimación de coste de desarrollo es más detallada que la del product backlog.
• Sprint backlog: Al comienzo de cada Sprint el equipo del proyecto va extrayendo y descomponiendo los elementos del Release Backlog empezando por los de mayor prioridad y los va introduciendo en el Sprint backlog, hasta que tiene suficientes elementos como para realizar el Sprint. En este momento el Sprint backlog se bloquea de modo que durante el sprint no se admiten modificaciones a los requisitos que se van a cubrir.

El Burndown Chart es otro elemento importante relacionado con los Backlogs. Se emplea para controlar los elementos en el Sprint Backlog pendientes por completar en el Sprint en curso. Se actualiza diariamente con objeto de que el equipo tenga feedback del grado de cumplimiento de los objetivos del Sprint.

Al finalizar un Sprint, se tiene una release que se muestra al cliente y usuarios con objeto de demostrar los avances obtenidos y para evaluar las prioridades del siguiente Sprint. También se informa de los problemas detectados, se analizan las peticiones de cambio y su impacto y se discuten las posibles soluciones.

Scrum no impone prácticas por lo que se combina bien con otras metodologías que sí las proporcionan como RUP o Agile UP y suele combinarse a menudo en proyectos más pequeños con XP.

Desde el punto de vista de proyectos de mayor dimensión, los equipos pueden formar parte de uno mayor, también guiados mediante Scrum o mediante gestión de proyectos clásica.