Las reglas de Scrum (II): Durante el Sprint

Depués de hablar de las reglas relativas al Sprint planning meeting le toca el turno a las reglas que rigen que ocurre durante un Sprint:


 El Sprint es limitado en el tiempo a 30 días consecutivos en el calendario. Sin considerar otros factores, esta es la cantidad de tiempo necesaria para que un Equipo pueda construir algo de interés significativo para el Product Owner y los stakeholders y llevarlo a un estado en que sea potencialmente entregable. Este es también el máximo tiempo que puede ser asignado sin que el Equipo tenga que hacer tanto trabajo que requiera artefactos y documentación para soportar su proceso de razonamiento. Es también el máximo tiempo que la mayoría de los stakeholders esperarán sin perder interés en el progreso del equipo y sin perder su convencimiento de que el Equipo está haciendo algo significativo por ellos.


  • El equipo puede buscar consejo, ayuda, información y soporte fuera de él mismo durante el Sprint.

  • Nadie puede proporcionar consejo, instrucciones, comentarios o dirección al Equipo durante el Sprint. El Equipo es completamente autogestionado.

  • El Equipo se compromete con el Product Backlog durante el Sprint planning meeting. No se permite a nadie cambia el Producto Backlog durante el Sprint. El Producto Backlog esta congelado hasta el final del Sprint.

  • Si se prueba que el Sprint no es viable, el ScrumMaster puede terminarlo anormalmente e iniciar un nuevo Sprint planning meeting para comenzar un nuevo Sprint. El ScrumMaster puede hacer este cambio por su voluntad o a petición del Product Owner. El Sprint puede no ser viable si la tecnología plantead no se puede emplear, si las condiciones del negocio cambian con el resultado de que el Sprint no será de valor para el negocio, o si el Equipo sufre interferencias de personas ajenas a él mismo durante el Sprint.

  • Si el equipo se siente incapaz de completar todo el Product Backlog comprometido durante el Sprint, puede consultar con el Product Owner que elementos quitar del Sprint actual. Si se eliminan tantos elementos que el Sprint pierde su valor y significado, el ScrumMaster puede terminar anormalmente el Sprint.

  • Si el Equipo determina que puede abordar más Product Backlog durante el Sprint que el seleccionado durante el Sprint planning meeting, puede consultar al Producto Owner que elementos adicionales del Product Backlog pueden ser añadidos al Sprint.

  • Los miembros del Equipo tienen dos responsabilidades administrativas durante el Sprint: Acudir al Daily Scrum meeting, y mantener actualizado y públicamente disponible el Sprint Backlog. Nuevas tareas pueden ser añadidas al Sprint Backlog según sean detectadas, y la estimación contínua realizada día a día para cada tarea debe ser mantenida actualizada.

3 comentarios sobre “Las reglas de Scrum (II): Durante el Sprint”

  1. Entiendo que en el sprint se realiza la implementacion del software en si, o parte de él.

    ahora ese sprint puede tener fases claras, como OMT++???

    puede tener un analisis de los requerimientos seleccionados, un diseño de estos y su implementacion??? o solo se implementa??

    de ante mano gracias

  2. Hola Manuel:

    El análisis de los requisitos en Scrum es algo que se hace a priori, construyendo un Product Backlog, labor que realiza el Product Owner (rol asimilable al de Product Manager).

    Luego antes de cada sprint, durante el Sprint Planning Meeting, los requisitos se detallan.

    Durante el sprint, el equipo lleva a cabo del diseño técnico y la implementación de esos requisitos. No hay fases claras y marcadas sino que las actividades propias del desarrollo se solapan.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *