Las reglas de Scrum (I): El Sprint Planning Meeting

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente, y  que uno de los motivos por los que me gusta es porque tiene reglas claras. Creo que una buena aproximación para conocer Scrum es conocer sus reglas y por eso he decido traducirlas al castellano. La fuente de estas reglas es el libro Agile Project Management with Scrum de Ken Schwaber.


El Sprint planinng meeting es una reunión que tiene una duración fija de no más de 8 horas, divididas en dos partes iguales de 4 horas. La primera parte sirve para seleccionar el Product Backlog y la segunda para preparar el Sprint Backlog.



  • Los asistentes son el ScrumMaster, el Product Owner y el Equipo. Otras partes pueden ser invitadas por cualquiera de los anteriores para proporcional información adicional sobre el dominio del negocio o la tecnología, pero saldrán una vez proporcionen esta información. No hay gallinas como observadores.

  • El Product Owner debe preparar el Producto Backlog antes de la reunión. En ausencia del Product Owner o del Product Backlog, el ScrumMaster debe construir un Product Backlog antes de la reunión y sustituir al Producto Owner.

  • El objetivo de la primera parte, o las primeras 4 horas, es que el Equipo seleccione aquellos elementos del Product Backlog que cree que puede comprometerse a transformar en un incremento de funcionalidad potencialmente entregable. El Equipo demostrará esta funcionalidad al Product Owner y a los stakeholders en el Sprint review meeting al final del Sprint.

  • El Equipo puede hacer sugerencias, pero la decisión de que elementos del Product Backlog pueden formar parte del Sprint es responsabilidad del Producto Owner.

  • El Equipo es responsable de determinar que parte del Product Backlog, seleccionado por el Product Owner para ese Sprint, va a tratar de implementar durante ese Sprint.

  • Limitar el tiempo para la primera parte a 4 horas significa que este es todo el tiempo disponible para analizar el Product Backlog. Un análisis más profundo debe ser realizado durante el Sprint. El Producto Backlog de alta granularidad y alto nivel puede no ser entendido con suficiente profundidad durante esta parte del Sprint planning meeting, lo que puede tener como consecuencia que el equipo no sea capaz de completar todos los elementos que seleccione del Product Backlog.

  • La segunda parte del Sprint Planning Meeting ocurre inmediatamente después de la segunda y también durará como máximo 4 horas.

  • El Producto Owner debe estar disponible para el Equipo durante la segunda parte para responder aquellas preguntas que el Equipo pueda tener acerca del Product Backlog.

  • Es labor del Equipo actuar solamente en su propio nombre y sin ninguna dirección externa al mismo, para encontrar durante esta segunda parte como transformar la parte seleccionada del Product Backlog en un incremento de funcionalidad potencialmente entregable. Nadie más tiene permiso para hacer nada que no sea observar o preguntar para buscar más información.

  • El resultado de la segunda parte del Sprint planning meeting es una lista, llamada Sprint Backlog, de tareas, estimaciones de tareas y asignaciones que dará comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista de tareas puede no ser completa, pero debe ser suficientemente completa para reflejar el compromiso mutuo por parte de todos los miembros del Equipo y guiarles durante la primera parte del Sprint, durante la cual el Equipo puede encontrar más tareas a añadir en el Sprint Backlog.

He decidido dejar en inglés algunos términos centrales de la metodología porque lo habitual es citarlos en inglés (o al menos en spanglish). Las partes directamente traducidas, aparecen en cursiva. Lo que busco con esta traducción es para que os animéis a comentar estas reglas: si creeís que son buena idea, si veis posible llevarlas a la relalidad, si ya usaís alguna parecida en vuestra metodología actual etc… Me gustaría que se generase un poco de debate sobre Scrum, en definitiva.

