El día a día de un proyecto ágil: Scrum. Desde la conceptualización a la entrega del producto

• Marcos Bermejo

  

  Es programador desde el 2005, ha trabajado en varios lenguajes, en especial VB.net y más recientemente PHP. En los últimos dos años, ha estado formándose y aprendiendo sobre metodologías ágiles, hizo el Professional Scrum Developer de la scrum.org impartido por José Luis Soria y el curso de Coaching de equipos ágiles de Ángel Medinilla. En la actualidad, trabaja en Runroom como Scrum master y también como programador desarrollando aplicaciones web.

• Marc Florit

  

  Ingeniero en Telecomunicaciones de formación, gestor de proyectos y servicios informáticos de profesión y facilitador de vocación. Inició su camino profesional creando su propia empresa en 1997 para dar servicio de acceso a Internet a particulares y pymes de Barcelona. En el año 2000 fichó por una consultora en la que consiguió formar parte, a lo largo de doce años, de gran parte de los departamentos y roles productivos, finalizando esta etapa como gerente de operaciones. Este bagaje le ofreció una enorme experiencia que le permitió entender la manera en que las personas trabajan y colaboran para lograr los objetivos demandados.

  A principios de 2012 creó WynWin y desde entonces colabora con profesionales y empresas con el objetivo de lograr la excelencia de sus equipos y productos, y optimizar sus procesos operativos y de negocio mediante la adopción de metodologías y técnicas ágiles.

• Ramon G. Sedó

  

  Licenciado en Comunicación Audiovisual y desde hace más de quince años trabajando en la Universidad Autónoma de Barcelona, en el Instituto de la Comunicación, como director de la Unidad de Comunicación y Gestión de la Información, departamento responsable de conceptualizar y desarrollar proyectos en línea. También trabaja como profesional independiente en diversas empresas e instituciones, nacionales e internacionales, haciéndose cargo de proyectos relacionados con Internet, las nuevas tecnologías de la comunicación y la gestión de información.

PID_00236257

---

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya), no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

2.Cómo funciona Scrum

1) El product backlog

Un proyecto de Scrum está impulsado por una visión de producto elaborada por el propietario del producto y se expresa en la pila de producto. El product backlog es una lista priorizada de lo que se requiere, por orden de valor para el cliente o negocio, con los elementos de mayor valor en la parte superior de la lista. El product backlog evoluciona durante la vida útil del proyecto y los elementos se añaden, se sacan o son repriorizados continuamente.

2) El sprint

Scrum estructura el desarrollo de productos en ciclos de trabajo llamado sprints, repeticiones de trabajo que tienen típicamente entre una y cuatro semanas de duración. Los sprints son de duración determinada y nunca se extienden más allá de la fecha fijada al comienzo, independientemente de si el trabajo planificado por el sprint se ha completado o no.

3) Planificación del sprint

Al inicio de cada sprint, se lleva a cabo la reunión de planificación del sprint. El propietario del producto y el equipo Scrum (con la facilitación del scrum master) revisan la pila de producto, tratan los objetivos y el contexto de las historias de usuario y el equipo Scrum selecciona los elementos de la pila de producto que se comprometen a realizar para el final del sprint, partiendo de la parte superior de la pila de producto, donde se encuentran los elementos de priorización más alta.

Cada elemento seleccionado en la pila de producto se descompone después en una serie de tareas individuales. La lista de tareas se registra en un documento denominado sprint backlog.

4) Reunión diaria de Scrum

Una vez se ha empezado el sprint, el equipo Scrum se dedica a otra de las principales prácticas de Scrum, como es la reunión diaria de Scrum o dailystand-up en su nombre original en inglés. Se trata de un breve encuentro (de máximo quince minutos) que tiene lugar cada día de trabajo a una hora determinada. Todos los miembros del equipo asisten a la misma. En esta reunión se presenta la información necesaria para inspeccionar el avance desde el día anterior. Esta información puede resultar en la replanificación y en debates sobre la funcionalidad después del daily stand-up.

5) Revisión del sprint y retrospectiva

Una vez finalizado el sprint, se produce la reunión de revisión del mismo, donde el equipo Scrum y las partes interesadas inspeccionan lo que se hizo durante el proceso y lo tratan. En esta reunión están presentes el propietario del producto, los miembros del equipo y el scrum master, además de los clientes, los implicados en el negocio, expertos, ejecutivos y cualquier otra persona interesada.

Tras la revisión del sprint, el equipo se reúne para la retrospectiva de este, que es una oportunidad para que el equipo trate lo que ha funcionado bien durante el sprint y lo que no funciona, y se ponga de acuerdo en los cambios que pretenden intentar durante el siguiente sprint con objeto de conseguir ser más productivos.

4.Primeros pasos

Iniciar un proyecto Scrum no es difícil, siempre y cuando uno dé un paso a la vez y se asegure de que todo el mundo se sienta incluido.

4.1.El product backlog o pila de producto

Un proyecto de Scrum está impulsado por una visión de producto elaborada por el propietario del producto y se expresa en la pila de producto. El product backlog es una lista priorizada de lo que se requiere, por orden de valor para el cliente o negocio, con los elementos de mayor valor en la parte superior de la lista. El product backlog evoluciona durante la vida útil del proyecto y los elementos se añaden, se sacan o son repriorizados continuamente.

Este registro no solo existe y evoluciona a lo largo de la vida útil del producto, sino que es la hoja de ruta del producto.

En cualquier momento, la pila de producto es el punto de vista único y definitivo de todo lo que se puede hacer por el equipo, en orden de prioridad. Solo existe una única pila de producto.

La pila de producto incluye una variedad de elementos, sobre todo las nuevas características del producto (“permitir a los usuarios colocar el libro en la cesta de la compra”), pero también los objetivos de mejora de ingeniería (“revisar el módulo de procesamiento de transacciones para que sea escalable”), de exploración o trabajo de investigación (“investigar soluciones para acelerar la validación de la tarjeta de crédito"”), los requisitos de rendimiento y seguridad y, posiblemente, los defectos conocidos (”diagnosticar y corregir los errores de procesamiento de pedidos de secuencia”), si solo hay unos cuantos problemas (un sistema con muchos defectos en general tiene un sistema de seguimiento de defectos por separado).

Por lo general, se articulan los requisitos en términos de historias de usuario, que son descripciones concisas y claras de la funcionalidad en términos de su valor para el usuario final del producto.

El subconjunto de la pila de producto que se destina para la versión actual se conoce como la pila de la versión, o release backlog en el inglés original, y en general esta parte es el objetivo principal del propietario del producto.

Ampliación

Ejemplo de una pila de producto

La pila de producto la actualiza constantemente el propietario del mismo para reflejar los cambios en las necesidades del cliente, las nuevas ideas o puntos de vista, los movimientos de la competencia, obstáculos técnicos que aparecen y así sucesivamente. El equipo ofrece al propietario del producto las estimaciones del esfuerzo requerido para cada elemento de la pila de producto. Además, el propietario del producto es responsable de asignar una estimación del valor de negocio a cada elemento individual. Esto suele ser una práctica desconocida para un propietario del producto novel.

Como tal, es algo que un scrum master puede ayudar al propietario del mismo a aprender a hacer. Con estas dos estimaciones (esfuerzo y valor) y quizás con las estimaciones de riesgo adicionales, el propietario del producto da prioridad a la cartera de pedidos para maximizar el retorno de la inversión (eligiendo elementos de alto valor con poco esfuerzo) o, en segundo lugar, para reducir algún riesgo importante. Como veremos, estas estimaciones de esfuerzo y valor se pueden actualizar en cada sprint dado que la gente aprende y, en consecuencia, se produce una repriorización continua de la actividad y la pila de producto está en evolución constante.

Scrum no obliga a ejecutar las estimaciones de la pila de producto de una forma determinada, pero es común el uso de estimaciones relativas, calificadas como puntos de historia en lugar de unidades absolutas de esfuerzo, como horas-persona. Con el tiempo, y un buen seguimiento de los resultados del equipo, se pueden extraer conclusiones en función de la cantidad de puntos de historia relativos que un equipo de producción multimedia es capaz de implementar para cada sprint (por ejemplo, una media de 26 puntos de historia por sprint). Con esta información se puede proyectar una fecha de lanzamiento para completar todas las características o cuántas características se completarán con probabilidad antes de una fecha. Los puntos completados por sprint reciben el nombre de velocidad del equipo. Un plan de lanzamiento realista siempre se basa en la velocidad del equipo.

Los elementos de la pila de producto pueden variar significativamente en tamaño y esfuerzo. Los más grandes se rompen en elementos más pequeños, normalmente durante reuniones de refinamiento de la pila del producto o bien en la reunión de planificación del sprint.

¿La cantidad de detalles?

Uno de los mitos sobre Scrum es que impide escribir las especificaciones detalladas. En realidad, son el propietario del producto y el equipo quienes deben decidir cuánto detalle se requiere y esto puede variar de un elemento a otro, dependiendo de la visión del equipo y de otros factores. Se tiene que procurar reflejar lo que es importante en la menor cantidad de espacio necesario, en otras palabras, no describir todos los detalles posibles de un elemento, simplemente dejar claro lo que hace falta para que se entienda. Los elementos de baja prioridad, que son propensos a ser implementados en una etapa posterior, tendrán en general menos detalles respecto a los requisitos de alta prioridad, que pronto se llevarán a cabo y por lo tanto tienden a tener más detalles.

4.1.1.La visión del producto: pensando en el usuario. Las historias de usuario

La lista de tareas definidas en la pila de producto, aunque SCRUM no lo define, surgen en la mayoría de ocasiones de las historias de usuario, uno de los formatos más utilizados para crear las pilas.

Una historia de usuario es una redacción breve de una funcionalidad que por sí misma da valor al usuario.

Se compone de un título, una descripción breve sobre qué tiene que hacer la funcionalidad y unas condiciones de aceptación. Opcionalmente, se pueden añadir anotaciones y acotaciones a la historia.

Es muy aconsejable usar la siguiente estructura:

Como [papel de usuario] quiero [funcionalidad] para [objetivo]

Cómo tiene que ser una historia de usuario

Una buena historia de usuario sigue las siglas INVEST, es decir, es:

• Independiente,

• Negociable,

• Valiosa para usuarios y clientes,

• Estimable (se puede medir),

• Small (suficientemente pequeña para poder trabajar con ella), y

• Testeable.

1) Independiente

