El ciclo de vida de MCS-Scrum se estructura en 2 fases:

• Conceptualizacion: ¿Estamos de acuerdo con el alcance y los objetivos del proyecto y si el proyecto debe o no continuar?
• Construcción del producto: ¿La aplicación está completa e implantadae en su totalidad en producción a toda la comunidad de usuarios?

La fase de Conceptualizacion es común tanto a la metodología MCS-Scrum como a MCS-OpenUp y su objetivo es generar una visión y un modelo conceptual de la solución que permita dar comienzo al proyecto de desarrollo. Para el caso de MCS-Scrum se permite que el alcance de la solución no esté cerrado y que sea flexible a cambiar a lo largo del proyecto. De cualquier forma, es necesario tener un objetivo claro para todos los interesados y un presupuesto (de tiempo y recursos) establecido.

La fase de Construcción del producto está compuesta por múltiples ciclos de Sprints de liberación los cuales están pensados para liberar al ambiente de producción un incremento de la solución que está validada y lista para colocar a disposición de los usuarios. Cada Sprint de liberación está compuesto por uno o varios Sprints de construcción, en donde el objetivo es entregar in incremento de la solución que sea de valor a los interesados del proyecto, pero no necesariamente a ser implantada en producción. El resultado de un Sprint de construcción generalmente se coloca a disposición de los usuarios y del Scrum Product Owner para la realización de las pruebas UAT (pruebas de aceptación de usuarios). 

Al comienzo de cada sprint se lleva a cabo una reunión de planificación de Sprint durante la cual el Scrum Product Owner prioriza el Backlog del producto y el Equipo Scrum selecciona las tareas que pueden completar durante el próximo Sprint.

Estas tareas se trasladan del Backlog del producto al Backlog del sprint.

Cada día durante el sprint se lleva a cabo una breve reunión diaria llamada Scrum diario, que ayuda al equipo a mantenerse en el camino. Al final de cada sprint, el equipo demuestra la funcionalidad completa en una reunión de Revisión del Sprint. Los scrums diarios sean una excelente manera para que un equipo Scrum difunda información de estado; si está interesado en saber dónde están las cosas, asista a la reunión de ese día. El scrum diario no se usa como una reunión de resolución o resolución de problemas. Los problemas que se plantean se desconectan y, por lo general, el subgrupo relevante los trata inmediatamente después del scrum diario.

Durante el scrum diario, cada miembro del equipo proporciona respuestas a las siguientes tres preguntas:

1. ¿Qué hiciste ayer?
2. ¿Qué vas a hacer hoy?
3. ¿Hay algún impedimento en tu camino?

Al centrarse en lo que cada persona logró ayer y logrará hoy, el equipo obtiene una excelente comprensión de qué trabajo se ha realizado y qué trabajo queda. El scrum diario no es una reunión de actualización de estado en la que un jefe recopila información sobre quién está retrasado. Más bien, es una reunión en la que los miembros del equipo se comprometen entre sí. Si un programador se pone de pie y dice "Hoy terminaré el módulo de almacenamiento de datos", todos saben que en la reunión de mañana dirá si terminó o no. Esto tiene el maravilloso efecto de ayudar a un equipo a darse cuenta de la importancia de estos compromisos y que sus compromisos son entre sí, no con un cliente lejano. En los casos en que el Scrum Master no puede eliminar estos impedimentos directamente por sí mismo (por ejemplo, generalmente los problemas más técnicos), aún asume la responsabilidad de asegurarse de que alguien en el equipo resuelva rápidamente el problema.