Scrum: guía fundamental

Introducción a Scrum

Scrum es el método ágil de desarrollo de Software más utilizado del mundo. Se presentó por primera vez 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. Aquellas organizaciones que consiguen usarlo con éxito, consiguen mejoras de 4 a 10 veces en productividad, time-to-market y competitividad.

Para que Scrum tenga éxito es necesaria la mejora de la transparencia, la reducción de los ciclos de desarrollo y la mejora de la innovación.

Scrum ha evolucionado significativamente para adaptarse a nuevos retos e ideas durante los últimos 20 años. Las últimas actualizaciones de la guía de Scrum lo han hecho menos prescriptivo y más flexible, orientado sobre todo a generar valor a través del enfoque en el desarrollo de producto. A pesar de todo, muy pocas compañías consiguen vencer sus propias resistencias e impedimentos para llegar a obtener todos los beneficios de Scrum.

A pesar de que Scrum se presentó años antes, ha crecido junto al movimiento Agile, surgido de la redacción del Agile Manifesto en 2001.

El modelo Waterfall

La realidad de la industria del Software en ese momento era lamentable. Proyectos que se eternizaban, no cumplían expectativas y terminaban costando varias veces más de lo que se había presupuestado. Es por ello que varias personas, incluyendo a lo creadores de Scrum decidieron unirse y publicar un manifiesto para intentar cambiar las cosas. Seguramente no imaginaban el impacto que ello tendría más de 20 años después.

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 proyectos de desarrollo que han terminado en desastre. Por ejemplo, en Andalucía (España) el gobierno invirtió unos 45 millones de euros en el desarrollo del Software para gestión del sistema sanitario Diraya. Tuvo que tirarlo y hacerlo de nuevo antes de que estuviera verdaderamente en funcionando.

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. Estaban liderados por el creador de eXtreme Programming, Kent Beck.

Entre las personas que se encontraban allí, había diferentes voces que pretendían cambiar la forma en que se realizaban los proyectos y productos de software. No solamente los creadores de Scrum. También personas muy reconocidas de la industria del Software y expertos que promulgaban metodologías alternativas a la gestión de proyectos en cascada (Waterfall).

El problema residía en que esta forma de trabajar habitualmente llevaba a grandes fracasos con un coste de millones de dólares. El sistema de ciclos o fases en el que se finalizaba un diseño previo a la implementación, se desarrollaba todo el Software antes de ser testeado y se testeaba antes de hacerlo en el entorno final de trabajo hacía que pequeños problemas terminaran amplificándose y multiplicándose en el tiempo

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 presentaron Scrum en una conferencia de desarrollo de Software. Utilizando un paper publicado en 1986 titulado “The new new Product Development Game” destilaron las reglas del framework 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. Sin embargo, los profesionales que lo utilizaban no tuvieron una guía oficial hasta bien entrado el nuevo milenio.

Cuando en 2011, Ken Schwaber y Jeff Sutherland publicaron 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 enseñaba.

Desde entonces evolucionado para recoger la forma en que se utiliza en la práctica. Desde 2011 la guía de Scrum ha sufrido tres grandes cambios: en 2013, 2016 y 2020. Las veremos en el siguiente punto.

¿Scrum o SCRUM?

Para entender los orígenes de Scrum, merece la pena leer el paper original. En el trabajo de investigación original en el que se describía la forma de trabajar en empresas como 3M, Xerox o Dyson. Esa forma de trabajo se describió como Scrum porque a los autores les recordaba a la forma que los equipos de Rugby tienen de jugar el balón en un partido.

Una de las cuestiones que aclaró la guía de Scrum (Melèe) es el nombre: 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 no han tenido la oportunidad de adaptarse.

El lenguaje es importante.

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 cuáles son las reglas, los eventos (Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective), responsabilidades (Scrum Master, Product Owner y Development Team) y artefactos (Product Backlog, Sprint Backlog e Incremento). Esta guía se puede leer aquí en Castellano. En los próximos párrafos veremos cuáles son los detalles de cuáles son cada una de las mecánicas que subyacen a Scrum.

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 refinement. 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 y de nuevo se simplificó el lenguaje.

Tras la actualización de 2017, se aclaró 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, indica la excelente relación de los creadores de Scrum y su compromiso hacia este marco de trabajo.

Actualización de 2020

La última actualización de la guía oficial de Scrum se produjo en 2020. En esta versión se ha simplificado aún más el lenguaje, se han eliminado prácticas prescriptivas y se ha reforzado la unidad del equipo Scrum como un solo grupo, eliminando el Development Team. También se ha introducido el Product Goal y el Sprint Goal y la Definition of Done se han convertido en compromisos del Sprint Backlog y el Incremento, respectivamente.

Tras leer la guía podemos tener la sensación -cierta- de que el framework por sí solo no aporta mucho. Ese es el caso de las implantaciones amateur de las que hablaba anteriormente. Son aquellas que, tras una lectura rápida y ver un par de videos, se abrazan a Scrum como la solución de todos sus problemas sin tener en cuenta la complejidad de sus organizaciones. Es un error.

El objetivo no debe ser otro que la agilidad, y el framework no es el único camino para conseguirla. A pesar de su comparación en ocasiones con la producción industrial, Scrum no es sino un reflejo del empirismo y un marco de trabajo listo para funcionar en entornos complejos.

Empirismo

El Empirismo o control empírico de procesos es el mecanismo principal que subyace a Scrum y el que hace que sea tan poderoso. Detrás de un nombre enrevesado hay algo mucho más simple, y no es más que hacer transparente el trabajo que estamos realizando, inspeccionarlo a intervalos regulares y adaptar nuestra táctica para corregir el rumbo. Transparencia, inspección, adaptación.

La razón de que sea tan poderoso es debido a que nuestro trabajo habitualmente se mueve dentro del dominio de lo complejo, esto es, un entorno donde existen muchas variables que no podemos manejar.

Todos estamos más que acostumbrados a ese entorno porque es lo más parecido a nuestra vida real. Detrás de nuestra sensación de control, lo que hay no es más que un ciclo continuo de transparencia-inspección-adaptación que nos permite lidiar con los problemas del día a día.

Veámoslo con un caso práctico.

Scrum: Un caso práctico

Optipayment 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.

Optipayment tiene un equipo de 10 desarrolladores con diferentes perfiles que se encargan de diferentes partes del producto. Estos desarrolladores no son solo programadores, sino que comprenden a todas las personas necesarias para realizar nuevas mejoras al producto: Diseñadores, testers o personas de infraestructura. Trabajando juntas en un solo equipo.

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 podría llevar 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, asegurandose de que todos los elementos de la lista están alineados con una meta a tres meses: El Product Goal . Él es el único que decide sobre el orden del Product Backlog y es responsable de decidir hacia donde debe ir el producto.

El flujo de un Sprint

El equipo de Optipayment hace una entrega de producto cada cuatro semanas. Al principio de la primera semana, los Developers 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. El Sprint Goal.

Pasamos a la siguiente parte. Los Developers miran nuestra lista de requerimientos, que está actualizada y ordenada en función del valor de negocio y ha sido previamente refinada con todo el equipo Scrum y decide qué porción creen que pueden completar en cuatro semanas atendiendo a la meta para esa iteración. Una vez decidido el trabajo a realizar, el Scrum Team se encarga de 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 y el Sprint Goal completan una lista (Sprint Backlog) en la que el equipo trabajará y será el plan de cuatro semanas. También se encargarán de mantener actualizada 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 el progreso hacia la meta del Sprint y actualizar su plan de trabajo para el día. Los miembros del equipo informan a otros miembros de impedimentos y problemas. Juntos deciden cómo pueden resolverlos.

Trabajo con negocio

Cuando el equipo termina el trabajo sobre los elementos del Sprint Backlog, los va mostrando al Product Owner y así poder continuar con el plan en que estaban inicialmente. El Product Owner proporciona feedback y ayuda a validad el trabajo terminado

La persona que ejerce la responsabilidad de Product Owner, trabaja con el equipo para informarles de la situación con respecto al producto. Todos los requerimientos terminados, una vez que están integrados con el resto del producto se consideran el Incremento. El objetivo de la iteración es cumplir con la meta del Sprint teniendo un Incremento terminado.

En ocasiones, descubrimos que para cumplir con la meta que nos habíamos propuesto, no es necesario completar todos los elementos que habíamos escogido al comienzo del Sprint y hay maneras más inteligentes de llegar. O surgen imprevistos que nos obligan a cambiar nuestro plan. Eso está bien porque Scrum permite abrazar los cambios.

Al final del Sprint, el Product Owner invita quien tenga un interés en el producto (Stakeholders) al Sprint Review. Los Stakeholders dan feedback al equipo sobre el Incremento y preguntan cualquier duda que tengan. Después ponen en común cuál 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, llega le retrospectiva. el Scrum Team revisa como ha ido el Sprint y toma decisiones para el siguiente. Esto marca el final del Sprint e inmediatamente otro Sprint comienza, siguiendo el mismo proceso descrito arriba.

Responsabilidades en Scrum

Para que Scrum pueda tener éxito, es necesario que existan personas que tengan distintas responsabilidades dentro del proceso. Scrum no dicta que éstas responsabilidades tengan que ser necesariamente ejercidas por una sola persona o que una persona no pueda tener varias reponsabilidades a la vez, sin embargo este enfoque tiene sus riesgos. ¿Qué diferencia a un Scrum Master/Product Owner de un Project Manager? ¿Cual es el mayor interés de un Developer que ejerce de Product Owner?

En Scrum no existe gestión de proyectos. Las responsabilidades quedan potencialmente distribuidas entre varias personas. Si no prestamos atención a que muchas veces éstas presentan conflictos entre sí, podemos caer en asignar todo el poder a un solo miembro del equipo Scrum haciendo que, por mucho que usemos los nombres “ágiles” no hagamos más que reproducir la manera tradicional de trabajar y pasado un tiempo observaremos que Scrum no nos aporta ningún valor. Cero.

Es por ello que conocer y tener éstas responsabilidades ejercidas de manera profesional es fundamental para el éxito de cualquier iniciativa en la que usemos Scrum. Dicho de otra manera: las personas que trabajan en un Scrum Team tienen que conocer bien las herramientas con las que trabajan.

Scrum Master

El Scrum Master se encarga de asegurar el proceso Scrum, que éste se lleva a cabo correctamente y de facilitar la ejecución de las reglas y sus mecánicas, siempre atendiendo a los tres pilares del control empírico de procesos: Transparencia, inspección y Adaptación. Además, se encarga de eliminar impedimentos que puedan afectar a la entrega de producto. También se encarga de guiar al resto del equipo Scrum cuando lo necesitan y 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 cumple dos funciones dentro del marco de trabajo. La primera es gestionar el proceso Scrum y la segunda es ayudar a eliminar impedimentos. Ambas sirven para que el Scrum Team sea más efectivo. Veámoslas.

Gestionar el Proceso Scrum

El Scrum Master es el encargado de mantener Scrum al día, de proporcionar coaching, mentoring y formación a la organización en caso de que lo necesite y de velar porque Scrum favorezca la entrega de valor.

El Scrum Master no impone. En su lugar, adopta un enfoque pedagógico guiando al Scrum Team y a la organización a mejorar a lo largo del tiempo introduciendo pequeños cambios que hagan la entrega de producto más fácil, más ágil y más resiliente.

Esta manera de trabajar se conoce como Servant Leadership.

Ayudar a eliminar impedimentos

Esta función del Scrum Master se traduce en la necesidad de ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo en la organización. Afectan mucho al éxito de Scrum pero aún más importante, impiden a la organización entregar más valor.

Hay que remarcar que estos impedimentos no siempre son del equipo, sino de la organización, y donde el Scrum Master aporta es a nivel organizativo. No reparando teclados u organizando vacaciones para el resto de sus compañeros.

En ocasiones encuentro Scrum Masters que se quejan de la imposibilidad de hacer Scrum debido a que la organización no facilita su introducción adecuada a lo largo y ancho de la misma. Es precisamente al contrario. El Scrum Master es responsable de velar porque Scrum se lleve adelante y se pueda facilitar la implementación, creando y cambiando los espacios dentro de la organización para que esto ocurra. El dilema del Scrum Master es cómo influenciar sin tener la autoridad.

Poseer habilidades de comunicación efectiva, escucha activa y resolución de conflictos es por tanto básico para tener éxito como Scrum Master.

Los Scrum Masters y el tiempo libre

Es común echar cuentas y pensar que si el Scrum Master tiene que asegurarse de que existen una serie de eventos durante un Sprint y la mayoría de los días el evento principal, el Daily Scrum, dura apenas 15 minutos podamos pensar: “¿Qué hace un Scrum Master el resto del tiempo?”

Un buen Scrum Master tiene tiempo libre y está fuera de la vorágine del día a día. Precisamente esto le permita enfocarse en problemas de mayor calado que afectan a la organización a nivel global, en lugar de encargarse de actualizar el Scrum Board para reportar, o hacer el trabajo del Product Owner.

El trabajo de eliminar impedimentos en una organización 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. Lamentablemente cuando surgen problemas y los Scrum Masters no están disponibles porque están ocupados llevando a cinco equipos a la vez, los problemas no se resuelven.

Product Owner

La labor del Product Owner es maximizar el valor del producto que entregamos usando Scrum. El Product Owner gestiona todo el flujo de valor del producto a través del Product Backlog, el Product Goal y el Refinamiento, 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í como un solo Product Backlog.

El Product Owner es responsable de maximizar el valor del producto en el que el Scrum Team trabaja. Esto, que se expresa fácilmente, es una tarea complicada, tal y como veremos a continuación.

Gestionar prioridades

El Product Owner se ha entendido tradicionalmente como un gestor de requisitos o un cliente que se encarga de gestionar el Product Backlog. Es mucho más que eso. El Product Owner tiene la responsabilidad de gestionar los presupuestos, de contratar al equipo de desarrollo y de explicar a los stakeholders cuál es el valor que produce el producto en el que está invirtiendo.

Cada Sprint, el Product Owner hace una inversión en desarrollo del producto que tiene que producir valor. Tiene que rendir cuentas a la organización para explicar por qué las decisiones que ha tomado son las decisiones que mayor valor pueden aportar a la organización.

Representar al negocio

Cuando el Product Owner es alguien que conoce bien el negocio, aportará valor a su trabajo al producto dependiendo de, al menos, dos variables.

La primera es la capacidad de decisión que tiene. Si habitualmente el Product Owner no puede realmente tomar decisiones sin consultar con otra persona no es un Product Owner real y debe, o ser sustituido por la persona que toma las decisiones, o ser investido para tomarlas por sí mismo. Hay que recordar que esto no es un capricho de los fanáticos de Scrum, sino una manera de maximizar la inversión realizada en el desarrollo de producto y reducir los riesgos inherentes a los mismos.

La segunda es su conocimiento técnico del producto en sí mismo. Un Product Owner que no conoce o que conoce vagamente las tripas del producto en el que el equipo está trabajando siempre estará condicionado por ese desconocimiento. Por tanto, la inversión de tiempo del Product Owner en conocer a fondo aquello que gestiona es necesaria para asegurar esa maximización de valor.

Emprender en la organización

Es en la faceta de emprendedor dentro de la organización donde realmente el Product Owner puede aportar valor al negocio. Un Product Owner en esta faceta es un Product Manager ágil, capaz de medir el valor generado y utilizar la flexibilidad de entregar cada Sprint para incrementar ese valor.

Merece la pena apuntar aquí que cuando Sutherland y Schwaber desarrollaron Scrum pensaron en darle a esta responsabilidad el nombre de Agile Product Manager. Finalmente optaron por el nombre de Product Owner para reflejar que debía ser un verdadero propietario del producto y no un mero intermediario del mismo.

Developers