Las dependencias entre historias a veces derivan en problemas en la planificación y priorización. Si una historia muy poco prioritaria está vinculada con una que lo es mucho, la priorización será complicada.

Cuando dos historias están vinculadas, hacen muy difícil la estimación, puesto que surgen dudas tales como “Si desarrolláramos primero la historia A, la historia B sería más fácil de hacer y supondría menos esfuerzo, pero la historia A no es prioritaria”. En la gestión ágil de proyectos siempre se hace antes lo más prioritario, así que entraríamos en un conflicto.

Cuando se presentan estos tipos de dependencias entre historias hay dos caminos para solucionarlo:

1) Combinar las historias dependientes en una más grande, pero independiente del resto.

2) Encontrar un camino diferente en la definición de estas historias.

2) Negociable

Las historias de usuario son descripciones cortas de funcionalidades, cuyos detalles deben ser negociados en conversaciones posteriores entre el cliente y el equipo de producción. Tal como hemos dicho al comienzo, una historia se compone de una breve descripción acompañada opcionalmente de anotaciones o acotaciones de la historia. Estas acotaciones se tendrán que ir negociando a lo largo del proyecto.

Acotar la funcionalidad

Las anotaciones de una historia deben acotar su funcionalidad. Es decir, si tenemos una funcionalidad de “Como usuario administrador quiero poder generar un documento Word con el listado de nombres de los productos del sistema”, una anotación como “la funcionalidad también debe sacar el listado en PDF” no acota ni detalla la funcionalidad, la aumenta. Una anotación posible sería “el documento Word tiene que estar en el formato oficial de la empresa”.

En muchos proyectos, se confunde dar más detalles con dar más precisión. No hay que entrar en la precisión excesiva, si la historia se puede estimar y priorizar se pueden dejar los detalles precisos para conversaciones posteriores.

Podemos ver una historia como un recordatorio de tener una conversación entre el equipo de producción y el cliente. Donde la descripción indica sobre qué funcionalidad tenemos que hablar y las anotaciones serían los detalles a los que se han llegado en estas conversaciones.

3) Valiosa

La mejor manera de asegurarse de que una historia es valiosa para el cliente es dejarlos escribir a ellos las historias. Es habitual que los clientes se muestren incómodos con esta propuesta, ya que están acostumbrados a que todo lo que escriben es un contrato y se puede usar en su contra (“Como no escribiste que querías la validación del DNI...”). En la gestión ágil de proyectos no se busca esta manera de “pasar la pelota”. Es muy extraño que detalles importantes no se comenten en las conversaciones entre cliente y equipo de producción.

Si logramos tener a un cliente que confía en nosotros y se involucra, tenemos mucho ganado en la definición de historias.

4) Estimable

Hay tres razones comunes por las que una historia de usuario no se puede estimar:

1) poco dominio por parte del equipo de producción del lenguaje del cliente;

2) poco dominio técnico por parte del equipo de producción sobre la tecnología que se va a usar; y

3) la historia es demasiado grande.

Si el equipo de producción no entiende la historia tal cual se ha escrito, la solución es celebrar reuniones entre el equipo de producción y el cliente. En la gestión ágil de proyectos no está permitido ahorrarnos conversaciones ni suponer o interpretar conceptos. Si el equipo de producción no está seguro de lo que tiene que hacer, se tiene que hablar para entenderlo.

Si el problema es tecnológico, la solución es reservar uno o dos programadores para un spike.

Un spike es un breve experimento para aprender cómo funciona una tecnología y qué implicaría en nuestro proyecto usarla.

Durante el spike, se pide a los programadores que experimenten y aprendan todo aquello necesario solo para estimar la funcionalidad, no que la desarrollen.

Si el problema es que la historia de usuario es demasiado grande para estimarla con cierta precisión, la única salida es dividirla, más adelante aprenderemos cómo dividir las historias de usuario.

Aunque una historia sea demasiado grande, a veces son útiles como épicas. Las historias épicas son recordatorios de las grandes partes del sistema que tienen que ser desarrolladas.

5) Small

El tamaño ideal de las historias varía en función del equipo, las capacidades y la tecnología empleada.

Si la historia se tiene que dividir, se deben tener en cuenta las consignas siguientes:

a) Dividir historias por su composición

Tenemos que pensar en el flujo de acciones que el usuario va a ejecutar en toda esta funcionalidad, por ejemplo “Como usuario administrador quiero poder administrar los productos del sistema” se podría dividir en “ver una lista de productos”, “crear un producto”, “eliminar un producto”, “editar un producto”. Tener en mente las siglas CRUD (create, read, update, delete) nos puede ayudar en esta tarea.

b) Dividir historias complejas

Esto es menos obvio. Son aquellas historias que son muy complejas técnicamente o que no se han hecho nunca y no sabemos cuánto nos pueden costar, la división recomendada en este caso es investigar-realizar-refactorizar. Podemos crear una historia de usuario que sea “Investigar cómo hacer un registro de usuario en la nueva tecnología” y se asignaría un time-box limitado, el otro “realizar la funcionalidad” y otra de “refactorizar ⁽¹⁾ la funcionalidad”.

Es posible que nos encontremos con historias demasiado pequeñas, como arreglar algún bug o corregir literales. Detectaremos una historia demasiado pequeña enseguida, ya que el equipo de producción dirá que es más rápido hacerla que escribirla.

Hay algunas historias que hacen referencia a todo el proyecto, por ejemplo “La web tiene que ser rápida”. Esto no es una historia, es una constraint y las constraints son condiciones que deben cumplir todas las historias que se desarrollen y en general todo el proyecto. “Ninguna página de la web tiene que tardar más de tres segundos en cargarse” sería un buen ejemplo de constraint.

Las constraints están presentes en todo el proyecto y las deben tener siempre en cuenta el equipo de producción antes de finalizar una historia de usuario.

6) Testeable

¿Cómo sabemos si una historia está acabada si no se puede probar? Una historia debe tener ciertas condiciones de validación que justifiquen que la historia está acabada. Una historia se tiene que poder probar que funciona.

Los beneficios de las historias de usuario

Las historias de usuario comportan, entre otros, estos beneficios principales:

1) Promueven la comunicación verbal

Los seres humanos tienen una gran tradición oral. Cuentos y leyendas han sido transmitidos oralmente entre generaciones, pero en algún momento, en torno al año 1970, se empezó a sentir la necesidad de registrarlo todo por escrito. Hemos cambiado el compartir conocimiento por compartir documentos. Parece que dejar algo por escrito evita desacuerdos y malentendidos, pero no es así.

Comunicación verbal

Si en un restaurante vemos que en el primer plato sirven bacalao o lomo con guarnición, ¿significa que tanto la carne como el pescado vienen acompañados de guarnición? Si ya nos cuesta leer el menú en el restaurante, imaginad la definición de una funcionalidad de un proyecto de producción multimedia.

La palabra debería no se tiene que usar nunca. ¿Qué quiere decir “el sistema debería avisar si el usuario ha introducido un DNI incorrecto”? ¿Significa que el sistema puede no avisar?

Cuando cliente y proveedor usan la comunicación oral, se produce un feedback constante, del que se extrae mucha más información que por escrito. Promueve el aprendizaje y el entendimiento mutuo.

2) Son comprensibles por todo el mundo

Como una historia de usuario está escrita en lenguaje natural, es comprensible tanto por usuarios como por el equipo de producción y por todo el que participe en el proyecto. Promueve la participación y la opinión de todo tipo de perfiles, tanto diseñadores como programadores o comerciales, entre otros. No se restringe la opinión a ninguna persona que lea la funcionalidad.

3) Tienen el tamaño justo para planificar

Ni demasiado grandes ni demasiado pequeñas, una historia de usuario tiene el tamaño justo para que tanto cliente como desarrolladores se sientan cómodos con ella, tanto para definirla como para desarrollarla, probarla o demostrarla al cliente en una demo.

