Scrum ¿Por dónde empiezo?
Scrum es un framework a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.
Mis primeros pasos
Para empezar te recomiendo que leas minuciosamente la guía de Scrum. Comentar que la guía está condensada de tal forma, que no existe ninguna frase dentro de ella que esté de más. Todo concepto, término o descripción es importante y tiene un propósito. Además, deberás conocer los pilares, los valores, los roles, los eventos y los artefactos que existen.
Pilares del empiricismo
- Transparencia
- Inspección
- Adaptación
Valores de Scrum
- Compromiso
- Coraje
- Foco
- Franqueza
- Respeto
Roles que forman el Scrum Team
Diferenciar cuándo se habla de Scrum Team y cuándo se habla de Dev Team, ya que las responsabilidades pueden afectar al rol de equipo de desarrollo o a todos los roles.
Eventos
Artefactos
Me he leído la guía de Scrum, ¿y ahora qué?
¿Quieres aplicar Scrum? ¿Estás preparado? Para empezar, es recomendable que tu organización apoye la utilización de este framework y que cuentes con los elementos necesarios para su implantación, esto es, un equipo de desarrollo de entre 3 y 9 personas, un Scrum Master y un Product Owner. Menos devs no son suficientes para generar valor y más devs está demostrado que genera demasiada complejidad. El Scrum Master y el Product Owner deben ser personas distintas y no están incluídos en este número excepto si también ejecutan trabajo del Sprint Backlog.
Con respecto a los medios materiales, considero que son importantes los espacios de modo que te permitan celebrar los eventos de una forma cómoda, así como elementos accesorios como tableros, post-it, rotuladores, etc.
También considero fundamental que todas las personas del equipo lean la guía de Scrum, de modo que conozcan cuales son sus responsabilidades. En la guía verás que se habla en ocasiones de accountable y en ocasiones de responsible, y tienen una sutil diferencia. Por ejemplo un Product Owner puede delegar la gestión del Product Backlog en el equipo de desarrollo, por lo que estos serán responsibles de esta gestión, sin embargo, el Product Owner seguirá siendo accountable (es decir, responsable final).
Hemos formado un equipo Scrum, tenemos Product Owner y soy el Scrum Master
¡Muy bien! ahora que habéis formado el equipo, deberás hacer unas primeras tareas básicas que vendrán muy bien de cara a nuestra organización. Recuerda que premia la autoorganización, por tanto, no intentes imponer un modelo sobre otro y deja que sea el conjunto del equipo el que decida la mejor forma de trabajar para la entrega de valor, que al fin y al cabo es nuestro objetivo.
¡Vuelve a revisar los eventos y los artefactos de Scrum!
- Hazte con un tablero físico (ayuda mucho, en serio)
- Ayuda al Product Owner a que entienda la accountabilidad del Backlog y a ordenarlo.
- Ayuda al equipo para mantener la premisa fundamental de entrega de valor como objetivo.
- Establecer como equipo el calendario y horario de los eventos
- Sprint (decidir la longitud del sprint)
- Daily Scrum (no más de 15 minutos)
- Sprint Planning (4 horas máximo para sprint de 2 semanas)
- Refinamiento (menos del 10% capacidad del equipo - este decide cuándo y cómo)
- Sprint review (2 horas máximo para sprint de 2 semanas)
- Retrospectiva (menos de 3 horas para sprint de 2 semanas)
- Establecer el Definition of Done, es decir, lo mínimo necesario para que un PBI (Product Backlog Item) del backlog esté terminado y pase a formar parte del incremento
Mi primer sprint, ¿cómo lo afronto?
¡Estamos a lunes y el miércoles empieza el Sprint 1!
De cara a este primer sprint, ayuda al Product Owner a generar una primera versión del Product Backlog (podéis apoyaros con alguna técnica como la de User Story Mapping) y a ordenarlo. Una vez hecho esto, juntaros todo el equipo Scrum, e intentar refinar los PBIs de cara al Sprint Planning.
Recordar que un PBI es cualquier cosa que sea necesaria para completar el producto, desde casos de uso, historias de usuario, tareas técnicas o requerimientos no funcionales, por lo que debéis intentar no forzar cada item a que sea una historia de usuario.
Como parte del proceso de refinamiento, también es una buena práctica estimar los PBIs en complejidad. Unos PBIs poco definidos y sin estimación, en definitiva sin refinar, generarán muchísima conversación en el evento de planificación que producirá complicaciones de time-box.
Queremos PBIs INVEST y las tareas resultantes del refinamiento de los PBIs, que cumplan el criterio SMART.
Ahora que hablas de estimar, ¿cómo lo hago?
Me gustaría aclarar que la estimación de los PBIs en complejidad forma parte del proceso de refinamiento (bien en el evento de Refinamiento o en el Sprint Planning) y el objetivo es generar una conversación. Las puntuaciones (Story Points) asignadas a un PBI se basará en tamaño, complejidad y esfuerzo y no deberían ser representados por ninguna métrica que implique duración (horas, días, etc). Los Story Points siempre van a tener una relación entre si conocida como Estimación Relativa y van a representar el esfuerzo necesario para dar un PBI por terminado según nuestro Definition of Done.
La estimación relativa es diferente entre equipos
Existen algunas técnicas para ayudar a estimar al equipo y quizás la más famosa sea el Planning Poker, pero existen otras que también nos pueden resultar útiles como T-shirt sizing, No estimates o Affinity Estimation. Este tipo de técnicas, que no forman parte de la definición de Scrum, fomentan que se genere una conversación cuando no tenemos unanimidad sobre el nivel de complejidad de un product backlog item que estamos estimando.
Scrum no prescribe una forma de estimación
Existen multitud de sitios donde puedes descargarte unas cartas o mismo estimar con una app en Android o iOS. A mi, personalmente, me gusta mucho tanto la escala como las cartas que han diseñado el equipo de Redbooth.
Estimando
Scrum se basa en el empiricismo y por tanto, en la experiencia. Al ser nuestro primer sprint no hay datos y tendremos que hacer una suposición informada, esto es, basarnos en la experiencia del equipo en otros proyectos; después, ejecutamos, inspeccionamos y adaptamos.
Basándonos en dicha experiencia, el primer paso es dar una puntuación media (M o 5 puntos) al esfuerzo necesario para conseguir un PBI terminado siguiendo nuestro Definition of Done. Una vez identifiquemos dicho PBI con puntuación media, podremos comparar el resto de los PBIs del Product Backlog ordenado que el Product Owner está presentando para ir estableciendo las puntuaciones del resto.
Capacidad, Velocidad y entrega de valor
La Capacidad es la cantidad de trabajo que un equipo Scrum puede abordar en un sprint y esta directamente relacionada con la Velocidad del equipo, que es la suma de puntos de los PBIs terminados (cumplen el Definition of Done) al final de un sprint.
Si estás utilizando T-shirt sizing, asinga una puntuación a cada talla (S,M,L …) para poder hacer proyecciones
A medida que avancemos en los sprints, las estimaciones y la capacidad del equipo por sprint se irá ajustando y podremos hacer estimaciones más o menos fiables sobre la capacidad por sprint del equipo y la velocidad del mismo, pero siempre teniendo en cuenta que el desarrollo de software es algo complejo.
¡Importante!
- El objetivo es la entrega de software terminado
- La velocidad entre equipos es diferente
- Para hacer estimaciones más o menos fiables, se necesitan al menos tres o cuatro sprints terminados
Sprint Planning
El trabajo a realizar durante el Sprint se planifica en el Sprint Planning y en el participa todo el Scrum Team.
Como comentaba en el apartado anterior, procurar no llegar a este evento sin haber trabajado previamente como equipo cada uno de los PBIs que el Product Owner presentará. Para ello utilizar el refinamiento, ya que esto nos ayudará a descomponer los PBIs e intentar que sean lo más INVEST posibles.
¡En este blog encontrarás unos consejos muy útiles de cómo preparar esta reunión!
El Sprint Planning responde a lo siguiente
-
¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
-
¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
y por tanto, podemos dividir el evento en dos partes.
Parte uno ¿Qué puede hacerse en este sprint?
El Product Owner arrancará esta primera parte del evento discutiendo el objetivo (la idea, no confundir con el Sprint Goal aunque esté directamente ligado) que el Sprint debería lograr y los elementos (PBIs) del Product Backlog que si se completan, lograrían ese objetivo.
Del equipo necesitaremos que determine la capacidad para este primer sprint, es decir, cuántos PBIs será capaz de terminar, aunque siempre teniendo en cuenta que el desarrollo de software es algo complejo y en ocasiones, la capacidad puede ser excedida o no alcanzada.
A medida que avancemos en los sprints, el equipo afinará mejor la cantidad de PBIs que pueden entrar en un sprint, es decir, su capacidad real estimada.
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Equipo de Desarrollo y está relacionado con su capacidad y la estimación de esfuerzo de cada uno de los PBIs que el Product Owner ha ido presentando para lograr el objetivo del Sprint.
Volver a hacer una estimación final aunque ya se hayan estimado en el refinamiento.
Una vez que el equipo de desarrollo selecciona los PBIs que completan el objetivo del sprint, el Scrum Team define dicho Sprint Goal y queda establecido como meta para todo el sprint.
Parte dos ¿Cómo se completará el trabajo seleccionado?
Ahora que ya tenemos el Sprint Goal y el conjunto de PBIs que lograrán esta meta, es el momento de realizar un plan que logre terminar cada uno de los elementos seleccionados. Estos PBIs seleccionados, más el plan para terminarlos, recibe el nombre de Sprint Backlog.
Para poder realizar este plan, el equipo de desarollo deberá descomponer en lo que queda de reunión, los primeros PBIs en tareas de al menos un día, para tener suficiente trabajo en los primeros días del sprint. A medida que avancemos en el sprint, podremos continuar descomponiendo el resto de PBIs.
¡Importante! El Scrum Master debe enseñar al equipo a mantenerse dentro del time-box para este evento.
Sprint Goal
Prestar mucha atención a la definición como equipo del Objetivo del Sprint en cada planificación; es clave, ya que nos sirve de guía y nos ayuda con el foco de una forma increíble a través de todo el Sprint.
Los equipos mejoran su entrega de valor cuando el Sprint Goal está bien definido y se utiliza como guía durante el sprint.
Además, el Sprint Goal nos servirá para no perder el objetivo de Sprint en caso de que se produzca cualquier tipo de inconveniente.
En este link podréis encontrar una buena plantilla para generar Sprint Goals.
Daily Scrum
Daily Scrum es un evento diario de 15 minutos como máximo para el Equipo de Desarrollo. En él se planea el trabajo para las próximas 24 horas y se lleva a cabo cada día en la misma hora y mismo lugar para reducir complejidad.
He visto en muchas ocasiones, cómo este evento se convierte en un reporte de lo que el developer ha hecho durante el día anterior y lo que va a hacer en el día en curso. Esto ocurre cuando la aplicación de Scrum se ha hecho por obligación o sin haberla fundamentado mínimamente en los pilares (Transparencia, Inspección, Adaptación) y valores (compromiso, coraje, foco, franqueza, respeto). Puede sonar a cliché, pero nada más lejos de la realidad, ya que si todo el equipo es capaz de alinearse con los valores, seremos capaces de confiar en el trabajo diario del equipo para lograr la meta del sprint.
La Daily Scrum nos puede servir de termómetro para comprobar si un equipo está en un modelo Agile o está encubriendo un modelo Waterfall
La mayoría de la gente, adopta la técnica de responder a tres preguntas:
- ¿Qué hice ayer?
- ¿Qué voy a hacer hoy?
- ¿Qué impedimentos tengo?
El problema de estas tres preguntas es que le falta una segunda parte que nos va a ayudar a que el Equipo de Desarrollo tenga foco y no piense en el evento como una reunión de control:
- ¿Qué hice ayer para conseguir el Objetivo del Sprint?
- ¿Qué voy a hacer hoy para conseguir el Objetivo del Sprint?
- ¿Qué impedimentos tengo para conseguir el Objetivo del Sprint?
Por favor, si eres Scrum Master y el Product Owner quiere hablar, no lo hagas callar basándote en la guía de Scrum ;)
Sprint Review
La Sprint Review se lleva a cabo al final del Sprint para inspeccionar el incremento y adaptar el Product Backlog si es necesario.
Un gran artículo sobre la Sprint Review se puede encontrar en este enlace
Algunos puntos importantes citados son
- Es una reunión informal, no una reunión de estado ni una demo
- No está para aplaudir al equipo de desarrollo
- No es el momento de aceptar los PBIs terminados
Esperar a la Sprint Review para aceptar los PBIs terminados, resultaría en un gráfico de burndown totalmente plano con una caída en el último día de sprint. Es el Product Owner el que debe colaborar con el equipo Scrum durante todo el sprint para ir aceptando los PBIs hechos acorde a nuestra Definition of Done.
Es una reunión de negocio donde los stakeholders dan feedback y el resultado es un Product Backlog actualizado con este feedback.
Retrospectiva
La Sprint Retrospective es una oportunidad para que el equipo Scrum se inspeccione a si mismo y crear un plan de mejoras (acciones) que sean abordadas durante el siguiente sprint.
El propósito de la Retrospectiva es:
- Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas
- Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras
- Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.
A esto debemos añadir la inspección y adaptación de nuestro Definition of Done
En todo momento estamos hablando de un plan y con esto nos referimos a generar acciones en forma de PBI que pasen a formar directamente parte de nuestro siguiente Sprint Backlog.
Estas acciones pueden generar Product Backlog Items como historias técnicas, spikes de programación o investigación y que es posible que requiran esfuerzo y por tanto se deban estimar, pero también pueden ser acciones que puedan ser resueltas por el Scrum Master o Product Owner y no sea necesario hacer una estimación.
En este enlace encontraréis una fuente muy grande de diferentes tipos de Retrospectivas que os ayudarán a hacer este evento más ameno.
Es muy importante que el Scrum Team no caiga en la rutina de hacer siempre el mismo tipo de retrospectiva.
Refinamiento
Es un evento que no forma parte del CORE de Scrum, pero en la guía hace mención a esta sesión en el apartado de Backlog. Es una sesión que no debe exceder el 10% de la capacidad del equipo durante un sprint y durante este tiempo permite trabajar al equipo, conjuntamente con el Product Owner, en los posibles PBIs que pueden entrar en el siguiente sprint.
Es muy importante que el Product Owner haya trabajado por su cuenta los PBIs a nivel funcional, de modo que pueda responder de forma adecuada y lo mejor posible a las dudas del equipo.
Además, en esta sesión, es recomendable hacer una estimación previa de esfuerzo, por si es necesario dividir el PBI al no ser lo suficientemente SMART.
Aunque no forme parte del core de Scrum, es una reunión muy importante para empezar a encaminar el trabajo del siguiente sprint, pues es aquí donde el equipo debe aclarar cualquiera duda y empezar a analizar el esfuerzo de cada PBI que el Product Owner presenta.
Al principio, como no conocemos la capacidad de nuestro equipo Scrum, recomiendo que los primeros refinamientos sean de al menos una hora y media o dos horas.
Herramientas, métodos y técnicas (o movimientos)
User story mapping es un ejercicio visual que ayuda a definir y crear una experiencia de usuario de una forma más sencilla. Se utiliza para mejorar la comprensión de los equipos y para priorizar el trabajo.
Kano o Modelo de Kano es una teoría de desarrollo de producto y en el que clasifica las preferencias del cliente en cinco categorías, sirviendo así como una técnica más de ayuda a la priorización de desarrollo de producto en base a dichas categorías.
Método MoSCoW es una técnica de priorización que permite clasificar los requerimientos en categorías de importancia en la entrega de producto (Must have, Should have, Could have, Won’t have (this time)).
Planning Poker es una técnica de estimación de PBIs.
Affinity estimate técnica de estimación
T-shirt sizing al igual que el Planning Poker y Affinity Estimates, es otra técnica de estimación
No Estimates es un movimiento, no una técnica concreta de estimación, en relación a las estimaciones y previsiones del desarrollo de software.
Gráfico de Burndown es una representación gráfica del trabajo restante en un sprint. En el eje X mostramos el trabajo que queda por hacer y en el eje y el tiempo. Ha ido perdiendo importancia en las sucesivas revisiones de la guía de Scrum.
Retromat es un site en el que encontrás un conjunto enormes de diferentes tipos de retrospectivas que puedes realizar con el equipo.