Habitualmente un equipo Scrum tiene 10 miembros o menos. Los Developers son aquellos que se encargan de desarrollar el producto. Se autoorganizan y deciden cuál 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 la pertenencia al equipo, y este solo hay uno, independientemente de cuántos miembros tenga el Scrum Team y cuáles sean sus roles internos. Dicho de otra manera, el Scrum Team actúa como una unidad, no como la suma de sus partes.

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 y fomentar un ambiente de colaboración y responsabilidad sobre su trabajo.

Crean incrementos terminados

El equipo de desarrollo se encarga de crear un incremento terminado a partir de los Product Backlog items seleccionados durante el Sprint Planning, siempre en la dirección marcada por el Sprint Goal. Independientemente del número de personas que forman parte del Scrum Team, rinden cuentas como uno solo.

Habitualmente, también es un equipo cross-funcional, capaz de generar un incremento terminado de principio a fin, sin otras dependencias externas. El aspecto más importante del equipo de desarrollo es que se autoorganiza y se autogestiona.

Es importante reforzar la idea de que un Developer no es necesariamente un desarrollador de Software. Puede ser cualquier persona que sea necesaria para conseguir un incremento de producto, como un especialista en pruebas. Esto se hace más visible en productos que no son de Software.

Gestionan el Sprint Backlog

Como parte de su trabajo, se encargan de gestionar, actualizar y mantener el Sprint Backlog de acuerdo a la evolución de sus planes iniciales durante el Sprint. Durante el Daily Scrum identifican el progreso hacia el Sprint Goal y modifican su plan para el siguiente día de trabajo.

El equipo de desarrollo es responsable de contratar al Scrum Master.

Artefactos en Scrum

Para que Scrum funcione y sea efectivo, todos los artefactos y eventos sirven al empirismo: Transparencia, inspección y adaptación. Sin transparencia no tenemos nada y aquí entran en juego los artefactos (elementos físicos) que nos ayudan a mantenerla constante a lo largo de todo el ciclo de vida del producto.

Tenemos tres artefactos en Scrum: El Product Backlog, el Sprint Backlog y el Product Increment.

Product Backlog

El Product Backlog es un inventario que contiene cualquier tipo de trabajo que hay que hacer en el producto, como requerimientos, casos de uso, tareas y dependencias. Todas ellas están representadas en el Product Backlog, que es la principal fuente de información sobre el producto en Scrum.

El Product Backlog es una lista en cualquier formato que contiene todos los requerimientos a implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con los distintos Stakeholders de la organización, su propia investigación y las necesidades de los usuario; refleja el estado real del trabajo pendiente.

El Product Backlog está gestionado por el Product Owner y puede contener cualquier tipo de tarea en cualquier formato. Su única condición es que esté ordenado, colocando arriba los items que tienen más valor en ese momento.

Al comenzar a utilizar Scrum, no es necesario tener una lista completa y exhaustiva de todos los requerimientos, tal y como se hace en los enfoques tradicionales de gestión de proyectos. Es posible y recomiendo empezar con los dos o tres requerimientos más urgentes e ir añadiendo más conforme se descubren nuevas necesidades del producto.

Típicamente, un Product Backlog contiene diversos tipos de elementos.

1. Funcionalidades
2. Bugs
3. Historias de usuario
4. Tareas técnicas
5. Trabajo de investigación o Spikes
6. Etc…

Historias de usuario

Las historias de usuario son solo una de las maneras de expresar los elementos de un Product Backlog y no son la única forma. Es un error común en organizaciones sin experiencia querer convertir todos los elementos del Product Backlog en historias de usuario.

El formato típico 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)

Plantilla de historias de usuario

Para maximizar el valor de una historia de usuario, es crucial expresarla desde la perspectiva del usuario. Convertir una tarea técnica en una historia de usuario a menudo resulta en descripciones forzadas como: “Como desarrollador, quiero descargar el entorno de desarrollo para poder programar”. Esto no aporta valor.

Las historias de usuario se componen de tres elementos claves: la tarjeta, que describe la historia; la conversación, que aclara los detalles; y la confirmación, que asegura que todos comprenden el valor que proporciona.

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
• Habilitar la opción de hacer login con cuentas externas
• Asegurar que la app cumple con los criterios de accesibilidad del W3C.
• 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

Product Goal

Como parte de la mejora de la transparencia, la guía de Scrum en 2020 incluyó un nuevo Commitment, el Product Goal.

El Product Goal es una meta a largo plazo que puede abarcar varios Sprint. Los elementos del Product Backlog están alineados con el Product Goal y éste sirve para enfocar el Scrum Team en metas a largo plazo. Metas que van más allá de un solo Sprint.

A pesar de que el Product Backlog está centrado en el Product Goal no está limitado por el mismo, ya que puede haber otros elementos que no se correspondan con el Product Goal. Sin embargo solo puede existir un Product Goal en un momento dado y el Scrum Team tiene que completarlo o abandonarlo antes de introducir uno nuevo.

Sprint Backlog

Una vez que se decide en el Sprint Planning, todo el trabajo que el Scrum Team ha seleccionado para hacer durante el siguiente Sprint pasa, junto con el plan para entregarlo y el Sprint Goal al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo del Sprint y está gestionado por los Developers. Su propósito es mantener la transparencia dentro del Sprint.

El Sprint Backlog nos proporciona una visión del trabajo a realizar durante el Sprint actual. Está gestionado por los Developers. Se encargan de mantenerlo actualizado y transparente durante toda la iteración, especialmente a través de los Daily Scrums.

Tras evaluar el Product Backlog, el equipo de desarrollo decide 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 que facilitan la implementación de los mismos en un Incremento terminado.