4) Funcionan muy bien en el proceso de producción iterativo

En la gestión ágil de proyectos, donde se trabaja de manera empírica, iterativa e incremental, las historias de usuario son la mejor unidad mínima de funcionalidad para desarrollar. Iteración tras iteración se pueden usar para ir construyendo el proyecto multimedia final.

4.2.Planificación del sprint

Al principio de cada sprint se lleva a cabo la reunión de planificación del sprint. En la primera parte de la planificación, el propietario del producto y el equipo (con la facilitación del scrum master) revisan los elementos de alta prioridad en la pila del producto que el propietario del producto está interesado en que se lleven a cabo en ese sprint. Se tratan los objetivos y el contexto de estos elementos de alta prioridad de la pila de producto y se da al equipo información sobre cuál es la idea del propietario del producto sobre cada elemento.

El propietario del producto y el equipo también fijan la definición de hecho (definition of done o DoD según el término original en inglés).

Esta definición de hecho es un breve documento donde se indican todas las condiciones generales que las funcionalidades tienen que cumplir para ser dadas como hechas.

Esta definición de hecho garantiza la transparencia y la calidad apta para la finalidad del producto y la organización.

La primera parte de la reunión de planificación del sprint se centra en la comprensión de lo que quiere el propietario del producto. De acuerdo con las reglas de Scrum, al final de la primera parte, el propietario del producto (siempre ocupado) puede dejar la reunión a pesar de que tiene que estar disponible (por ejemplo, por teléfono) durante la segunda parte de la reunión. Sin embargo, es bienvenido y se recomienda que también asista a la segunda parte.

La segunda parte de la reunión de planificación se centra en la planificación de tareas detalladas para la forma de aplicar los elementos que el equipo ha decidido asumir. El equipo selecciona los elementos de la pila de producto que se comprometen a ejecutar para el final del sprint, empezando por la parte superior de la pila de producto (en otras palabras, a partir de los elementos que son la máxima prioridad para el propietario del producto) y bajando la lista en orden.

Mientras que el propietario del producto no tiene control sobre la cantidad que el equipo se compromete a poder hacer, sabe que los elementos a los que el equipo se ha comprometido se han extraído de la parte superior de la pila de producto,o sea, los elementos que ha calificado como los más importantes.

El equipo tiene la autoridad para seleccionar también los temas de más abajo de la lista en consulta con el propietario del producto. Esto sucede cuando el equipo y el propietario del producto se dan cuenta de que un producto de prioridad más baja se adapta fácilmente y de forma más apropiada a las cuestiones de alta prioridad que se harán en este sprint.

La reunión de planificación del sprint se limita a cuatro horas para un sprint de cuatro semanas y a dos horas para un sprint de dos semanas. Por eso, el equipo tiene que ayudar al propietario del producto mediante la estimación del tamaño de las historias antes de la reunión de planificación de sprint. Un equipo basa sus compromisos en sus velocidades en el pasado. Si un equipo es nuevo, en la tecnología o el campo, no se pueden tener velocidades fiables hasta que no hayan trabajado juntos durante tres o cuatro sprints.

Una vez determinada la capacidad de los equipos disponibles, el equipo empieza con el primer elemento de la pila de producto –en otras palabras, lo que el propietario del producto ha fijado con más alta prioridad– y se descompone en tareas individuales, que se registran en la pila del sprint o sprintbacklog. Tal como se ha mencionado, el propietario del producto tiene que estar disponible durante la segunda parte (por ejemplo, a través del teléfono) de forma que las aclaraciones y decisiones en cuanto a los enfoques alternativos sean posibles. Al final de la reunión, el equipo ha elaborado una lista de tareas con las estimaciones (en general en horas o fracciones de un día). La lista es un punto de partida, pero pueden salir más tareas que se desconocían a medida que el equipo avanza durante el sprint.

Scrum anima a que los equipos de trabajo sean polivalentes, en lugar de solo trabajar en lo que dice su etiqueta, es decir, un programador solo programa o un probador solo hace pruebas. En otras palabras, los miembros del equipo siguen el principio de ir donde haya trabajo y ayudar como sea posible. Si hay muchas tareas de prueba, todos los miembros del equipo pueden ayudar a probar. Esto no implica que todo el mundo sea generalista, sin duda, algunas personas son muy habilidosas en la prueba (y así sucesivamente), sino que el equipo ha demostrado ser un enfoque valioso para el intercambio de conocimientos.