8 comentarios sobre “Las reglas de Scrum (I): El Sprint Planning Meeting”

  1. Hola Rodrigo,

    Hay van algunos pegas/problemas que le veo al uso de Scrum. Esto no quita que le veo cosas interesantes, pero voy a comentar algunas pegas que le veo.

    > Scrum supone un cambio bastante importante es la forma de trabajar; cambiar es muy difícil. Superar las reticencias al cambio son bastante complicadas y más cuando es un cambio importante. Ya sé que has escrito sobre este tema en post anteriores, pero
    aún así lo veo complicado.

    > Los proyectos más o menos terminan saliendo con más o menos dolor, pero ahí están. Por esto, pienso que la tendencia es más hacia cómo puedo “matizar” mi proceso actual, quitando lo que me sobra o añadiendo alguna buena práctica, para que la próxima vez lo haga bien, más que cambiar la metología e implantar otra diferente.

    Lo que se plantea es: ¿ Para que voy a cambiar si haciendo pequeños retoques puedo mejorar ?. Aprendo de cómo me han ido mis proyectos, saco lo bueno y mano de cada uno, y voy mejorando poco a poco.

    > Implicación del equipo. Para poder llevarlo a cabo debe haber un equipo comprometido, que adquiera unos compromisos y los cumpla. No sé hasta que punto esto siempre se puede conseguir. Del tema del compromiso no siempre se puede fiar uno. Hay gente para todo.

    Ibon.

  2. De acuerdo cambiar es dificil. Pero no queda otro remedio. Los clientes cambian, los lenguajes cambian, los requisitos cambian, los equipos cambian… lo único que no cambia es que siempre hay cambios. Puedes protegerte de ellos, lo que exige mucho esfuerzo, o acostumbrarte a ellos, y estar preparado para cuando ocurran. De todos modos estoy totalmente de acuerdo contigo en que el valor está en encontrar las técnicas que funcionan, no en seguir una metodología. Si bien es cierto, que hay metodologías, especialmente las ágiles, que se centrar en encontra y aplicar esas técnicas. Debajo de las reglas de Scrum o de las prácticas de XP solo hay un afán de difundir prácticas que funcionan (o pueden funcionar) en un amplio abanico de proyectos de desarrollo de software, no en otro tipo de proyectos; los proyectos de software son radicalmente diferentes a otros tipos de proyecto.

    Cierto es que los proyectos van saliendo. Pero la cuestión no es esa. La cuestión es cómo salen mis proyectos respecto a la competencia. Por qué si tus proyectos son más caros o queman más a sus miembros que los de la competencia, por mucho que ‘salgan’, a medio plazo te vas a encontrar en una situación en la que la competencia te compra, o no encuentras quien quiera trabajar en tu empresa (por solo citar dos factores). Otro factor es que los proyecto salen si, pero:
    ¿Cuántos equipos de desarrollo sobreviven al proyecto?
    ¿Cuántos proyectos salen en coste y tiempo?
    ¿Cuántos clientes satisfechos tenemos en la industria informática?
    Las respuestas a estas preguntas tienen que cambiar radicalmente. Y ahora empieza a haber empresas y jefes de proyecto que lo saben. (http://geeks.ms/blogs/rcorral/archive/2006/09/07/No-les-vamos-a-volver-a-enga_F100_ar.aspx)

    Sobre el fiarse o no del equipo, del cliente, de tu jefe, etc.: Creo que es una cuestión de enfoque. Si tu te enfocas en protegerte, nunca vas a crear una relación de confianza. Para crear un relación de confianza debes ser tu quien esté dispuesto a dar el primer paso. El compromiso se construye sobre la confianza. Eso si, no puedes juzgar a la gente por no complir sus compromisos y mucho menos por no cumplir los que establecio el comercial, o el jefe de proyecto en su nombre (http://geeks.ms/blogs/rcorral/archive/2006/11/16/Recibiendo-estimaciones.aspx). Lo único que puedes hacer, en mi opinión, es ver porque no se cumplieron, y actuar sobre la causas.

    Esta claro que Scrum es una metodología ágil, y por tanto o se asumen los planteamientos del manfiesto ágil o nos olvidamos de usarla.

  3. Yo no te digo que las empresas no se hacen las preguntas que tu comentas, sino que se las hacen pero la respuesta no es cambiar la forma de trabajar y usar la metodología X, sino que de forma natural intentan modificar su forma de trabajar actual con retoques de la misma.
    ¿ Qué igual la respuesta debería ser otra ? De acuerdo, pero hoy por hoy creo que es lo que más habitualmente sucederá.

    Comentas que hay jefes de proyecto que lo empiezan a saber, pero en organizaciones medianas-grandes aún así, lo veo difícil, salvo que encuestres un sponsor bien arribita que entienda que la manera actual de trabajar y que parchearla no es una solución. Cosa tb difícil.

Deja un comentario

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