Objetivo del documento
A continuación se describe el estándar SCRUM que aplica nuestro equipo de desarrollo. Es importante recordar que la metodología es muy flexible, por lo que lo indicado en este documento es solo una orientación; cada uno es libre de adaptar y modificar este modelo a su propio contexto.
Product Backlog
El product backlog es una lista de los elementos (Product Backlog Items) necesarios para completar el producto; en él podemos encontrar historias, bugs, requisitos técnicos, ideas y elementos de estudio (Spike). Es importante que el product owner pueda entender cada item y el motivo por el que está ahí sin necesidad de saber qué hay que implementar (técnicamente).
Otro aspecto importante es que el product backlog está siempre sujeto a cambios; de hecho, adquirir nuevos conocimientos sobre el producto que se está desarrollando puede llevar a reevaluar las prioridades de los elementos situados en la parte alta del backlog, elementos que pueden intercambiarse con otros situados más abajo, eliminarse o añadirse al Product Backlog.
User Story
Las user stories describen una única funcionalidad del sistema desde la perspectiva de un usuario final. Deberían ser pequeñas para que el equipo pueda hacer una estimación aproximada del esfuerzo necesario para llevarlas a cabo.
Cada historia incluye:
- ID: código identificativo único de la historia
- Nombre: un nombre breve que identifica la historia; debe ser lo bastante claro para que los desarrolladores y el product owner entiendan a grandes rasgos de qué se está hablando.
- Importancia: un valor que mide lo importante que es la historia para el product owner.
- Estimación: valoración por parte del equipo de cuánto trabajo hace falta para implementar la historia
Cada historia debería cumplir el acrónimo INVEST:
- Independent: No debe tener interdependencias con otras user stories.
- Negotiable: Deben ser “negociables” y estar abiertas a las aportaciones de todos
- Valuable: Debe ser capaz de aportar valor añadido al usuario final.
- Estimable: Debe poder estimarse
- Small: No debe ser tan grande que no se pueda planificar o realizar
- Testable: Debe poder probarse e incluir información sobre cómo ejecutar las pruebas (Criterios de aceptación).
Consejo:
Lo importante no es tener estimaciones absolutamente correctas (es decir, que una historia de dos puntos requiera dos días), lo importante es tener estimaciones relativamente correctas (es decir, que una historia de dos puntos requiera aproximadamente la mitad de trabajo que una historia de cuatro puntos).
Cómo escribir las user stories
Cada historia describe qué hacer, para quién y por qué, de modo que el cliente y los desarrolladores la entiendan de la misma manera. El punto de vista es el de quien solicita la nueva funcionalidad, y la cantidad de información es la imprescindible para que el equipo de desarrollo pueda hacer una estimación aproximada del trabajo necesario para llevarla a cabo.
Scrum no ofrece ninguna indicación ni obligación sobre el formato que se debe utilizar para redactar estos elementos, pero el formato que resulta más útil para este fin es el siguiente:
As a type of user, I want some goal so that some reason
Como tipo de usuario, quiero una funcionalidad concreta, para obtener valor/beneficio
Backlog Refinement
El objetivo de esta reunión es perfeccionar el backlog leyendo las historias, con el fin de preparar el terreno para la planificación del próximo sprint. El backlog refinement tiene una duración máxima de 2 horas y se lleva a cabo durante el sprint. El product owner define el objetivo del próximo sprint e identifica las historias necesarias para alcanzarlo; a cada historia se le asigna un grado de importancia.
Obviamente, el objetivo no es repasar todo el Product Backlog, sino solo los elementos que se prevé incluir en la siguiente iteración o, como máximo, en los dos próximos Sprints. Es responsabilidad del Product Owner definir o aclarar las prioridades y los objetivos.
Se procede reordenando las historias del backlog según las decisiones del product owner (objetivo e importancia). Durante la reunión, con la ayuda del product owner, se leen las historias seleccionadas, se aclaran las posibles dudas y, si procede, se optimizan (por ejemplo, las historias grandes se dividen en historias más pequeñas).
El Product Owner aporta detalles y responde a las preguntas sobre el “porqué”; los desarrolladores aportan detalles y responden a las preguntas sobre el “cómo”
Sprint Planning
“El propósito de la reunión de sprint planning es dar al equipo información suficiente para poder trabajar tranquilo y sin interrupciones durante unas semanas, y dar al product owner la confianza suficiente para que se lo permita.”
El sprint planning tiene un time box: debería durar como máximo 3 horas, con una pausa de 10 minutos cada hora. Si no se ha alcanzado el objetivo, se continúa con lo que se ha analizado (el equipo aprende a gestionar mejor el tiempo).
El motivo por el que es necesario que todo el equipo y el product owner estén presentes en la reunión de sprint planning es que el product owner tiene la responsabilidad de compartir el alcance y la importancia, mientras que el equipo tiene la responsabilidad de aportar las estimaciones; estas tres propiedades (alcance, importancia, estimaciones) se someten a un refinamiento continuo gracias al diálogo cara a cara con el product owner.
En la primera parte de la reunión, el product owner comparte el objetivo del sprint e indica las historias que, en su opinión, permiten alcanzarlo; el equipo examina cada historia y estima sus tiempos, empezando por la más importante. Durante este proceso, si es necesario, se dividen en tareas más detalladas (las estimaciones de tiempo suelen ser más fáciles cuando las historias están divididas en tareas); es posible que, al crear las tareas, surjan preguntas importantes sobre el alcance: en algunos casos las respuestas sorprenderán al equipo y le llevarán a cambiar sus estimaciones; en otros, la estimación no es la que deseaba el product owner, lo que podría llevarle a cambiar la importancia de la historia o a modificar su alcance (lo que implicará una nueva estimación). Después, para cada tarea, se procede con el Planning Poker.
Cuando todas las historias están claras y estimadas y, si es necesario, se ha definido una tarea para cada una de ellas, el equipo decide qué historias llevar al próximo sprint (es el equipo quien decide cuántas historias incluir en el sprint, no el product owner ni nadie más). En este punto se puede proceder de dos maneras:
- Primera manera: se pide al equipo que ignore las cifras y se limite a pensar, de forma intuitiva, si cree que podrá completar las historias seleccionadas para el sprint; si parece demasiado, se prueba a quitar alguna historia; si, por el contrario, parece poco, se prueba a añadir alguna. El product owner puede influir en este proceso actuando sobre las historias (puede simplificarlas o cambiar su importancia).
- Segunda manera: se comprueba la velocidad del equipo y, a continuación, se calcula cuántas historias se pueden añadir sin superar la velocidad estimada.
Consejo para el scrum master: ¡se pueden combinar ambas maneras!
Si el sprint termina antes de tiempo
Se evalúan y se llevan al sprint las historias situadas en la parte alta del backlog (ordenado previamente)
Si el sprint termina con historias sin completar
El equipo aprende del error para no repetirlo y las historias se mueven a la parte alta del backlog. Llevarlas al próximo sprint dependerá del Product Owner, ya que, mientras tanto, las prioridades podrían haber cambiado.
Velocidad del equipo
La velocidad del equipo está representada por los story points que el equipo consigue completar en una iteración. Hay distintos métodos para calcular la velocidad del equipo; a nosotros nos resulta más eficaz calcularla en función de las jornadas-persona, y asociamos a una jornada-persona el valor de 2 story points. Así, suponiendo un equipo de 4 personas, se pueden completar 8 story points al día. Sin embargo, este valor no es del todo eficaz, ya que presupone una jornada ideal, sin interrupciones (algo poco habitual). Además, convendría tener en cuenta factores como el trabajo no planificado añadido al sprint, las bajas por enfermedad, etc.
De hecho, harán falta entre tres y cinco sprints para estabilizar la velocidad del equipo de desarrollo. El primer sprint suele ser complejo. Se trata de empezar con un equipo cuyos miembros no necesariamente se conocen. La velocidad rara vez es alta, pero irá aumentando gradualmente durante los tres o cuatro primeros sprints hasta estabilizarse. La velocidad Agile es entonces óptima y relativamente representativa, aunque sigue siendo una estimación del esfuerzo que el equipo es capaz de producir durante un sprint. Una vez estabilizada la velocidad Agile, es posible prever con bastante fidelidad el número de story points que el equipo consigue completar. Para tener una estimación fiable y, por tanto, hacer previsiones de entregas más eficaces, conviene tener en cuenta al menos 4 o 5 Sprints.
Sprint Review
La sprint demo es una reunión muy importante, de una hora como máximo, cuyo objetivo es aumentar la confianza entre el equipo y el product owner para que disminuyan las interrupciones y las presiones. De hecho, permite al equipo demostrar al product owner la atención que ha prestado a sus peticiones, ganando así credibilidad. Además, se obtiene el feedback de los distintos stakeholders para poder corregir el rumbo a medida que avanzan las iteraciones.
Otra ventaja: el equipo se ve impulsado a completar y entregar el incremento (aunque sea solo en un entorno de pruebas). Sin las demos, se seguirá teniendo una larga lista de cosas “terminadas al 99 %”.
Durante la demo se recuerda el objetivo del sprint y, si es necesario, se describe el producto a quienes no lo conocen. La demo debería ser breve, no bonita, y debe estar orientada al negocio, evitando detalles técnicos. Si es posible, habría que permitir a los asistentes (Product owner) probar por sí mismos las funcionalidades del producto.
Retrospectiva
La retrospectiva es la segunda reunión más importante de la iteración, porque es la mejor ocasión para mejorar, y tiene una duración máxima de tres horas. Cada miembro del equipo podría tener una idea para mejorar, pero no es posible saber si el equipo está dispuesto a aplicarla; esta reunión ofrece la posibilidad de intercambiar opiniones y debatir para que todos puedan contribuir a la mejora.
Cada miembro del equipo puede decir qué cree que ha ido bien, qué cree que podría haber ido mejor y qué haría de otra manera en el próximo sprint.
Se analiza la diferencia entre la velocidad estimada y la velocidad real y, si hay una gran diferencia, se intenta analizar las causas. Cuando el tiempo está a punto de agotarse, el scrum master intenta resumir las sugerencias concretas sobre lo que se podría hacer mejor en el próximo sprint.
Poker Planning
- El equipo de desarrollo, junto con el Product Owner, se reúne en una sala (también virtual)
- El Product Owner presenta al equipo una user story y deja un espacio para las preguntas. El objetivo es que todos los presentes la entiendan y partan de la misma base para poder llegar a una estimación de cada uno de los items que componen la user story.
- Comienza la fase de “estimación”: se elige el primer elemento que se va a valorar y cada participante, de forma individual y privada, asigna una carta de su baraja según el esfuerzo que considere necesario.
- Tras una cuenta atrás, los participantes descubren sus cartas a la vez: si todas las cartas coinciden, se asigna ese valor al item y el procedimiento termina. Si las cartas son distintas, se debaten los valores que se alejan especialmente de la media. Así, la persona que ha asignado el valor más bajo y la que ha asignado el más alto deben justificar su elección. Una vez terminadas las explicaciones, hay que hacer una nueva estimación. Este procedimiento se repite en un ciclo continuo hasta alcanzar la unanimidad.
Consejo:
- Las historias también pueden estimarse comparándolas con historias ya completadas o estimadas anteriormente (¿tiene el mismo peso? ¿un poco menos o un poco más?)
- Para facilitar la estimación, se puede suponer que 2 story points equivalen a una jornada laboral (8 horas).
- Si no se llega a un consenso, se puede recurrir a una media.
Iteración ideal
Tras varios proyectos y distintos intentos, hemos configurado lo que a día de hoy consideramos la iteración ideal. Hemos observado que un sprint de 2 semanas ofrece el equilibrio adecuado entre calidad y velocidad. La configuración semanal que nos ha parecido mejor es la siguiente: el sprint empieza un lunes y termina un viernes; el último miércoles se hace el Backlog Refinement para organizar el próximo Sprint; después, el miércoles se considera cerrado el sprint y se continúa con las demás reuniones (demo, retrospective, Sprint Planning de la siguiente iteración).
Suponiendo que exista un backlog definido, se empieza con el Backlog Refinement, con una duración máxima de 2 horas; durante esta reunión se reordenan las historias según las prioridades del cliente y se presentan al equipo empezando por la primera de la parte alta del backlog; si es necesario, las historias se descomponen en work items más sencillos.
Al cabo de las 2 horas tendremos suficientes historias refinadas para poder organizar un sprint; las historias restantes se refinarán en el próximo refinement si, y solo si, las prioridades lo permiten. Después del Backlog Refinement, incluso el mismo día, se pasa al Poker Planning, estimando las historias refinadas previamente; conviene hacerlo el mismo día porque el equipo debería tener muy claro lo que ha refinado y no se ha distraído con otras cosas. Una vez estimadas las historias refinadas, se pasa al Sprint Planning, donde el equipo decide qué llevar al sprint para alcanzar el objetivo indicado por el PO; el equipo elige las historias guiándose por su percepción, y es importante dejar claro que no es tan grave si algunas historias se quedan en el sprint sin completarse, porque el equipo, sobre todo en la fase inicial, debe alcanzar un grado de conciencia que le permita mejorar esa percepción; el scrum master puede aprovechar la velocity del equipo para comprobar si lo indicado es realista o no y, si es necesario, puede influir en la decisión del equipo. El sprint planning dura como máximo 2 horas, por convención 2 horas por cada 5 días de sprint. Se continúa con el sprint y cada día se celebran los distintos Daily Meeting, en los que es importante que cada miembro del equipo entienda la importancia de informar al equipo sobre el estado de las actividades realizadas. El Daily tiene una duración máxima de 15 minutos; las posibles discusiones que no entren en las 3 preguntas deben tratarse en otras reuniones con las personas directamente implicadas.
Terminado el sprint, se pasa a la Review, que permite al cliente probar la aplicación y dar su feedback sobre el trabajo realizado; tiene una duración máxima de 1 hora. Por último se celebra la Retrospective, incluso el mismo día, en la que el equipo identifica qué ha ido bien y qué ha ido mal, con el fin de mejorar las próximas iteraciones; tiene una duración máxima de 3 horas. Y se vuelve a empezar con el Backlog Refinement.
Pro tips
Precondiciones: existe un backlog de user stories.
- Llevar al cliente a definir varios objetivos para poder planificar un release plan.
- El PO define un objetivo (sprint goal) para el próximo sprint (qué entregar en la próxima release)
- El PO identifica qué historias hay que llevar al sprint para alcanzar el objetivo (cumplir el sprint goal) y se reordenan las historias.
- Se hace el refinement con el equipo: se explican las user stories y, si es necesario, se optimizan (por ejemplo, las historias grandes se dividen en historias más pequeñas). Se deja un periodo de estudio de las historias aprobadas en el backlog (1 día). Se obtienen las tareas de cada historia estudiada.
- Se hace el poker planning de las tareas creadas.
- Se hace el sprint planning con el equipo: se llevan al sprint todas las historias y tareas que hay que completar para alcanzar el objetivo de la release fijado por el PO. Dura como máximo dos horas por semana de desarrollo.
- Arranca el sprint y se celebran los distintos daily scrum.
- Al final del sprint se hace la review: una demo con el cliente para entender qué historias completadas se quieren entregar.
- El incremento se entrega al cliente (se hacen los merges en main y se incrementan las versiones según la lógica habitual).
- El sprint ha terminado. En este punto se hace una retrospective.