Dicho todo esto, hay momentos en los que solo un miembro del equipo puede desempeñar una determinada tarea, puesto que perdería demasiado tiempo que lo hiciera otro miembro o no es posible que otros aprendan a hacerlo en un tiempo razonable (quizás es la única persona con alguna habilidad artística para dibujar). En este caso, es posible pero hay que tratar de evitarlo al máximo dado que dependemos de un único miembro del equipo para desempeñar un determinado trabajo (puede ser necesario preguntarse si las tareas planificadas totales de dibujo que este miembro del equipo debe desempeñar son factibles dentro del corto sprint).

Uno de los pilares de Scrum es que, una vez el equipo acepta su compromiso, las adiciones o cambios tienen que ser aplazados hasta el próximo sprint. Eso significa que, si en mitad del sprint el propietario del producto decide que hay un elemento nuevo que le gustaría que el equipo trabajara, no puede introducir el cambio hasta el inicio del siguiente sprint. Si una circunstancia externa parece que cambia de forma significativa las prioridades, y significa que el equipo estaría perdiendo el tiempo si continuara trabajando, el propietario del producto o el equipo pueden acabar el sprint. El equipo se detiene y se inicia una nueva reunión de planificación del sprint. El coste de hacerlo (lo que se llama romper un sprint) es en general grande y sirve como un desincentivo para que el propietario del producto o el equipo recurran a esta decisión drástica.

Al seguir estas reglas de Scrum, el propietario del producto gana dos cosas:

1) En primer lugar, tiene la confianza de saber que el equipo ha alcanzado un compromiso para completar un conjunto realista y claro de las tareas que ha elegido. Con el tiempo, un equipo puede llegar a ser muy habilidoso en la elección y la entrega de un compromiso realista.

2) En segundo lugar, el propietario del producto llega a introducir los cambios que le gustan en la pila de producto antes del comienzo del siguiente sprint. En ese momento, las adiciones, supresiones, modificaciones y reordenaciones de la preferencia de todo esto son posibles y aceptables. Aunque el propietario del producto no tiene privilegios para modificar los elementos que han sido seleccionados en el sprint actual, sí puede introducir cambios en aquellas funcionalidades que aún no han entrado en el sprint. Es decir, el propietario del producto tiene que estar siempre a un sprint de distancia por delante del equipo de desarrollo para introducir cualquier cambio. De este modo, se acaba con el estigma en torno al cambio, cambio de dirección, cambio de requisitos o simplemente cambiar de opinión.

4.3.El daily stand-up

Una vez el sprint ha empezado, el equipo se involucra en otra de las claves de las prácticas de Scrum, el daily stand-up. Se trata de una breve reunión (de quince minutos más o menos) que tiene lugar cada día de trabajo en el mismo sitio y a la misma hora. Todos los formantes del equipo asisten a ella. Recibe su nombre por el hecho de que, por ser breve, se recomienda que todo el mundo permanezca de pie. Es la oportunidad del equipo para informar a los demás de su avance y obstáculos. En el daily scrum, uno por uno, cada miembro del equipo informa de tres (y solo tres) cosas a los demás miembros del equipo:

1) qué han sido capaces de lograr tener hecho desde la última reunión;

2) lo que están planificando tener para acabar antes de la próxima reunión e informar de si se produce un cambio en la estimación inicial para completar la tarea; y

3) todos los obstáculos que se encuentran en el camino.

Tened en cuenta que el daily scrum, no es una reunión para informar a un gestor del avance, es un tiempo en el que un equipo autoorganizado comparte con los demás lo que está pasando para ayudar a coordinar el trabajo entre todos para optimizar la probabilidad de cumplir los compromisos.

Alguien toma nota de los impedimentos y el scrum master es responsable de ayudar a los miembros del equipo a resolverlos. No hay debate en el daily scrum, solo la presentación de informes en forma de respuestas a las tres preguntas. Si se requiere tratar un punto, el debate se lleva a cabo inmediatamente después del daily scrum, en una reunión de seguimiento, habitualmente solo con las personas a las que les afecta de forma directa en su trabajo. Esta reunión de seguimiento es un acontecimiento común donde el equipo se adapta a la información que escuchó en el daily scrum , en otras palabras, otra reunión de inspección y adaptación del ciclo.

En general, se recomienda que los gerentes u otras personas que ocupen puestos de autoridad no asistan al daily scrum, o, si lo hacen, no permitirles intervenir. Se corre el riesgo de que el equipo se sienta controlado –con la presión de reportar avances importantes todos los días (una expectativa poco realista) y se inhibe sobre el informe de problemas– y tiende a socavar la autogestión del equipo e invitar a la microgestión.

