Blog Post

El Sprint

Antonio Jesús Ruiz Córdoba • 2 de noviembre de 2018

El tiempo en Scrum

Para asegurar un feedback continuo, un proyecto Scrum se divide en muchos " subproyectos ". A esa división es a lo que se conoce como Sprint.
Un Sprint no es más que un periodo de tiempo, en el que un Scrum Team es capaz de entregar un incremento terminado de producto. La guía de Scrum limita dicho periodo de tiempo a un" time-box "de un mes máximo, pero con un matiz importante: Cada vez que la guía especifica un " time-box "en un evento, ese tiempo se puede reducir si se finaliza el objetivo a conseguir. Sin embargo el Sprint es el único que, una vez empezado no puede cambiar su duración.
Durante un Sprint, ocurren todos los eventos de Scrum: Se comienza con el Sprint Planning, se realizan los Daily Scrum y se acaba con el Sprint Review seguido del Sprint Retrospective. Una vez acaba un Sprint, se da comienzo al siguiente.

El objetivo del Sprint es asegurarse de que el trabajo no útil (por error, porque el resultado no es lo que espera el cliente, porque las prioridades han cambiado...) es el mínimo posible. Por ese motivo, la recomendación siempre es que la longitud del Sprint sea la menor posible, de forma que la cantidad de feedback recibido sea la mayor posible, y que en caso de tener que tirar trabajo, éste se reduzca al máximo. Es decir, disminuimos el riesgo y la complejidad .
¿Cuál debe ser la longitud de un Sprint? Pues depende del equipo y del proyecto. La longitud de un Sprint debería ser la menor posible en la que el equipo se sienta cómodo para realizar un incremento de producto al final del Sprint. Si el equipo no es capaz de realizar dicho incremento, la longitud es demasiado corta y el Sprint pierde su función. Si el Sprint es demasiado largo, la cantidad de feedback se reduce y potencialmente se podría tener que deshacer más trabajo del necesario.
No obstante, a la hora de elegir una duración para el Sprint, la recomendación es hacerla en semanas. ¿Significa esto que está prohibido hacer Sprints de 3 días? No. La duración del Sprint es libre, siempre que sea menor a un mes. Sin embargo, por logística para el equipo y sobre todo para los Stakeholders, es mejor hacerlo en semanas. Con ello conseguirás que todos tengan en su calendario algo como "cada dos lunes tengo una reunión con el equipo XXX para su Sprint Review". Si en lugar de eso tienes que una semana la reunión es el jueves, la siguiente es martes, la otra no hay... sólo conseguirás que el número de Stakeholders que asistan se reduzcan por problemas de agenda.

Otra recomendación es, que según avanza el proyecto y con el acuerdo del equipo e interesados, se juegue con la duración del Sprint.
Sé lo que estás pensando: " ¡Pero si los Sprints tienen todos la misma duración! ". Es cierto, los Sprints son de duración fija y no se cambian... una vez empezados . No vale incrementar el Sprint un par de días para que dé tiempo a terminar la última tarea. Si una tarea no se ha terminado, se verá en las reuniones dedicadas a la inspección (Review y Retrospective) qué ha pasado con ella, por qué no se ha terminado y qué acciones se pueden tomar a futuro para evitar que pase de nuevo. Si se amplía un Sprint una vez empezado, sólo consigues engañarte a ti mismo.
Explico la idea con un ejemplo: Llevamos 5-6 Sprints con una cadencia de 3 semanas y vemos que estamos entregando más trabajo de lo que podríamos considerar como "mínimo producto viable". Ahí podríamos ver con el equipo e interesados la opción de bajar la cadencia a 2 semanas, probar durante 2-3 Sprints y ver qué pasa. Para estos casos, tenemos siempre en cuenta los pilares de Scrum (transparencia, inspección y adaptación), así que básicamente probamos, si va bien lo mantenemos y si no funciona volvemos a como estábamos.

Durante un Sprint:

No se realizan cambios que puedan afectar al Sprint Goal (objetivo del Sprint).
Los objetivos de calidad no disminuyen
El alcance puede clarificarse y renegociarse entre el Product Owner y el Development Team según se aprende.

" Creo que lo entiendo. Mi objetivo del Sprint es hacer un formulario de color verde para una web y mi Sprint de un mes empezó hace 3 días. Me acabo de enterar que el cliente quiere cambiar los verdes por naranjas, pero como la duración del Sprint no se cambia una vez empezado y tampoco se admiten cambios que afecten al objetivo, pues dentro de 27 días, en el Sprint Review me dirán que en lugar de verde lo quieren naranja y ya "

Si se te ha pasado lo anterior por la cabeza, sigue leyendo: Scrum no va en contra del Agile Manifesto. Dos de los puntos del Agile Manifesto son "Respuesta ante el cambio" y "Colaboración con el cliente", y parece claro que la idea anterior no va por el mismo camino. El cliente no estará muy contento si le decimos que el plan era poner verde y hasta dentro de un mes no vamos a cambiar el plan.
Si sabemos que el objetivo del Sprint se ha vuelto obsoleto, Scrum permite realizar lo que se conoce como "Cancelación del Sprint".
La cancelación del Sprint la realiza el Product Owner (aunque pueden solicitárselo los Stakeholders, el Scrum Master o el Development Team) cuando el el objetivo del Sprint queda obsoleto. Esto puede pasar por un cambio de dirección de la compañía, de las condiciones del marcado o de la tecnología, entre otros. En general, cuando el Sprint deje de tener sentido dadas las circunstancias.
Cuando se cancela un Sprint, se realiza un Sprint Review para ver si los elementos terminados pueden ser entregables. Todos los no terminados pasarán al Product Backlog, donde el Product Owner los revisará. Si tienen sentido, se reestimarán y si no, desaparecerán del Product Backlog.
Dado que las cancelaciones de Sprint consumen recursos, suelen ser traumáticas para el Scrum Team y los Sprints son de corta duración, es algo muy infrecuente y rara vez tienen sentido. No obstante, y como otro punto más a favor de los Sprints cortos, mientras menor duración tenga éste, más improbable es que se produzca una cancelación.
Por último, una duda muy común que me hacen con la duración del siguiente Sprint tras una cancelación: ¿Duración normal o se disminuye el nuevo para que finalice cuando se esperaba que finalizara el cancelado? Pues como todo, depende. Lo ideal es que el nuevo Sprint tenga la cadencia normal que estaban teniendo los Sprintsanteriores, sin embargo, por motivos logísticos lo más habitual es que el nuevo Sprint sea de una duración menor a la habitual para que el Sprint Review del nuevo coincida con el ya estaba planeado para el que se canceló, siempre que el equipo sea capaz de terminar algo entregable para esa fecha. Cualquiera de las opciones es igualmente válida.

< Entrada más antigua

Entrada más reciente >

E-mail

Otras entradas del blog:

Scrum no funciona

Por Antonio Jesús Ruiz Córdoba • 11 de febrero de 2025

En mi experiencia, me he encontrado con muchos casos donde gente muy diversa reniega de Scrum afirmando, con excusas y ejemplos muy diversos que Scrum no funciona. Y esto lo hacen a todos los niveles, desde alta dirección, management, desarrolladores e incluso, algunos "Scrum Master". "Scrum está bien en la teoría, pero en la práctica no funciona", "es que nuestro caso es especial y Scrum no encaja en lo que hacemos", "Scrum tiene demasiadas reuniones que nos hacen perder el tiempo", "Scrum no sirve porque no se mira la calidad", "que sí, que en nuestra empresa hay un Scrum Master certificado y lo hemos probado en un proyecto tal cual viene en la guía y no hemos terminado en tiempo todos los requisitos que se nos pedían"... Casualmente, todos tienen algo en común: Interpretaciones o implementaciones incorrectas. Esto hace que el marco de trabajo Agile más común a nivel mundial, no sólo no dé ninguna ventaja, sino que acaba resultando contraproducente. ¿Quieres que veamos algunos de estos casos? Proyectos cerrados : Excusa : "Es que yo quiero xxxx para dentro de 30 meses y con un presupuesto cerrado de $$$ y con Scrum no puedo tenerlo" Explicación : Este punto parte de una base errónea que además es muy popular: "En Scrum está prohibido tener proyectos cerrados". No. En ningún sitio pone que esté prohibido tener proyectos cerrados y se puede trabajar perfectamente con Scrum un proyecto cerrado. ¿Pero, si la ventaja de Scrum es la adaptabilidad, para qué serviría en un caso como este? Pues justo para eso, para la adaptabilidad. La gran ventaja de Agile en general y Scrum en particular es que nos va a mostrar los problemas con muchísima antelación para que nosotros seamos capaces de adaptarnos, de forma que si vemos que no llegamos podemos aumentar el equipo (o reducirlo), adquirir nuevas herramientas que faciliten el desarrollo o cualquier punto que veamos que puede reconducir el problema. Si nos resultase imposible haciendo cambios de forma interna, tendremos que renegociar algo (alcance, coste y/o tiempo). Renegociar con mucha antelación da opción a que las condiciones puedan cambiar, mientras que si retrasamos dicha negociación hará que se complique o que las nuevas condiciones sean problemáticas para todas las partes. Si es imposible renegociar, posiblemente sea mejor cancelar un proyecto en el mes cinco que en el mes 29, que es lo que pasaría en caso de usar Waterfall (tendríamos muchos más gastos para llegar al mismo punto: No se puede hacer) Problema : Aquí el problema no es Scrum. Es el hecho de aceptar proyectos completamente cerrados en entornos complicados o complejos. Auto-engaño : "Es que mis clientes así lo exigen". MENTIRA (salvo que trabajes con la Administración Pública). ¿De verdad crees que RENFE exigió tener la mayor vergüenza de la ingeniería de software de la historia de España, en forma de una web donde los usuarios que querían hacer una compra sólo conseguían insatisfacción máxima? ¿No crees que si le hubieran dicho "Ey, renegociamos algo porque esto no tiene toda la calidad esperada" no hubieran preferido entregar con calidad un mes después o haber invertido un 5% más pero que los usuarios finales estuvieran contentos? Y si nos vamos al ejemplo inicial: ¿De verdad crees que, en un mundo como el actual donde cada poco tiempo sale algo totalmente novedoso, tu cliente quiere dentro de 30 meses algo que era útil hace 30 meses pero que en el momento de la entrega está obsoleto? ¿Y si durante ese tiempo sus necesidades han cambiado qué hacemos? ¿Le damos algo que ni quiere ni necesita sólo porque el proyecto era cerrado? ¿De verdad crees que ese cliente va a repetir con nosotros? Solución : Es tan sencillo como hablar con tus clientes y mostrarles, pero de verdad, que tu objetivo es su satisfacción y que para facilitar adaptarnos a sus necesidades y evitar casos "web de Renfe" debemos conocer qué podemos negociar en caso de ser necesario (aunque reflejemos qué, cuándo y con qué coste de forma inicial). ¿Quieres que veamos más ejemplos? Sigue atento a esta página donde actualizaremos con más detalles o únete a la Newsletter donde las próximas entregas irán dedicadas a desmitificar bulos sobre Scrum y Agile.

¡PMI y Agile Alliance se unen!

Por Antonio Jesús Ruiz Córdoba • 10 de enero de 2025

