Scrum, la guía definitiva
ESTA GUÍA FUNDAMENTAL ES UNA INTRODUCCIÓN AL SCRUM FRAMEWORK: SUS ROLES; ARTEFACTOS Y EVENTOS JUNTOS A TRAVÉS DE UN CASO PRÁCTICO, ELABORADO POR JERÓNIMO PALACIOS, PROFESSIONAL SCRUM TRAINER DE SCRUM.ORG
Scrum.
Una breve introducción
Scrum es el método ágil de desarrollo de Software más utilizado del mundo. Se presentó en 1995 y hoy en día, más del 70% de los equipos de desarrollo de Software en el mundo lo usan.
Scrum es simple pero no es fácil. Las compañías que consiguen implementarlo, consiguen mejoras de 4 a 10 veces en productividad, time-to-market y competitividad.
Sólo es posible mediante la mejora de la transparencia, la reducción de los ciclos de desarrollo y la mejora de la innovación, según el reporte CHAOS de Standish Group.
Scrum ha evolucionado significativamente para adaptarse a nuevos retos e ideas durante los últimos 20 años. A pesar de todo, muy pocas compañías consiguen vencer sus propias resistencias para conseguir todos los beneficios de Scrum.
El movimiento ágil surge de la publicación del Agile Manifesto por líderes de la industria en el 2001. La realidad del mercado entonces era lamentable.
Los proyectos de desarrollo de Software se planificaban durante años antes de escribir una sola línea de código, llevando a catástrofes como la del proyecto Sentinel del FBI, en el que después de invertir más de 60 millones de dólares, hubo que rehacer todo el Software de nuevo.
Hay miles de casos de fracaso de iniciativas de desarrollo que han terminado en desastre. Por ejemplo, en Andalucía (España) el gobierno regional invirtió unos 45 millones de euros en el desarrollo del Software para gestión del sistema sanitario Diraya, sólo para tener que rehacerlo antes de que estuviera verdaderamente en funcionamiento.
El Manifiesto ágil.
En Febrero del año 2001, 17 críticos con el modelo de gestión tradicional de proyectos se reunieron para crear un manifiesto que corrigiera esta situación, impulsados por el creador de eXtreme Programming, Kent Beck.
Entre las personas que se encontraban alli, se encontraban diferentes voces que pretendían cambiar la forma en que se realizaban los proyectos y productos de software.
Esta forma de trabajar habitualmente llevaba a grandes fracasos con un coste de millones de dólares.
De esta reunión surgieron cuatro valores y doce principios que rigen el desarrollo ágil de Software.
Valores del manifiesto ágil
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Principios del manifiesto ágil
Seguimos estos principios:
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software
con valor. - Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
- Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. - La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Los orígenes de Scrum
En 1995, Jeff Sutherland y Ken Schwaber habían presentado Scrum en una conferencia de desarrollo de Software. Utilizando un paper publicado en 1986, llamado «The new new Product Development Game», en el que se analizaban las formas de trabajo de equipos de éxito, destilaron sus reglas para ponerlas al servicio del mundo.
Así nació el que hoy en día se considera el estándar para la gestión de iniciativas complejas de desarrollo de producto.
Los profesionales que lo utilizaban no dispusieron de una guía oficial hasta bien entrado el nuevo milenio.
Cuando en 2011, Ken Schwaber y Jeff Sutherland decidieron publicar la guía oficial de Scrum, lo hicieron atendiendo a un problema cada vez mayor: Cada profesional veía Scrum de una manera distinta y, lo que en su momento eran una serie de reglas, se convirtió en algo que quedaba a la más pura interpretación del profesional que lo implantaba.
Ha evolucionado con el tiempo para recoger la forma en que se utiliza en la práctica. Desde 2011 ha habido dos grandes cambios en la guía de Scrum, en 2013 y 2016.
Primero, se eliminaron algunas cosas, como los diagramas de burndown. Se reforzó el énfasis en el Daily Scrum como elemento de planificación -y no solamente sincronización- y también se cambió el nombre de la reunión de grooming a refinenement. Todos estos conceptos los veremos más adelante.
En 2016 se añadieron los valores de Scrum, aquellos que hacen que el marco funcione en una organización, además de algunos cambios menores.
Una de las cuestiones importantes que trajo la guía de Scrum es que dejó de llamarse SCRUM. Hace muchos años, cuando se publicó el paper original sobre Scrum, se eligió en mayúsculas para darle más énfasis. Sin embargo, parece que muchos profesionales siguen tratándolo como un acrónimo.
Para entender los orígenes de Scrum, merece la pena leer el paper The New New Product Development Game, en el que se describen las reglas que dieron lugar al que hoy es el framework de desarrollo de Software ágil más usado en el mundo.
Uno de los énfasis que hacemos en Scrum.org es en el uso del lenguaje en lo que a Scrum se refiere. El Sprint Review es una reunión de negocio, no una demo. El Sprint Planning es para el equipo Scrum, no para los Stakeholders. Estas cosas marcan la diferencia en el entendimiento sobre las responsabilidades que cada una de las personas que están afectadas por Scrum, tienen. Mejoran la comunicación y reducen la fricción.
Scrum es un nombre propio, y por eso se escribe capitalizado, tanto en Castellano como en Inglés.
La guía oficial de Scrum
La guía de Scrum es el documento que explica en detalle cuales son las mecánicas, sus eventos (Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective), roles (Scrum Master, Product Owner y Development Team) y artefactos (Product Backlog, Sprint Backlog e Incremento). La guía se puede descargar aquí en Castellano. En las próximas secciones desgranaremos cuales son los detalles de cuales son cada una de las mecánicas que subyacen a Scrum.
La guía de Scrum ha tenido su última actualización en 2017, matizando el uso de Scrum fuera del software, el papel del Scrum Master o el objetivo del Daily Scrum. Esta actualización, después de las de 2016 incluyendo los valores, 2011 y 2013, indican la excelente relación de los creadores de Scrum y su compromiso hacia este marco de trabajo.
Por sí mismo, el framework no aporta mucho. Ese es el caso de las implantaciones amateur de las que hablaba anteriormente. El objetivo debe ser la agilidad, y el framework no es solo el camino para conseguirlo. A pesar de su comparación con proyectos industriales, Scrum no es sino un reflejo del empirismo y un marco de trabajo listo para funcionar en entornos complejos.
Scrum: Un caso práctico
Optiopay es una startup con sede en Berlín. Su producto es una plataforma de pagos entre particulares y empresas, que permite a los usuarios decidir si quieren recibir un pago con dinero en efectivo o quieren obtener vales regalo por un importe superior.
Optiopay tiene un equipo de 9 desarrolladores con diferentes perfiles que se encargan de diferentes partes del producto.
Todos los requerimientos del producto están recogidos y expresados en una lista, el Product Backlog. Esta lista contiene todo el trabajo que hay que hacer al producto y que lleva muchos meses. El Product Owner, que representa al negocio, se encarga de mantener la lista actualizada y en lo alto coloca las prioridades más urgentes. Este rol es el único que decide sobre las prioridades y es responsable de decidir hacia donde debe ir el producto.
El equipo de Optiopay hace una entrega de producto cada cuatro semanas. Al principio de la primera semana, el Development Team se reúne con el Product Owner en una reunión de planificación (Sprint Planning), donde éste le explica al equipo que su máxima prioridad es entregar la parte de la plataforma que se encarga del procesamiento de pagos. Esta es la meta para la iteración.
Primero el equipo de desarrollo (Development Team) mira nuestra lista de requerimientos, que está actualizada y ordenada por prioridades y decide que porción creen que pueden completar en un cuatro semanas atendiendo a la meta para esa iteración. En la segunda parte, una vez decidido el trabajo a realizar, el Development Team se encarga de analizar y desmenuzar en tareas cada uno de los requerimientos que han escogido, lo suficiente para empezar a trabajar.
Todas estas tareas, junto con los requerimientos escogidos completan una lista en la que el equipo de desarrollo trabaja y será el plan de cuatro semanas que el equipo se encargará de mantener actualizado durante todo el Sprint.
Durante cada uno de los días de trabajo, el equipo de desarrollo se reúne todas las mañanas durante 15 minutos para analizar la lista de tareas y actualizar el trabajo que van completando y queda pendiente; los miembros del equipo informan a otros miembros de impedimentos y problemas. Juntos deciden como pueden resolverlos.
Una vez que el equipo va terminando el trabajo sobre los requerimientos, los va mostrando al Product Owner para que les de el visto bueno, y así poder continuar en el orden en que estaban inicialmente. La persona que ejerce este rol, trabaja con el equipo para informarles de la situación con respecto al producto. Todos los requerimientos terminados junto con la parte de producto hecha anteriormente se llama Incremento. El objetivo de la iteración es entregar un Incremento terminado que cumpla con la meta marcada.
Al final del Sprint, el Product Owner organiza una reunión llamada Sprint Review, donde invita a Stakeholders y al equipo de desarrollo para mostrar el Incremento terminado; los stakeholders dan feedback al Product Owner sobre el Incremento y preguntan cualquier duda que tengan al equipo de desarrollo. Después ponen en común cual es la situación de negocio actual. Al final, se actualiza el Product Backlog con nueva información que pudiera haber surgido.
Después del Sprint Review, el Scrum Master que es la persona encargada de gestionar todo el proceso Scrum, organiza una Retrospectiva para todo el equipo Scrum -Product Owner + Equipo de Desarrollo + Scrum Master-, donde analizan la forma de trabajar, posibles problemas en el equipo, areas de mejora y temas técnicos.
La retrospectiva marca el final del Sprint e inmediatamente otro Sprint comienza, siguiendo el mismo proceso descrito arriba.
Roles en Scrum
Scrum master
El Scrum Master se encarga de gestionar y asegurar el proceso Scrum, que éste se lleva a cabo correctamente y de facilitar la ejecución del proceso y sus mecánicas, siempre atendiendo a los tres pilares del control empírico de procesos. Además, se encarga de eliminar impedimentos que puedan afectar a la entrega de producto. También se encarga de hacer coaching al resto del equipo Scrum cuando lo necesitan, además de facilitar reuniones y eventos si es necesario. El Scrum Master puede ser compartido entre varios equipos, aunque su disponibilidad afectara al resultado final del proceso Scrum.
El Scrum Master tiene dos funciones dentro del marco de trabajo. La primera es gestionar el proceso Scrum y la segunda es ayudar a eliminar impedimentos. Vamos a echarles un vistazo en profundidad:
Gestionar el Proceso Scrum
El Scrum Master es el encargado de mantener Scrum al dia, de proporcinar coaching, mentoring y formacion a la organizacion en caso de que lo necesita y de verlar porque Scrum favorezca la entrega de valor en lugar de ser una herramienta de microgestion.
Ayudar a eliminar impedimentos
Esta funcion del Scrum Master indica la necesidad de ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo en la organizacion y que afectan tanto a la integridad de Scrum como impiden a la organizacion entregar valor.
Hay que remarcar que estos impedimentos no son del equipo, sino de la organizacion, y donde el Scrum Master aporta es a nivel organizativo, no reparando teclados para los miembros del Development Team. En ocasiones me encuentro Scrum Masters que se quejan de la imposibilidad de hacer Scrum debido a que la organizacion no facilita su introduccion adecuada a lo largo y ancho de la misma. Es precisamente al contrario, es el Scrum Master el responsable de velar porque Scrum se lleve adelante y se pueda facilitar la implementacion.
Los Scrum Masters y el tiempo libre
Un Scrum Master tiene mucho tiempo libre y esta fuera de la voragine del dia a dia, precisamente para que es le permita enfocarse en problemas de mayor calado que afectan a la organizacion a nivel global, en lugar de encargarse de actualizar el Scrum Board para el equipo de desarrollo, o hacer el trabajo del Product Owner. EL trabajo de eliminar impedimentos en una organizacion por parte del Scrum Master va desde influenciar a la capa ejecutiva o senior a favorecer el cambio de procesos internos para facilitar la agilidad organizacional.
Product Owner
La labor del Product Owner es optimizar el valor del producto dentro de los roles Scrum. El Product Owner gestiona el todo el flujo de valor del producto, a través del Product Backlog, así como todo lo relacionado con informes, presupuestos y relación con las partes interesadas en el producto (Stakeholders). En Scrum existe solamente un Product Owner por cada producto, así cómo un sólo Product Backlog.
El Product Owner es reponsable de maximizar el valor del producto o proyecto que este llevando a cabo. Esto, que se expresa facilmente, es una tarea complicada, tal y como veremos a continuacion.
Gestiona prioridades
El Product Owner se han entendido tradicionalmente como un gestor de requisitos, o un cliente que se encarga de gestionar el Product Backlog, pero es mucho mas que eso. El Product Owner tiene la responsabilidad de gestionar los presupuestos, de contratar al equipo de desarrollo y de explicar a los stakeholders cual es el valor que produce el producto en el que esta invirtiendo. Al fin y al cabo, cada Sprint que pasa, el Product Owner hace una inversion en desarrollo que tiene que producir valor.
Representan al negocio
Cuando el Product Owner es alguien de negocio, aportara valor a su trabajo al producto dependendiendo de al menos dos variables. La primera es la capacidad de decision que tiene. En ocasiones, es normal que el Product Owner no pueda realmente tomar decisiones sin consultar con otra persona. En ese caso, no es un Product Owner real y debe, o de ser sustituido por la persona que toma las decisiones, o ser investido para tomarlas el mismo. Hay que recordar que esto no es un capricho de los fanaticos de Scrum, sino una manera de maximizar la inversion realizada en el desarrollo de producto y reducir los riesgos inherentes.
Son Intraemprendedores
Es en esta faceta donde realmente el Product Owner puede aportar valor al negocio. Un Product Owner en esta faceta es un Product Manager agil, capaz de medir el valor generado y utilizar la flexibilidad de entregar cada Sprint para incrementar ese valor.
Development Team
El Equipo de desarrollo está formado por 3 a 9 profesionales que se encargan de desarrollar el producto, se autoorganizan y deciden cual es la mejor manera de conseguir entregar un incremento de software al final del ciclo de desarrollo. Nótese que en Scrum no importa el número de individuos sino el rol, y este solo hay uno, independientemente de cuantos miembros tenga el equipo de desarrollo y cuales sean sus roles internos. Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tiene que rendir cuentas por ello; hay que evitar intervenir en sus dinámicas.
El equipo de desarrollo se encarga de crear un incremento terminado a partir de los Product Backlog items seleccionados durante el Sprint Planning. El Equipo de desarrollo tiene un tamano recomendado de 3 a 9 personas, que rinden cuentas como uno solo.
Habitualmente, tambien es un equipo cross-funcional, capaz de generar un incremento terminado de principio a fin, sin otras dependencias externas. El aspecto mas importante del equipo de desarrollo es que se auto-organiza y se auto-gestiona.
El equipo de desarrollo es responsable de contratar al Scrum Master.
Artefactos en Scrum
Product Backlog
El Product Backlog es un inventario. Contiene cualquier tipo de trabajo que haya que hacer en el producto. Requerimientos, casos de uso, tareas, dependencias. Todas ellas están representadas en el Product Backlog y este es la fuente principal de información sobre el producto en Scrum.
El Product Backlog es una lista en cualquier formato que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con los distintos Stakeholders de la organización, y refleja el estado real del trabajo pendiente de implementar en un producto
El Product Backlog está gestionado por el Product Owner. Puede contener cualquier tipo de tarea en cualquier formato y su única condición es que esté priorizado con aquellos items que tienen más valor en ese momento.
Al comenzar a utilizar Scrum, no es necesario una lista completa y exhaustiva de todos los requerimientos. Es posible (¡Y recomendable!) empezar con los dos o tres requerimientos más urgentes arriba e ir añadiendo conforme vamos descubriendo más necesidades de nuestro producto.
Típicamente un Product Backlog contiene diversos tipos de elementos:
- Funcionalidades
- Bugs
- Historias de usuario
- Tareas técnicas
- Trabajo de investigación o Spikes
Historias de usuario
Las historias de usuario son una forma de expresar elementos de un Product Backlog, pero no la única. Un error común en organizaciones sin experiencia es tratar de expresar todos los elementos de un Product Backlog como historias de usuario.
El formato de una historia de usuario es:
As a… (Cómo tal o cual perfil)
I want to… (Especifica qué se quiere conseguir)
So I can… (Explica el por qué se quiere conseguir eso)
Para obtener el máximo valor de una historia de usuario, es necesario expresarlas desde el punto de vista del usuario. Intentar expresar una tarea técnica como una historia de usuario puede llevarnos a relaciones absurdas del tipo: Como desarrollador, quiero descargar el entorno de desarrollo para poder desarrollar.
Como se puede comprobar, el valor que se obtiene es mínimo. Otro punto a tener en cuenta en las historias de usuario es que tienen tres elementos importantes: La Tarjeta donde se expresa la historia de usuario, una Conversación acerca de que va la historia de usuario y la Confirmación de que todo el mundo ha entendido el valor.
Un ejemplo de Product Backlog
Este podría ser un ejemplo de Product Backlog para diferentes aplicaciones o industrias:
Red social
- Como posible cliente, quiero poder suscribirme en la landing page para saber cuando va a ser el lanzamiento del producto
- Como usuario, quiero poder escribir mis pensamientos para que queden guardados
- Como usuario, quiero poder leer lo que escriben mis amigos
- Como empresa, quiero poder segmentar usuarios para saber cuanto invertir en publicidad.
Banco
- Como cliente particular, quiero poder consultar mi saldo para saber cual es la posición de mis cuentas
- Como empresa, quiero recibir una notificación de cuando mis empleados usan la tarjeta para poder controlar mis gastos
- Como cliente, quiero poder descargar la aplicación móvil para estar al tanto de mis cuentas en cualquier lugar
- Como cliente particular, quiero saber cuanto puedo dinero puedo obtener en la aplicación móvil para evitar ir a una oficina
na vez que se hace el Sprint Backlog, todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo del Sprint y está gestionado por el Development Team. Su propósito es mantener la transparencia dentro del desarrollo
El Sprint Backlog nos proporciona una visión del trabajo a realizar durante el Sprint actual. Está gestionado por el equipo de desarrollo, que se encarga de mantenerlo actualizado y transparente durante toda la iteración, especialmente a través de los daily Scrums
Después del Sprint Planning, el equipo de desarrollo obtiene una lista de elementos en los que van a trabajar durante un Sprint. Estos elementos normalmente se deshacen en tareas técnicas más pequeñas. Facilitan la implementación de los mismos en un Incremento de software terminado.
El Sprint Backlog permite visualizar todo el trabajo pendiente durante un Sprint. Así, se pueden ver aquellos elementos que aún no han empezado a desarrollarse, aquellos que si y quienes están trabajando en los mismos y aquellos que están esperando a desplegarse o están completamente terminados.
Este artefacto permite entender cual es la evolución del trabajo durante el Sprint así como hacer una análisis de riesgos. Dado que cada Sprint tiene una meta específica (p.e. permitir que los usuarios se registren en la app móvil) y hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. Así maximizamos el retorno de la inversión en desarrollo.
Visualización del Sprint Backlog
Hay diferentes maneras de visualizar el Sprint Backlog. Desde el uso de herramientas electrónicas hasta una hoja de cálculo. Dado que el objetivo del Sprint Backlog es favorecer la adaptación y transparencia, el uso de una pizarra con columnas es uno de los más adecuados, al menos hasta que el equipo de desarrollo es suficientemente maduro como para poder lanzarse al uso de otra herramienta.
Incremento
Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado cada Sprint. El Incremento es la suma de todas las tareas, casos de uso, user stories y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software al final del mismo
Un incremento es el resultado del Sprint. Es una pieza de Software, acorde con los elementos seleccionados durante el Sprint Planning del Sprint Backlog que aporta un valor de negocio al producto que se está desarrollando
Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del software: Planificación, diseño, desarrollo, testeo y entrega ocurre en 30 días o menos. Por supuesto, no podemos construir toda la funcionalidad que queremos en sólo 30 días y tenemos que buscar la manera de ir entregando los componentes necesarios justo a tiempo.
La imagen superior refleja esa manera de pensar. A través de un desarrollo incremental, primero nos centramos en las características o features principales y luego vamos añadiendo más, refactorizando y permitiendo tanto una arquitectura como un diseño emergentes.
Las ventajas del desarrollo incremental
El desarrollo incremental es uno de los pilares principales de cualquier iniciativa ágil, y tiene una ventaja principal. Nos permite una adaptación rápida a las condiciones cambiantes del mercado y del producto. Si descubrimos que lo que diseñamos no es lo que nuestro cliente busca en la segunda o tercera iteración, habremos reducido nuestro riesgo y aumentado nuestro retorno de la inversión.
Un desarrollo de este tipo choca con la mentalidad tradicional de desarrollo en fases, y es probablemente el hito que marca el cambio de una empresa de un modelo tradicional a un modelo ágil. No importan los roles, reuniones o artefactos en marcha puesto que, sin un incremento de Software terminado al final de cada Sprint no hay posibilidad de ser ágil.
Eventos en Scrum
Sprint
El sprint es un contenedor para el resto de los eventos de Scrum. El Sprint es continuo, es decir, su duración no cambia y se puede interpretar como una medida de ritmo que no cambia a lo largo del tiempo y nos permite reducir complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint sirve a la transparencia Y permite inspeccionar y adaptar todos los otros eventos de Scrum.
Scrum prescribe que un Sprint debe durar 30 días o menos. La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo puede generar valor a través de un Incremento terminadoEl Sprint es una iteración definida (time boxed) que sirve al desarrollo iterativo e incremental. Todo el desarrollo se realiza durante el mismo Sprint y este contiene al resto de los eventos en Scrum, teniendo una duración de 1 mes o menos. La duración del Sprint se determina por un horizonte de planning aceptable. No hay fases en Scrum, sólo Sprints. No existen los Sprints de testing, hardening, release o análisis.
El Sprint es un evento que contiene a todos los demás eventos en Scrum, y su cometido principal es facilitar la transparencia del proceso Scrum. Un Sprint debe de durar 30 días o menos, y es bastante habitual que los equipos Scrum elijan tener Sprints de una duración de dos semanas. Sin embargo, cada caso es diferente, y es el equipo Scrum el que debe descubrir cual es su periodo mínimo necesario para generar valor a través de un Incremento terminado.
El Sprint también se puede definir como un metaevento que contiene todos los demás eventos. Un Sprint normal tendría:
- El sprint Planning al comienzo del Sprint
- Daily Scrums para actualizar el Sprint Backlog e identificar impedimentos
- Un Sprint Review al final del Sprint para inspeccionar el Incremento
- Justo después, la retrospectiva para hacer transparentes e inspeccionar posibles problemas en la forma de trabajar o de hacer Scrum.
Todo ocurre en un sólo Sprint
La mentalidad de un proyecto por Sprint es uno de los cambios más difíciles de asumir en la mentalidad de organizaciones que están haciendo una transición ágilScrum es una herramienta excelente para la gestión de proyectos. A diferencia de la gestión tradicional de proyectos, donde un proyecto puede durar meses o años, en Scrum un proyecto dura un sólo Sprint. Todas las tareas necesarias para llevar el proyecto a cabo se realizan durante el mismo Sprint. Así, el diseño, la planificación o el testing son actividades que se realizan dentro de un sólo Sprint, siempre orientado a generar el máximo valor. En Scrum, los proyectos se financian cada Sprint y es el Product Owner quien decide donde y a qué dedicar los recursos. Entender esto es crítico para asegurarse el éxito en la utilización de Scrum en una organización
Monitorizando el progreso del Sprint
“A Scrum project is only one Sprint long. A release of software is the sum of multiple increments (and previously developed software, if any). A Scrum project cannot fail, only deliver unacceptable return on investment.”Ken SchwaberEl monitoreo del progreso del Sprint es una práctica bastante utilizada en equipos Scrum. Es una práctica del equipo de desarrollo que les permite ser transparentes acerca de la situación del trabajo reflejado en el Sprint Backlog y decidir si es necesario adaptar. En el caso de que así fuera, es el Development Team el responsable de hablar con el Product Owner para que sea él o ella quien decida cual es el trabajo de más valor del Sprint.
Una de las técnicas frecuentemente utilizadas es la del Sprint Burndown. En un diagrama se fijan los días del Sprint en el eje de abcisas, mientras que en el eje de ordenadas se refleja la suma del trabajo por hacer. Se hace un seguimiento diario del trabajo pendiente y el burndown va reflejando el trabajo restante a lo largo del tiempo.
Claves
- La duración del Sprint se mantiene fija.
- No hay espacios entre Sprints, cuando acaba uno, empieza el siguiente.
- Permite mantener el ritmo.
- Sirve a la transparencia
Sprint Planning
El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el producto backlog y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente sprint. Durante esta reunión el Product Owner presenta el Product Backlog actualizado, que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crean necesarios.
En el Sprint Planning participa el equipo Scrum al completo, pero no Stakeholders. En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of Done y se adaptan el Sprint Backlog, el Forecast y el Sprint GoalEl Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata el ¿Qué? se va a hacer el siguiente Sprint y en la segunda parte, se discute el ¿Cómo?. La primera parte está organizada y liderada por el Product Owner y la segunda parte por el Development Team. La única labor del Scrum Master es asegurarse de que la reunión existe como parte de Scrum.
El Sprint Planning es una reunión de planificación y puede durar hasta 8 horas para Sprints de 30 días. La razón del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en cuanto a cuales son las prioridades.
Flujo del Sprint Planning
El Product Owner presenta un Product Backlog priorizado y actualizado, además de proponer un Sprint Goal que de coherencia a todos los ítems seleccionados durante la reunión. Durante la primera parte, el Equipo de Desarrollo pronostica cuantos elementos del Product Backlog cree que será capaz de terminar en el Sprint, teniendo en mente el Sprint Goal propuesto por el Product Owner. Una vez que existe un acuerdo entre el Product Owner y el Equipo de Desarrollo, entonces el equipo de desarrollo pasa a la segunda parte, donde se encargan de desmenuzar el trabajo que hayan seleccionado en tareas más pequeñas, siempre cumpliendo la regla de analizar solamente el mínimo para empezar a trabajar.
- El Sprint Planning se compone de dos partes: Una donde se pronostica el trabajo a realizar y otra donde el Development Team se encarga de analizar y desmenuzar el trabajo en tareas, hasta donde crean necesario.
- La primer parte del Sprint Planning está liderada por el Product Owner y la segunda parte por el Development Team.
- Es responsabilidad del Scrum Master que el meeting ocurra, pero no tiene que facilitarlo ni organizarlo él mismo.
- El Development Team tiene la última palabra sobre cuanto trabajo creen que pueden completar en un sólo Sprint.
¿Que necesitamos?
- Definition of Done
- Acuerdos de la retrospectiva
- Product Backlog
- Disponibilidad del Development Team
¿Que obtenemos?
- Product Backlog actualizado
- Sprint Backlog
- Sprint Goal
Duración
8 horas para Sprints de 30 días. Menos para Sprints más cortos.
Quien es el responsable
Primera parte: Product Owner
Segunda parte: Development Team
Daily Scrum
El Daily Scrum es una reunión diaria de planificación de 15 minutos en la que participa el Development Team. Durante el Daily Scrum, se inspecciona el Sprint Backlog y se adaptan las tareas. Se hacen transparentes los impedimentos y el progreso hacia el Sprint Goal.
El Daily Scrum es una reunión de inspección y adaptación en Scrum de una duración de unos 15 minutos. Durante esta reunión, el equipo de desarrollo se reúne y analizan cuales son los elementos en los que están trabajando y que impedimentos encuentran. También comunican si existe riesgo de no alcanzar la meta marcada durante el Sprint -el Sprint goal-.
En Scrum existen varios feedback loops, pequeñas interacciones que nos dan la oportunidad de inspeccionar y adaptar nuestro trabajo. Eso nos permite planificar riesgos y tener transparencia y visibilidad sobre el proceso. El Daily Scrum es de frecuencia diaria y es exclusivo para el equipo de desarrollo. Durante el mismo, el equipo discute cual es la situación del incremento y como mitigar los riesgos asociados al mismo.
Mucha gente confunde el Daily Scrum con el Standup Meeting, pero no son lo mismo. El Standup Meeting es una práctica de eXtreme Programming (XP) orientada a controlar y gestionar el trabajo motivada por un manager, mientras que el Daily Scrum es una práctica que permite la inspección y adaptación a través de la auto-organización del equipo.
Facilitación de un Daily Scrum
Uno de los métodos de facilitación más conocidos, es el de las tres preguntas:
¿Que hice ayer para contribuir al Sprint Goal?
¿Que voy a hacer hoy para contribuir al Sprint Goal?
¿Tengo algún impedimento que me impida entregar?
Este método, aunque cómodo y claro para equipos que acaban de empezar con Scrum, se tienda a modificar con el tiempo una vez que los equipos maduran y son capaces de hacer un análisis de riesgo y adaptarse a demanda.
Otra de las temáticas durante el Daily Scrum es decidir quien va a trabajar con quien, por ejemplo a través de técnicas como el Pair Programming.
Sprint Review
El Sprint Review es una reunión que ocurre al final del Sprint, donde el Product Owner presenta a los Stakeholders el Incremento terminado para su inspección y adaptación. Esta reunión, organizada por el Product Owner, es el momento de medir cual es la situación y actualizar el Product Backlog con nuevas condiciones que puedan afectar al negocio.
El Sprint Review marca la finalización de un Sprint. El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software que ahora mostrará a los Stakeholders. Para ello, el Product Owner se encarga de convocar una reunión donde se revisaran varias cosas.
No se trata de una demostración, sino de una
reunión de trabajo. El software ya ha sido mostrado y validado junto con
el Product Owner
Por un lado, se revisará el incremento terminado. Se mostrará el software funcionando en producción y los stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El Software funcionando ha sido validado previamente por el Product Owner, que se ha encargado de trabajar con el equipo durante el Sprint para asegurarse que cumple con la Definition of Done y efectivamente hace que el Sprint Goal sea válido.
Posteriormente, el equipo de desarrollo comenta qué ha ocurrido durante el Sprint. Problemas que se han encontrado, así como soluciones tomadas, y actualizan a los stakeholders con la situación del equipo. Por último el Product Owner y los stakeholders actualizan, con las condiciones de negocio, el Product Backlog para el siguiente Sprint.
A pesar de lo que muchos creen, el Sprint Review no se trata de una demo para un cliente o para los stakeholders, o incluso para el Product Owner. No es tampoco una reunión para felicitar al Equipo de Desarrollo o congratularse. Es una reunión de trabajo, una de las más importantes ya que sirve para marcar la estrategia de negocio.
Ficha del Sprint Review
Asistentes: Equipo Scrum (Product Owner, Scrum Master y Equipo de Desarrollo) y Stakeholders
Facilitador: Product Owner
Duración: 4 horas para un Sprint de 4 semanas, menos para sprints más cortos
¿Que se inspecciona durante el Sprint Review?
- El Incremento
- El Sprint
- El Product Backlog
¿Qué se adapta durante el Sprint Review?
- El Product Backlog con las condiciones actualizadas de negocio
Retrospectiva del Sprint
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En ella se hacen transparentes los problemas del equipo y se llegan a acuerdos para solucionarlos. También se inspecciona y adapta la definition of Done
Justo después del Sprint Review, ocurre la retrospectiva, que marca el fin del Sprint. El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo Sprint. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva.
Un formato común es analizar Qué ha ido bien durante el Sprint, Qué ha fallado y Qué se puede mejorar. Este formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban post-its, para luego agruparlos y votar sobre aquellos ítems que sean más relevantes, dando a todo el mundo la oportunidad de hablar y expresar sus inquietudes.
También se utiliza el formato de retrospectiva basado en cinco fases:
- Preparar el ambiente: Un pequeño ejercicio para romper el hielo, junto con el recordatorio de la Prime Directive* hacen el comienzo perfecto.
- Recolectar información: Durante esta fase, se utilizan actividades para intentar construir una imagen de lo que ha sido el último Sprint. Una imagen conjunta de equipo.
- Generación de ideas: Ahora el equipo intenta generar ideas para identificar acciones que ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint.
- Decidir que hacer: De las ideas generadas, se proponen acciones que puedan implementarse en el próximo Sprint. A implementar por todo el equipo.
- Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la propia retrospectiva, ayudan al equipo a decidir donde quieren ir en próximas ocasiones. Un recordatorio de la mejora continua.
Para encontrar actividades para realizar durante la retrospectiva, te recomiendo que le eches un vistazo al Retr-o-mat.
Ficha de la retrospectiva
Asistentes: El equipo Scrum (Product Owner, Scrum Master y Development Team)
Dueño de la reunión: Scrum Master
Duración: 3 horas
¿Qué se inspecciona durante la retrospectiva?
- El último Sprint
- Herramientas y procesos técnicos
- Definition of Done
- Relaciones entre los miembros del equipo
- Procesos
¿Que se adapta durante la retrospectiva?
- Una serie de acciones para mejorar la forma en la que el equipo trabaja
* Prime directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.