4.4.Actualización de la pila del sprint y gráfico de sprint burndown

Tal como ya hemos comentado, todos los días los miembros del equipo se reúnen y, entre otros, actualizan su estimación de la cantidad de tiempo que queda para completar su tarea actual en la pila del sprint. Después de esta actualización, alguien suma las horas que quedan para el equipo en conjunto y se representa en el gráfico de sprint burndown.

Este gráfico muestra todos los días una nueva estimación de la cantidad de trabajo (medida en horas de la persona o los puntos relativos) y se mantiene hasta que las tareas del equipo se hayan acabado. Idealmente, es un gráfico de una curva que desciende y que se encuentra en una trayectoria para llegar a cero esfuerzo pendiente en el último día del sprint. Por eso, se llama un diagrama de crema (de tareas). Y aunque a veces se ve bien, a menudo no es así, esta es la realidad del desarrollo del producto. Lo importante es que muestra al equipo su progreso hacia la meta, no en términos de cuánto tiempo se empleó en el pasado (un hecho irrelevante en términos de progreso), sino en términos de la cantidad de trabajo que sigue habiendo en el futuro, lo que separa al equipo de su objetivo. Si la línea no se quema, es decir, la gráfica de trabajo por completar frente al tiempo que falta no tiene una pendiente negativa, sino que decrece hacia la finalización a mitad del sprint, el equipo puede necesitar ejecutar algún procedimiento para corregir la situación:

1) cambiar el enfoque del trabajo o eliminar los obstáculos para aumentar la velocidad;

2) buscar ayuda de alguien de fuera del equipo;

3) reducir el alcance del trabajo;

4) abortar el sprint si se considera que no es posible seguir avanzando.

4.5.El refinamiento del producto Cartera

Una de las actividades menos conocidas, pero más valiosas en Scrum, es que en cada sprint una pequeña parte del esfuerzo la tendría que dedicar el propietario del producto y el equipo al refinamiento (o grooming) de la pila de producto. Esto incluye:

1) el análisis detallado de los requisitos;

2) la división de elementos de grandes dimensiones en otros más pequeños;

3) la estimación de los elementos nuevos;

4) la reestimación de los elementos existentes.

Basta una reunión regular semanal con el propietario del producto. Esta actividad no es el refinamiento de los elementos seleccionados por el sprint actual, sino que es por los elementos por el futuro, muy probablemente en los próximos uno o dos sprints. Con esta práctica, la planificación de sprint llega a ser relativamente simple, ya que el propietario del producto y el equipo Scrum inician la planificación con un claro, muy analizado y calculado conjunto de elementos.

Una señal de que este proceso de refinamiento no se está llevando a cabo (o no se está haciendo bien) es que la planificación de sprint incluya preguntas importantes, el descubrimiento de nuevas historias o confusión sobre las existentes.

4.6.Finalizando el sprint

Uno de los principios básicos de Scrum es que la duración del sprint no se extiende más allá de la fecha asignada, independientemente de si el equipo ha completado el trabajo al que se ha comprometido. Los equipos normalmente acostumbran a comprometerse a más de lo que pueden realizar en los primeros sprints y no cumplen con los objetivos. No obstante, en el tercero o cuarto sprint, un equipo normalmente se ha dado cuenta de lo que es capaz de entregar y cumple los objetivos.

Se anima a los equipos a tomarse un periodo de tiempo para los sprints (por ejemplo, dos semanas) y que no lo cambien. Una duración coherente ayuda al equipo a aprender lo mucho que puede conseguir, lo que ayuda tanto a la estimación como a la planificación a largo plazo. También ayuda al equipo a conseguir un ritmo de su trabajo, por lo que a menudo se califica como el latido del equipo en Scrum.

4.7.Revisión del sprint

Una vez finalizado el sprint, se lleva a cabo la revisión de este, donde el equipo revisa el sprint con el propietario del producto. Esto es a menudo mal etiquetado como la demo, pero este término no refleja la verdadera intención de esta reunión.

Una idea clave en Scrum es inspeccionar y adaptar. Se hace para ver y saber lo que está pasando y después evolucionar en función de la información, en la repetición de ciclos.

La revisión del sprint es una actividad de inspección y adaptación para el producto. Es un tiempo para que el propietario del producto y las principales partes interesadas aprendan lo que está pasando con el producto y con el equipo (es decir, una revisión del sprint) y para que el equipo sepa qué está pasando con el producto y el mercado. En consecuencia, el elemento más importante de la revisión es una conversación en profundidad y la colaboración entre el equipo y el propietario del producto para conocer la situación, obtener consejos y así sucesivamente. La revisión incluye una demostración de lo que el equipo ha construido durante el sprint, pero si el enfoque de la revisión es una demostración más que conversación, hay un desequilibrio.