Hace unas semanas una chica me preguntó por la certificación de Agile Coach que ofrece el PMI (Project Management Institue). Mi respuesta no podía ser otra que, aunque el saber no ocupa lugar y mientras más te formes mejor, yo no me centraría en esa certificación y el motivo que le di era muy sencillo: Si a mí me pide una empresa que les ayude a contratar a un Agile Coach y hay varios candidatos que me demuestran similares conocimientos y experiencia, yo no sólo no valoro como algo positivo tener certificaciones del PMI, sino que incluso prefiero a alguien que no tenga ninguna al que sólo tenga de esta institución. ¿Por qué? La mayor empresa en el mundo en las certificaciones de Project Management lleva desde 1969 defendiendo un punto de vista predictivo y una forma de trabajo en cascada que no encaja con la filosofía Agile. No está mal en entornos muy simples, pero en cuanto el entorno se complica un poco esta forma de trabajo en cascada ha demostrado una y otra vez su ineficacia, de ahí que naciera hace más de 20 años Agile y su manifesto, para hacer las cosas de una forma distinta. Cuando vieron que perdían el monopolio de las certificaciones en gestión de proyectos por una forma más óptima de trabajar se unieron al carro haciendo su propia certificación en Agile, defendiendo que Agile era perfectamente encajable en la gestión de proyectos tradicionales haciendo algo así como la imagen de este post (imagen de monolit-it.pl/2018/02/Water-Scrum-Fall ). Es decir, que cogen una gestión de proyectos en cascada y, dentro de la fase de desarrollo, es donde se hace un trabajo en iteraciones como si trabajar así ya te hiciera Agile. Algo similar (con otra imagen) es algo que publicó por X (twitter) la cuenta @PMIMadridSpain (si lo quieres, tengo el enlace aunque acabaron borrando el contenido por la burrada tan gorda que defendían, prometo que era mucho peor que lo de la imagen). Aunque podría llegar a entender que trabajes así si es tu primer día en una transformación Agile (y no estás siguiendo mis consejos), debes saber que haciendo esa mezcla, vas a tener las desventajas de los dos mundos (cascada y Agile) y sin ninguna ventaja reseñable ni a corto ni a largo plazo. Así que es muy difícil tomarse en serio a quien claramente demuestra su incompetencia (por desconocimiento, por mantener el status quo...) y nos enseña como caso ideal lo que claramente es una crónica de una muerte anunciada y motivo por el que Agile nunca funcionará en tu organización. Y de repente, para empezar el año, noticia bomba: El Project Management Institute y la Agile Alliance han anunciado el día 3 que se asocian: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ Esta noticia ha dejado perplejo a todo el mundo dentro de la Agilidad. ¿Cómo es posible que dos formas tan antagónicas de entender la gestión de proyectos se unan? De una parte una organización sin ánimo de lucro que busca promover y compartir la filosofía Agile y por otra una gran empresa que busca mantener su hegemonía como único referente en la gestión de proyectos. Pues para entenderlo basta con leer la letra pequeña: "As part of this process, Teresa Foster, Managing Director of Agile Alliance, and her team will transfer to PMI" Esto es como cuando una gran empresa energética recibe una ayuda del gobierno que nadie entiende y que perjudica al resto de ciudadanos, y luego vemos que los ministros que la aprobaron, casualmente pasan a la empresa como asesores... pues algo parecido. Por un lado, la Agile Alliance será subvencionada por la mayor empresa en el mundo de certificaciones de Project Management, y el PMI, que ya vendía certificaciones Agile, ahora dirá que su contenido es bueno porque viene avalado por la Agile Alliance por lo que venderá más; y todo ello mezclado con esas "puertas giratorias" donde los que aprueban la colaboración se llevarán "su comisión". Así que, al final, es el dinero el que nos ha llevado a esto. ¿Mi opinión? Yo me mantengo receloso de esta colaboración. El cambio que tendría que dar el PMI para moverse en la mentalidad Agile tendría que ser tan grande que, casi casi habría que refundarlo. También creo que sus certificaciones de Project Manager van a seguir defendiendo esa forma de trabajo predictivo que funciona, sí, pero sólo en entornos muy simples. Hoy en día, hay muchas empresas certificadoras sobre Agile en general (y Scrum en particular) que, con mayor o menor prestigio hacen una defensa de esta forma de trabajar mucho más óptima (y coherente), por lo que yo no me iría a obtener una validación profesional justo a las antípodas de esta forma de trabajar. Si quieres validar tu carrera como Project Manager tradicional, ve al PMI. Si lo que quieres es validar tu evolución en Agile (y Scrum), que es lo que ahora más demanda el mercado, mi primera opción sería el PSM I de scrum.org (que puedes conseguir con mis cursos de Scrum ), siendo igual de válidas para la mayoría de las ofertas de trabajo hacerlo con EuropeanScrum o CertJoin (ambas también se pueden conseguir con mis formaciones ) o incluso Scrum Manager, Scrum Alliance y otras certificadoras. ¿Quién sabe? Igual, como he visto bromear en algún foro sobre este tema, dentro de poco nos encontramos con que el PMI ha abierto la certificación de "Agile Project Manager" o alguna aberración similar. Habrá que estar atento. ¿Y tú qué opinas sobre esto?