Este artefacto permite entender cuál es la evolución del trabajo durante el Sprint así como hacer un análisis de riesgos. Dado que cada Sprint tiene un Sprint Goal (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 dónde se ha cumplido el objetivo y qué se podría eliminar. Así maximizamos el retorno de la inversión en desarrollo.

Visualización del Sprint Backlog

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 sí y quiénes están trabajando en los mismos. También aquellos que están esperando a desplegarse o están completamente terminados.

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.

Monitorizando el progreso del Sprint

La guía lo deja muy claro: “Un proyecto Scrum es de un solo Sprint de duración. Una liberación de software es la suma de múltiples incrementos (y software previamente desarrollado, si lo hay). Un proyecto Scrum no puede fracasar, solo puede entregar un retorno de inversión inaceptable”. Ken Schwaber. El 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 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 cuál 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 abscisas, 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.

Sprint Goal

De la misma manera que el Product Backlog tiene un compromiso, el Product Goal, el Sprint Backlog tiene el Sprint Goal. La idea detrás de los compromisos introducidos en la guía de 2020 es mejorar la transparencia. En el pasado, podíamos leer un Sprint Backlog y ver 20 o 30 elementos pero no entender por qué existía ese Sprint, ya que la idea del Sprint Backlog no contemplaba una meta clara y tangible.

El uso de un sólo Sprint Goal permite al equipo enfocarse en los retos más allá de aquellos trabajos que están desarrollando en el momento, teniendo en mente un objetivo común para completar durante el Sprint en forma de un incremento terminado.

Incremento

Si Scrum tuviera que ser reducido a una sola cosa, sería entregar una algo terminado y de valor terminado cada Sprint, el Product Increment. El Incremento es la suma de todas las tareas, casos de uso, user stories y cualquier otro elemento en el que se haya trabajado durante el Sprint y que puede ser puesto a disposición de un usuario final en durante o al completar el mismo.

Un incremento es el resultado del Sprint. Es una pieza de producto que aporta un valor de negocio al producto que se está desarrollando porque cumple con el Sprint Goal.

Construir productos de manera ágil es hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del producto: 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, recibiendoo feedback de nuestros usuarios para poder adaptar mejor nuestros planes para el siguiente Sprint.

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 un producto emergente que proporciona soluciones a los usuarios.

Definition of Done

En la actualización de la guía en 2020 también se añadió el compromiso de la Definition of Done al Incremento. De la misma manera que el Product Backlog tiene que tener un Product Goal y el Sprint Backlog un Sprint Goal, el Incremento tiene que tener una Definition of Done.

La Definition of Done es una lista de criterios que tiene que cumplir el producto para considerarlo terminado.

De esa manera evitamos disparidad de opiniones sobre qué significa realmente terminado. Tiene que reflejar la posibilidad de uso por parte de las personas que utilizan nuestro producto.

Las ventajas del desarrollo incremental

El desarrollo incremental es uno de los pilares principales de cualquier iniciativa ágil. 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.

Podemos resumir la agilidad en tres cosas: Capacidad de reaccionar ante los cambios de entorno (p.e. competidores), velocidad de reacción y capacidad de innovación.

La única manera de conseguir agilidad es mediante el uso del ciclo empírico para adaptarnos rápidamente, lo que supone de manera ímplicita usar un enfoque de desarrollo de producto iterativo e incremental.

Eventos en Scrum

Los eventos en Scrum son feedback loops (ciclos de retroalimentación) que permiten la inspección y la adaptación constante del Scrum Team a las necesidades de los usuarios en el producto. Son cinco: Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

Sprint

El sprint es un contenedor para el resto de los eventos de Scrum. Es continuo, es decir, su duración no cambia y se puede interpretar como una medida de ritmo constante que permite reducir complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint fomenta la transparencia y permite inspeccionar y adaptar todos los otros eventos de Scrum.

Todos los eventos de Scrum ocurren dentro de un Sprint. O dicho de otra manera, no hay nada que ocurra fuera de los Sprints.

Scrum prescribe que un Sprint debe durar 1 mes o menos. La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo necesita para generar valor a través de un incremento terminado y el riesgo que el Product Owner considera aceptable para entregar nuevas funcionalidades del producto. El Sprint tiene un tiempo fijo (time-boxed) que sirve al desarrollo iterativo e incremental y no depende de que porcentaje del Sprint Backlog hayamos terminado.

Todo el desarrollo se realiza durante el mismo Sprint durante el mismo se van sucediendo el resto de eventos en Scrum. No hay fases en Scrum, solo Sprints. No existen los Sprints de testing, hardening, release o análisis. Tampoco el Sprint 0.

Contenido de un Sprint

El propósito principal es facilitar la transparencia del proceso. Dado que un Sprint debe durar 1 mes o menos, es común que los equipos Scrum opten por Sprints de dos semanas. Cada equipo Scrum debe encontrar su periodo mínimo necesario para generar valor a través de la entrega de un incremento terminado.

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 ágil.

Scrum 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 solo 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 solo Sprint, siempre orientado a generar el máximo valor. En Scrum, los proyectos se financian cada Sprint y es el Product Owner quien decide dónde 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.

Sprint Planning

El Sprint Planning es un evento que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo. Sirve para inspeccionar el Product Backlog y que el equipo de desarrollo decida un Sprint Goal y seleccione los Product Backlog Items en los que va a trabajar durante el siguiente sprint.

Durante este evento 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. Durante el mismo 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 Goal.

El Sprint Planning se divide en tres partes. En primer lugar se trabaja en construir el Sprint Goal. En la segunda parte de la reunión se trata qué se va a hacer el siguiente Sprint y en la segunda parte, se discute el cómo. Estas tres partes no son secuenciales, sino iterativas. Es normal comenzar con la construcción de un Sprint Goal para luego revisitarlo cuando estamos seleccionando elementos o incluso cuando debatimos el plan para llevarlos a cabo. La labor del Scrum Master es asegurarse de que la reunión existe como parte de Scrum.

Flujo del Sprint Planning

El Sprint Planning es una reunión de planificación y puede durar hasta 8 horas para Sprints de 1 mes. La razón de ser del Sprint Planning es conseguir una meta a corto plazo, el trabajo para conseguir esa meta y un plan inicial para llevarlo a cabo.

El Product Owner propone un Sprint Goal que de coherencia a todos los ítems seleccionados durante la reunión. Los Developers estiman cuantos elementos del Product Backlog creen 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 Scrum Team, entonces se comienza a trabajar en el plan inicial. Desmenuzan 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 tras trabajar el Sprint Goal: Una donde se estima 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 primera parte del Sprint Planning está liderada por el Product Owner y la segunda parte por los Developers con ayuda del Product Owner
• Es responsabilidad del Scrum Master que el evento ocurra, pero no tiene que facilitarlo ni organizarlo él mismo.
• Los Developers tienen la última palabra sobre cuanto trabajo creen que pueden completar en un sólo Sprint así como determinar si algo está listo para empezar a trabajar.

Daily Scrum

El Daily Scrum es una reunión diaria de planificación de 15 minutos en la que los Developers inspeccionan y adaptan su trabajo.

Durante el Daily Scrum, se inspecciona el progreso hacia el Sprint Goal y se adapta el plan con el que veníamos trabajando el día anterior. Se hacen transparentes los impedimentos y se actualizan los artefactos para proporcionar transparencia.

Tiene una duración de 15 minutos. Durante el evento, 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.

Los feedback loops en Scrum son 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 Developers. 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 de Extreme Programming (XP), pero no son lo mismo. El Standup Meeting es una práctica más 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 y que hasta hace poco formaba parte de la guía de Scrum 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 avanzar el Sprint Goal?

Este método, aunque cómodo y claro para equipos que acaban de empezar con Scrum, se adapta una vez que los equipos maduran y las preguntas tienden a ser sustituidas por una adaptación del trabajo a realizar para cumplir con el Sprint Goal.

De hecho, en la actualización de 2020 se eliminaron las preguntas porque al tratarse de una práctica prescrita en el documento oficial, los equipos que utilizan Scrum veían dificultades para abandonarla.

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 un evento que ocurre hacia el final del Sprint, donde el Product Owner presenta a Stakeholders el Incremento terminado para su inspección y posterior adaptación del Product Backlog con los aprendizajes.

Está organizado por el Product Owner y 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 del producto y se trataran varios temas

Por un lado, se revisará el incremento terminado. Se mostrará el producto funcionando en un entorno real y los Stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El producto funcionando ha sido validado previamente por el Product Owner. Se ha encargado de trabajar con el equipo durante el Sprint para asegurarse que cumple con la Definition of Done y efectivamente hacer 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 y deciden si el Product Goal sigue siendo relevante.

No es una demo

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 felicitarse. Es una reunión de trabajo, una de las más importantes ya que sirve para marcar la estrategia de negocio.

No se trata de una demostración, sino un evento estratégico para organización. El software ya ha sido mostrado y validado junto con el Product Owner.

Retrospectiva del Sprint

La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. Durante este evento se hacen transparentes los problemas del equipo y se llega a acuerdos para solucionarlos. También se inspecciona y adapta la Definition of Done.

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 como parte de la autogestión Scrum team

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.

El modelo de cinco pasos

Desde la publicación del libro de Esther Derby y Diana Larsen se ha popularizado el formato de retrospectiva basado en cinco fases:

1. Preparar el ambiente: Un pequeño ejercicio para romper el hielo, junto con el recordatorio de la Prime Directive hacen el comienzo perfecto.
2. 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.
3. 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.
4. Decidir que hacer: De las ideas generadas, se proponen acciones que puedan implementarse en el próximo Sprint. A implementar por todo el equipo.
5. 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.

Usar partes de Scrum ¿Sí o no?

Como reflexión final a esta guía, quiero abordar la idea que muchas organizaciones tienen de usar partes de Scrum, o de adaptar Scrum.

Scrum es sencillo de entender y realmente difícil de aplicar. Una vez que comencemos a utilizarlo empezaremos a descubrir los problemas que tenemos en la organización y tendremos la tentación o de adaptarlo o de utilizar aquellas partes que nos sean más cómodas. Es un error.

El problema reside en la organización y los problemas no son más que impedimentos para que sea más ágil. También podemos pensar que Scrum no funciona porque habla de equipos de 10 personas. Efectivamente escalar Scrum tiene muchos retos pero son abordables sin utilizar un mastodóntico sistema prefabricado.

Es cuestión de voluntad. Esfuerzo. Profesionalidad. Excelencia.

Mucha suerte.

Jerónimo.