Están presentes en esta reunión el propietario del producto, los miembros del equipo y el scrum master, además de los clientes, las partes interesadas, expertos, ejecutivos y cualquier otra persona interesada.

Una guía de Scrum es que se tiene que gastar el menor tiempo posible en la preparación para la revisión del sprint; Scrum sugiere no más de dos horas. Es simplemente una demostración de lo que se ha construido. Durante la revisión, cualquiera es libre de plantear preguntas y dar su opinión.

4.8.Retrospectiva del sprint

La revisión del sprint implica inspeccionar y adaptar en relación con el producto. La retrospectiva del sprint, que sigue a la revisión, implica revisar y adaptar en relación con el proceso.

Esta es una práctica que algunos equipos se saltan, lo que es inaceptable, ya que la autoorganización requiere de la reflexión frecuente ordinaria prevista por la retrospectiva. Es el principal mecanismo para la visibilidad que Scrum proporciona en las áreas de posible mejora con objeto de convertirlo en resultados. Es una oportunidad para que el equipo Scrum trate lo que funciona y lo que no funciona y ponerse de acuerdo en los cambios que desean intentar.

El scrum master puede actuar como un facilitador eficaz para la retrospectiva, pero puede ser mejor encontrar un ajeno neutral para facilitar la reunión.

Un buen enfoque es que los scrum masters faciliten retrospectivas de los demás, lo que permite la polinización cruzada entre los equipos.

La retrospectiva del sprint

Una forma sencilla de estructurar la retrospectiva del sprint es poner cuatro columnas en una pizarra con las etiquetas siguientes:

1) ¿qué ha salido bien?

2) ¿qué podría haber sido mejor?

3) ¿qué cosas hay que probar?

4) ¿qué problemas hay para escalar?

Y después ir dando vueltas por la sala y que cada persona añada uno o más elementos a las listas: ideas y experiencias, positivas y negativas, correspondientes a cada una de las columnas. Dado que muchos conceptos se repetirán, se pueden añadir marcas a las repetidas, de forma que los elementos comunes queden claros.

Después, el equipo busca las causas subyacentes y se llega a unas conclusiones y a unas acciones de mejora, de acuerdo con un pequeño número de cambios para tratar en el próximo sprint, junto con el compromiso de revisar los resultados en la cercana retrospectiva de sprint.

Una práctica útil al final de la retrospectiva es que el equipo etiquete cada uno de los elementos de cada columna con las siguientes etiquetas:

• S si es causada por Scrum (en otras palabras, sin Scrum no estaría pasando);

• E si está expuesto por Scrum (en otras palabras, estaría sucediendo con o sin pila de producto, pero Scrum lo da a conocer al equipo); y

• N si no está relacionado con Scrum (como el clima).

Habitualmente, el equipo puede anotar una gran cantidad de S en lo que funciona bien junto al tablero y una gran cantidad de E en lo que podría funcionar mejor, lo que es una buena noticia. Si lo que podría funcionar mejor está en la lista más larga, es un buen resultado, puesto que el primer paso para resolver los problemas subyacentes es hacerlos visibles y Scrum logra sacar a la luz los problemas ocultos de la organización.

4.9.Actualización de la pila de producto y product burndown

En este punto, algunos elementos se han acabado, algunos se han añadido, algunos tienen nuevas estimaciones y algunos han caído de la meta fijada. El propietario del producto es responsable de asegurar que estos cambios se reflejen en la pila de producto.

Además, Scrum incluye un gráfico llamado product burndown que muestra el progreso hacia la fecha de lanzamiento. Es análogo al gráfico de sprint burndown, pero está en el nivel más alto de los elementos (historias) en lugar de tareas del sprint. Como propietario de producto novel, es poco probable que sepa por qué o cómo crear esta tabla, así se trata de otra oportunidad para que un Scrum master ayude al propietario del producto.

4.10.Siguiente sprint

Después de la revisión del sprint, el propietario del producto puede actualizar la pila de producto con cualquier nueva idea. En este punto, el propietario del producto y el equipo están listos para empezar otro ciclo de sprint. No hay tiempo de inactividad entre sprints.

Los equipos van normalmente a partir de una retrospectiva de sprint, una tarde, en la próxima reunión de planificación de sprint a la mañana siguiente o después del fin de semana, por ejemplo.

Uno de los principios del desarrollo ágil es el ritmo sostenible, y solo por las horas de trabajo regulares en un nivel razonable los equipos pueden seguir este ciclo indefinidamente.