Guía de introducción a Scrum: pilares, valores, roles, artefactos y eventos

Scrum es un marco de trabajo liviano donde las personas, los equipos y las organizaciones generan valor a través de soluciones adaptativas a problemas complejos y entornos con requisitos cambiantes. Scrum se caracteriza por suceder en iteraciones llamadas Sprints, con determinados roles de equipo (Scrum Master, Scrum Product Owner y el Equipo de Desarrollo), pero también existen otros elementos esenciales que veremos a continuación.

¿Qué es Scrum y qué no es Scrum?

"Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos" - Guía Scrum

Dentro de los enfoques ágiles de creación de productos, Scrum es un marco de trabajo que hace más de 20 años revolucionó el desarrollo de software y con el tiempo se fue expandiendo a numerosas industrias por su capacidad de entregar valor a los clientes y usuarios y por brindar adaptabilidad a los equipos de producto en contextos complejos donde, por lo general, los diseños predictivos fallan.

El espíritu de Scrum se encuentra en los equipos sólidos, enfocados, multi-funcionales y auto-gestionados que miden los resultados que producen y evalúan constantemente su manera de trabajar.

Toda la base de la práctica de Scrum se puede encontrar en la Guía oficial de Scrum que es un documento detallado que se actualiza en el tiempo. La guía define a Scrum como un marco de trabajo liviano mediante el cual las personas, los equipos y las organizaciones generan valor a través de soluciones adaptativas a problemas complejos. Veamos esta definición identificando que sí es Scrum y que no es Scrum.

Scrum es una manera de trabajar muy útil a la hora de desarrollar productos en contextos complejos, como por ejemplo una campaña de marketing, una identidad corporativa, una solución digital, una aplicación mobile, entre tantas otras opciones.

Scrum es un diseño deliberadamente incompleto y minimalista. Cualquier persona, equipo u organización que desee crear productos de calidad con Scrum deberá complementarlo con técnicas y prácticas específicas de su industria. Scrum te dice qué hacer y no te dice cómo hacerlo.

La generación de valor a través de Scrum implica la creación de un producto de forma tal que lo puedas ver funcionando muy frecuentemente a medida que crece y evoluciona. De esta manera lo podrás inspeccionar y adaptar tanto como consideres necesario.

Este enfoque sólo tiene sentido frente a problemas complejos e inciertos, donde no solo se debe construir un producto, sino también descubrir en paralelo qué producto construir, mediante el uso de las técnicas adecuadas.

Scrum no es un enfoque para gestionar proyectos ni equipos. En Scrum no hay gerentes que dirijan y controlen el trabajo que realizan las personas del equipo. Específicamente en este punto, Scrum se basa en la capacidad de autogestión del equipo, quien tiene completa autonomía para elegir en qué trabajar, cómo hacerlo y quiénes lo hacen dentro del equipo.

A diferencia del modelo secuencial Waterfall o de cascada de gestión de proyectos, Scrum no es una metodología con procesos, subprocesos, inputs y outputs. Scrum no es un método para hacer seguimiento detallado, día a día, de las tareas individuales de los miembros del equipo Scrum.

Cuándo se utiliza Scrum y cómo saber si me conviene aplicar Scrum como método de trabajo

Para empezar a responder esta pregunta se puede utilizar el marco Cynefin de terminología actualizada y originalmente publicado en 2003 por C. F. Kurtz y D. J. Snowden que presentan de una forma muy clara y concisa las diferentes situaciones en las que te puedes encontrar operando, y cuál es, según este enfoque Cynefin, la manera más eficiente de responder a cada una de ellas al tomar decisiones.

Cynefin plantea 5 dominios de complejidad diferentes: claro (simple), complicado, complejo, caótico y confundido.

Cynefin describe el tipo de dominio complejo como uno donde no es posible conocer con anticipación si una determinada solución es acertada, y no puede apelarse a mejores ni buenas prácticas catalogadas para las situaciones frente a las cuales te puedes encontrar simplemente porque no existen. Simplemente, no sabes con anticipación si una determinada solución va a funcionar.

Para poder operar en este tipo de espacio necesitas tener la posibilidad de que haya lugar para la experimentación, el aprendizaje y donde los errores sean de bajo impacto. El producto se construye a medida que se lo va descubriendo.

En este contexto Scrum tiene sentido dado que es un marco, que no solo te permite construir el producto, sino al mismo tiempo descubrir cuál es ese producto que necesitas construir.

En mi experiencia, he identificado tres preguntas claves para poder decidir el uso o no uso de Scrum:

  1. ¿Cuánta seguridad posees de que el producto que tienes en mente va a resolver la necesidad que pretendes resolver?
  2. ¿Cuánta seguridad tienes que la tecnología escogida va a resolver la necesidad que pretendes resolver?
  3. ¿Cuál es la naturaleza del trabajo del equipo: trabajo principalmente mecánico o trabajo principalmente cognitivo?

Sin la seguridad de que el producto que vas a construir o la tecnología que vas a emplear vayan a resolver la necesidad, aunque conozcas con lujo de detalles el alcance del producto, en realidad me animaría a decir que no conoces qué es lo que hay que construir o cómo hay que emplear la tecnología para sí resolver esa necesidad. Aquí tiene sentido utilizar Scrum.

Por el contrario, si tienes seguridad de que el producto a construir y la tecnología a emplear resolverán el problema que se pretende resolver, entonces, no tiene tanto sentido utilizar Scrum.

Si te interesa saber más sobre los otros dominios del Marco Cynefin, que no es tan conocido como se merece por la claridad que nos aporta, te invito a que leas este artículo del Modelo Cynefin.

Scrum no tiene sentido en trabajos que son de naturaleza mecánica o física, pues existen otras soluciones más efectivas. En cambio, si las tareas son de tipo cognitivas o creativas, existe una alta probabilidad de que Scrum sea el enfoque adecuado, sobre todo cuando nos enfrentamos a un contexto en donde la predicción es inviable o tiene poco valor. Esta es una de las diferencias entre los procesos de seguimiento y control predictivo y empírico.

Los 5 Valores de Scrum: Compromiso, Foco, Franqueza, Respeto y Coraje

El éxito de Scrum radica en la capacidad que tengas de llevarlo adelante abriéndote a cinco valores: compromiso, foco, franqueza, respeto y coraje.

Estos valores determinan tu dirección con respecto al trabajo que realizas, las acciones que emprendes y el comportamiento que muestras.

Debes tener presentes estos valores en cada uno de los eventos de Scrum. Cuando encarnas los valores de Scrum, junto al resto de tu equipo y los interesados, logras sacar el máximo provecho de los pilares de transparencia, inspección y adaptación.

Cualquier decisión que tomes sobre la mejora continua del proceso, debe resguardar estos valores y no ir contra ellos. Ahora, veamos a qué se refieren estos valores.

Compromiso

“El equipo Scrum se compromete a lograr sus objetivos y a apoyarse entre ellos.” - Guía Scrum

Tu compromiso con el resto del equipo Scrum está por encima de los intereses personales. Te comprometes a apoyar a los otros miembros, a actuar con solidaridad y empatía, a colaborar, a crear un incremento de calidad, a hacer tu trabajo de forma profesional. Te comprometes con el objetivo del producto, te comprometes a ser parte de un equipo autogestionado y multi-funcional, a buscar la mejora continua, a seguir los valores y principios del manifiesto ágil. A ser transparente y a desafiar el status-quo.

Una conducta que he observado en varias oportunidades y que muchos de mis estudiantes traen a las conversaciones es aquella en la que se le exige al equipo entregar al final del sprint todo aquello que al iniciarlo había seleccionado. Es decir, se toma el trabajo escogido para el Sprint como un compromiso irrenunciable en vez de como lo que realmente es, un pronóstico.

Esta interpretación errónea de este valor se sustenta en la también errónea interpretación de Scrum como metodología predictiva. Hay una creencia que el compromiso es del equipo para con el Incremento y significa entregar sí o sí aquello a lo que se comprometió en el Sprint. Ten cuidado de no caer en esta creencia en la cual el compromiso es un contrato tácito y un elemento de presión para que el equipo entregue cierto Incremento.

Foco

"El foco principal del equipo Scrum está puesto en el trabajo del Sprint para lograr el mayor progreso posible hacia el objetivo" - Guía Scrum

Te enfocas en lo más importante, y lo más importante en este momento es el trabajo de este Sprint para lograr un Incremento de producto. El Sprint es un evento de tiempo preestablecido y fijo (a esto llamamos time-box) con un objetivo y un Incremento ya planificado. Durante el Sprint tu máxima prioridad es construir ese Incremento.

Uno de los aspectos que más cuesta en la puesta en práctica de este valor es la tentación de hacer cosas “por las dudas que se necesiten en un futuro”. Recuerda, debes trabajar solo en lo que es importante ahora y no en lo que puede llegar a ser importante en el futuro. Estás en un contexto complejo y anticiparte demasiado podría hacerte pagar un alto precio por basar tus decisiones en supuestos equivocados.

Otros peligros que atentan contra el foco son las interrupciones durante el Sprint con reuniones imprevistas o trabajo referente a temas no incluidos en el Sprint o perteneciente a otros equipos. Todas estas situaciones debes evitarlas para no corromper el valor potencial de Scrum. Enfócate en lo que hay que hacer ahora, trabaja en un solo equipo.

Frente a la incertidumbre, el foco también te ayudará a evitar el análisis-parálisis. Debes concentrarte en tener un Incremento funcionando en unas pocas semanas, no te enredas en tus propios pensamientos creyendo que analizando las posibilidades llegarás a la respuesta correcta ya que en un entorno complejo esto rara vez funciona. La clave es experimentar y validar en los hechos y no en los supuestos.

Estar enfocado significa que harás una cosa a la vez. Antes de comenzar algo nuevo, asegúrate de haber terminado lo anterior.

Franqueza

“El equipo Scrum y los interesados muestran franqueza con respecto al trabajo y a los desafíos.” - Guía Scrum

La naturaleza empírica de Scrum requiere que aprendas a partir de la inspección frecuente de la realidad. Pero ¿cómo? Para que la realidad que veas sea lo más cercana a la verdad posible, necesitas un ambiente transparente. Esa transparencia no se manifestará si en primer lugar no hay honestidad. Para sacar el mayor provecho posible de este valor, mi interpretación es que la honestidad o franqueza en el contexto de Scrum podemos concebirla en una doble vía.

Si los miembros del equipo abrazan la franqueza como un valor, bajarán tus defensas y la necesidad de cuidar tu imagen frente a la posibilidad de cometer un error o equivocación. Ser abierto te permitirá admitir los errores y cambiar de dirección sin apegos como parte del ejercicio de inspección y adaptación continua.

Para poder ser sinceros con los demás, también debemos practicar la franqueza para con nosotros mismos. Por ejemplo, si logramos una humilde honestidad frente a nuestras capacidades y falencias, sabremos qué aprendizajes nos están faltando y posiblemente tendremos mayor tolerancia con nuestro entorno.

Respeto

“Los miembros del Equipo Scrum se respetan entre sí como personas capaces e independientes y son respetados como tales por las personas con quienes ellos trabajan.” - Guía Scrum

No importa el rol que ocupes, muestra respeto por tus compañeros de equipo, por sus habilidades, experiencias y competencias.

Muestra respeto por su derecho a decidir cómo hacer su trabajo. Respeta sus decisiones y opiniones, tienes una gran oportunidad de aprender de ellas. Cuando las personas se sienten escuchadas y tenidas en cuenta es más probable que apoyen las decisiones del equipo, aun estando en desacuerdo. Eso se llama consentimiento.

Juzga las acciones y respeta a las personas. Esto garantizará un ambiente mucho más seguro para poner en práctica la mejora continua.

Y por sobre todas las cosas, respétate a ti. Di “no” cuando sientas la necesidad de decir que no. Al hacerlo enalteces tu autonomía y legitimidad como persona. No aceptes el status-quo si crees que se puede mejorar.

Coraje

“Los miembros del Equipo Scrum tienen el coraje de hacer lo correcto y de trabajar en problemas difíciles.” - Guía Scrum

Coraje es valentía. Eres valiente cuando decides construir solo aquello que aporta valor y no trabajar en las cosas que nadie utilizará. Valentía es enfocarte en lo que es importante ahora y no en lo que podría llegar a ser importante en el futuro.

Eres valiente cuando no dudas en poner manos a la obra, aun sabiendo que ningún plan es perfecto y que habrá retos por delante.

Eres valiente cuando reconoces abiertamente que no se lograron hacer aquellas cosas que se pretendía realizar. Valentía es no utilizar excusas. Valentía es hacerte cargo de lo que suceda. Valentía es no fingir frente a tus clientes mostrando cosas no terminadas.

Eres valiente cuando compartes toda la información que tienes para beneficiar al resto del equipo y a la organización, en especial cuando muchos podríamos haber sido educados con la premisa de "la información es poder". En un contexto colaborativo como Scrum, muestras valentía cuando eres transparente, aun sintiendo presión por no serlo.

Muestras valentía al admitir que los supuestos sobre los cuales basaste tus decisiones no fueron los correctos. Eres valiente cuando lo aceptas y cambias de dirección. Valentía es asumir tus errores abiertamente. Valentía es reconocer que no tienes acceso a la información completa y que tus puntos de vista pueden cambiar a medida que aprendes. Valentía es ser humilde en lo intelectual.

Transparencia, Inspección y Adaptación. Cómo se aplican los pilares de Scrum a los eventos de Scrum

Aprendes haciendo y observando. El conocimiento es información, el aprendizaje es acción. Debes aprender cuál es el producto correcto para generar en las personas los comportamientos que quieres promover.

Ese aprendizaje no lo vas a lograr en el campo intelectual, lo vas a lograr en el campo práctico, haciendo, observando, analizando la puesta en práctica, descubriendo el uso que las personas le dan a los productos que construyes.

Aprendes observando y adaptando. Observando y adaptando. Observando y adaptando.

Dentro de un Sprint de Scrum hay varios eventos. Cada uno de esos eventos está relacionado de una u otra forma con alguno de los tres pilares.

Transparencia

Ser transparente implica hacer visible la información deliberadamente.

Las decisiones importantes que tomes en Scrum están atadas a la información con la que cuentas. Para que las decisiones no sean riesgosas es preciso que esa información esté visible y al alcance de todos los involucrados. Lograrás transparencia visibilizando los artefactos y garantizando a todos, equipo e interesados, el acceso a los mismos.

La transparencia va en ambas direcciones, no solo del equipo Scrum hacia afuera, sino también desde los interesados hacia el equipo Scrum.

Inspección

Tanto la evolución del producto como las mejoras en el proceso de creación deben ser inspeccionados de forma frecuente. La evolución del producto te acercará o te alejará del objetivo buscado. Esos desvíos los irás descubriendo en el camino, es decir, dado que estás en un contexto complejo donde no tienes capacidad de predecir (por eso utilizas Scrum), debes inspeccionar si los supuestos en los que has basado las decisiones son adecuados o no. Esto lo podrás hacer una vez que el producto haya evolucionado, no antes.

En Scrum hay un artefacto que te permitirá inspeccionar la evolución del producto, lo llamamos Incremento, y un evento hacia el final de cada Sprint destinado a inspeccionar ese Incremento de producto, lo llamamos Sprint Review.

La mejora continua del proceso de creación del producto te hará ser más o menos eficiente en tu trabajo, Sprint tras Sprint. Esa mejora también debe ser inspeccionada para asegurarte que los supuestos, en los cuales has basado tus decisiones de cambio en la forma de trabajar, fueron los correctos. Todo Sprint culmina inspeccionando los cambios al proceso y su eficiencia. Esto sucede en un evento que llamamos Retrospectiva.

Como puedes ir deduciendo, para que estas inspecciones de producto, en el Sprint Review, y de proceso, en la Retrospectiva, sean eficientes, es necesario que todo esté bajo un manto de transparencia. De lo contrario es probable que termines inspeccionando una realidad que no es tal y tomando decisiones incorrectas.

Adaptación

Si descubres que el producto se está desviando considerablemente de su objetivo o el proceso está saliendo de ciertos límites tolerables, deberás tomar decisiones de adaptación. Esta adaptación deberá producirse tan pronto como sea posible para evitar incurrir en mayores desvíos.

En la Retrospectiva es donde tomarás decisiones de adaptación del proceso, eso implica, decisiones de cambio en la forma de trabajar.

Apenas comenzado un nuevo Sprint tomarás decisiones de adaptación del producto. Scrum tiene un evento dedicado a esto, lo llamamos Sprint Planning.

¿Qué caracteriza al Equipo Scrum?

"La unidad fundamental de Scrum es un pequeño equipo de personas, un Equipo Scrum. El Equipo Scrum consta de un Scrum Master, un Scrum Product Owner y Desarrolladores." - Guía Scrum

Tu Equipo Scrum funciona como centro de creación de Incrementos con el propósito de lograr el objetivo del producto. Ser la "unidad fundamental de Scrum" no es un detalle que debas pasar por alto. Todo lo contrario. Scrum sucede dentro del equipo y por ello desde el lugar que ocupes tienes que cuidarlo como la piedra fundamental a partir de la cual vendrá el resto.

Dentro de este equipo puedes ocupar uno de tres roles: Desarrollador, Scrum Product Owner o Scrum Master.

Tanto si ocupas el rol de Scrum Master como si ocupas el rol de Scrum Product Owner podrías ocupar en paralelo el rol de Desarrollador, aunque no es requerido. Pero cuidado, no debes ocupar el rol de Scrum Product Owner y el de Scrum Master juntos dado que ambos roles funcionan por oposición de intereses.

Scrum no reconoce ningún tipo de jerarquía dentro de tu equipo, sub-equipos ni roles que no sean los mencionados previamente.

Dado que Scrum está diseñado para responder a bajo costo a los cambios inherentes a los ambientes complejos con requerimientos cambiantes, tanto la estructura como el tamaño de tu equipo deben estar orientados a este fin.

Un Equipo Scrum tiene típicamente no más de 10 personas. Una mayor cantidad de personas ha demostrado no ser lo suficientemente eficiente a la hora de cambiar de dirección y tomar decisiones ágilmente. No debe ser muy pequeño tampoco, sino del tamaño necesario para que el Incremento producido en cada Sprint sea de un valor considerable.

Los equipos muy grandes se dividen en Equipos Scrum de no más de 10 personas, todos trabajando en un mismo producto, compartiendo no solo un único Scrum Product Owner, sino enfocados en un único Objetivo de Producto y Product Backlog. En el caso que desees profundizar en el uso de Scrum a gran escala te recomiendo un marco derivado de Scrum que se llama LeSS (Large Scale Scrum).

Un factor importante para considerar relacionado con el tamaño es que se espera que dentro de tu Equipo Scrum cuentes con todas las habilidades necesarias para poder entregar Incrementos terminados y usables al final de cada Sprint. Esto implica que no necesites de la intervención de personas externas a tu equipo. Esta característica la llamamos multifuncionalidad. Tu Equipo Scrum es un equipo multi-funcional.

¿Quiénes son y qué hacen los desarrolladores en Scrum?

"Los desarrolladores son las personas del Equipo Scrum que están comprometidas a crear cualquier aspecto de un Incremento utilizable en cada Sprint" - Guía Scrum

La designación de Desarrollador abarca cualquiera de los roles necesarios para construir el producto. Por ejemplo, si estamos construyendo sillas, el carpintero, el tapicero, el pintor, el diseñador y el probador de sillas son Desarrolladores. Si estuviésemos construyendo software entonces el tester sería un Desarrollador, el programador sería un desarrollador, el analista de negocio, el diseñador de producto, el de interfaz de usuario, el de back-end, el administrador de bases de datos, etc. serían todos Desarrolladores.

Si ocupas este rol, al margen de las habilidades técnicas que debas tener, las cuales varían según la industria en la cual te desempeñas, hay ciertas responsabilidades que son inalienables a ti y a los demás desarrolladores:

Crean el Plan del Sprint

En principio, ustedes son los responsables de crear el plan de cada Sprint. Para poder crear este plan, antes deberían haber estimado el trabajo a realizar, identificado cuánto de ese trabajo pueden realizar en el Sprint en cuestión, desglosar ese trabajo en diferentes tareas y darle cierta coherencia a todo ese trabajo.

Este plan se verá reflejado en el Sprint Backlog. Este plan no está escrito en piedra e irá mutando durante el Sprint en función del aprendizaje que vaya emergiendo.

Entregan solo aquello que esté “terminado”

En segunda instancia, deberán mostrarse comprometidos con los estándares de calidad asumidos por todos y registrados en la Definición de Terminado. Nadie podrá solicitarles la alteración de esos criterios con el fin de terminar más rápido o entregar más cantidad de producto. Deberás defender la calidad de tu trabajo como algo no negociable. El Incremento de cada Sprint debe estar alineado con esta Definición de Terminado.

Por respeto a tu propio trabajo, a tus compañeros de equipo y a los stakeholders, no vas a entregar nada que no esté terminado.

Adaptan el plan frecuentemente

En tercer lugar, eres responsable de revisar día a día, junto a los demás desarrolladores, el avance hacia el objetivo del Sprint. Es su responsabilidad compartida detectar desvíos y tomar las decisiones necesarias para adaptar el plan de las próximas 24 horas con el objetivo de corregir cualquier eventualidad.

Se consideran mutuamente responsables

Finalmente, otra expectativa que tienes como Desarrollador es responsabilizarte y responsabilizar a los demás Desarrolladores a llevar adelante un trabajo profesional. Los Desarrolladores, quienes en conjunto cuentan con todas las habilidades, conocimientos y herramientas para la construcción del producto digital para la industria de que se trate, se destacan por trabajar muy de cerca con los usuarios y tienen la capacidad de tomar decisiones de diseño y adaptación en tiempo real, respondiendo prácticamente al instante a los cambios en las condiciones del negocio, sin la necesidad de transitar las burocracias de hace años.

Los desarrolladores son responsables de la táctica de trabajo (cómo lo vamos a hacer) y de la calidad del producto, que se crea de a pequeños incrementos sucesivos por medio de los intervalos antes mencionados. Las personas dejan de ser percibidas como recursos o individuos independientes y pasan a ser parte de un conjunto interdependiente, donde el éxito o el fracaso es colectivo y no individual.

¿Cuáles son las funciones del Scrum Master?

"El Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Logra esto ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización" - Guía de Scrum

Siguiendo la guía oficial de Scrum, el foco del Scrum Master está puesto en el proceso de trabajo y en la mejora continua. El principal objetivo del Scrum Master es que el Equipo Scrum se desarrolle y logre ser competente en el uso de Scrum, autogestionado y multifuncional. Un Equipo Scrum es multifuncional cuando logra construir un Incremento en el Sprint sin depender de terceros.

Para que la carrera profesional de un Scrum Master logre ser exitosa, es recomendable que domine cuatro disciplinas claves: el training, la consultoría, la facilitación y el coaching.

Las habilidades de training, formación o educación asisten a los Scrum Masters en poder transmitir los conocimientos necesarios para comprender Scrum, y de esta forma asegurarse que el framework está siendo utilizado correctamente

Las habilidades de consultoría son útiles para que el Scrum Master pueda aconsejar tanto al Equipo Scrum como a los stakeholder en el uso de Scrum de una forma eficiente y evitando anti-patrones de conducta que vulneran la eficacia de Scrum.

La facilitación será una habilidad clave para el Scrum Master a la hora de facilitar los diferentes eventos de Scrum y hacer que sean encuentros significativos para todos los involucrados con resultados de valor.

El coaching es una competencia esencial en la agilidad y Scrum para acompañar al Equipo a superarse Sprint tras Sprint, derribar creencias auto limitantes y expandir su abanico de posibilidades con vistas a la entrega de valor.

El Scrum Master tiene un estilo de liderazgo servicial

Puede suceder que al Scrum Master también se lo llame Facilitador o Coach porque su responsabilidad consiste en asegurar que se siga Scrum sin interferir directamente en el desarrollo del Incremento durante el Sprint. El Equipo Scrum es quien elige la forma de trabajo que más prefiera, siempre que se cumplan las pautas básicas de Scrum, por ello mientras lo hagan no existe una forma “errónea” de trabajar.

Dado que el rol de Scrum Master también incluye asegurar que el desarrollo del producto tenga la mayor probabilidad de ser completado de forma exitosa, una manera de lograrlo es poniendo en práctica el liderazgo servicial, dando servicio de cerca al Equipo Scrum, al Scrum Product Owner y a la organización.

Cómo el Scrum Master apoya al Equipo Scrum

Siempre siguiendo la Guía oficial de Scrum, otro aspecto fundamental de las responsabilidades del Scrum Master es el entrenamiento que brinda el Scrum Master a los miembros del equipo en autogestión y multifuncionalidad.

También ayuda al equipo a concentrarse en crear Incrementos de alto valor que cumplan con la Definición de Terminado; canaliza la eliminación de impedimentos para el progreso del equipo; y se ocupa de que todos los eventos de Scrum tengan lugar y sean positivos, productivos y se mantengan dentro del marco de tiempo.

Cuál es el servicio que brinda el Scrum Master al Scrum Product Owner

El Scrum Master ayuda al Product Owner a encontrar técnicas para la definición de los objetivos del producto y la gestión del Scrum Product Backlog.

También asiste al Equipo Scrum en dar importancia a la necesidad de contar con Ítems del Product Backlog claros y concisos, contribuye con el Scrum Product Owner a establecer una planificación de producto empírica para un entorno complejo, y facilita la colaboración de los stakeholders según se solicite o necesite.

El Scrum Master también asiste a su organización

El Scrum Master acompaña a la organización en la adopción de Scrum a través de su liderazgo, la capacitación y el coaching a la organización. El Scrum Master también planifica y asesora en implementaciones de Scrum dentro de la organización.

Brinda ayuda a los empleados y stakeholders a comprender y aplicar un enfoque empírico para el trabajo complejo y elimina barreras entre stakeholders y Equipos Scrum.

¿Cuál es el rol del Scrum Product Owner?

"El Scrum Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Equipo Scrum" - Guía de Scrum

Dentro del equipo Scrum, el Scrum Product Owner es el responsable del producto desde el punto de vista de negocio. El Scrum Product Owner debe velar por que los Incrementos que entrega como integrante del Equipo Scrum sean del mayor valor posible en cada Sprint.

Al ocupar este rol, debe asumir que es el único responsable de tomar decisiones acerca del producto. El producto puede ser un producto digital, físico, un servicio o, inclusive, algo más abstracto como una experiencia. Aunque puede recibir ayuda de otros, el Scrum Product Ownership no es un trabajo que realiza un grupo de personas, lo realizas solo el Scrum Product Owner. También recuerda que, si bien podría actuar en el rol de desarrollador, la función de Scrum Product Owner es completamente incompatible con desempeñar al mismo tiempo el rol de Scrum Master.

Los objetivos y la visión del producto

Una de las responsabilidades del Scrum Product Owner es desarrollar y comunicar explícitamente los objetivos del producto. Dada la naturaleza colaborativa de Scrum, lo ideal sería que estos objetivos no sean algo impuesto a los demás, sino el resultado de una creación conjunta alrededor de una visión de producto.

La visión de producto establece el escenario futuro a lograr con el producto. Esta visión es típicamente utópica e inspiradora y determina la dirección, pero difícilmente ayude a medir el progreso. La visión de producto no es parte del framework de Scrum.

A partir de la visión, el Scrum Product Owner debe establecer la estrategia de creación del producto. En esa estrategia se trazan los diferentes objetivos del producto a ir alcanzando. Los Objetivos de Producto sí son parte del framework de Scrum.

Podríamos deducir entonces que cuando hablemos de Objetivos de Producto estamos hablando de diferentes hitos de negocio, medibles, que al encadenarse determinan la estrategia de producto hacia una visión.

Tanto la visión, como la estrategia, como los objetivos emergen del trabajo colaborativo que involucra a stakeholders y miembros del Equipo Scrum.

Garantizar el entendimiento del Product Backlog

El trabajo como Scrum Product Owner se desarrolla durante todo el día, todos los días del Sprint. El Product Owner es parte del Equipo Scrum, está en contacto constante con el resto del equipo. Si trabajan de forma remota, está accesible todo el tiempo. Si trabajan de manera presencial, se sienta junto a los desarrolladores. En cualquier caso, el Scrum Product Owner trabaja codo a codo con el resto del Equipo Scrum durante todo el Sprint.

La responsabilidad del Scrum Product Owner es garantizar que todos entiendan lo mismo del Product Backlog. Esto no significa documentar detalladamente los requerimientos, sino conversar y verificar durante el Sprint que el Incremento que se vaya creando cumple con las expectativas.

Al mismo tiempo, el Product Owner coordina y facilita actividades que llamaremos Refinamiento donde los desarrolladores se involucran activamente, y convocan a stakeholders y usuarios, para la definición del producto a mediano plazo y en detalle a corto plazo.

Determinar el orden en el que se hace el trabajo

Todo lo que forma parte del Product Backlog está ordenado. El orden es muy preciso para aquellos Product Backlog items (PBIs) prioritarios que se transformarán en un Incremento en el corto plazo.

No tiene mucho sentido dotar de mucha precisión al orden de aquellos Product Backlog Items que tienen menor prioridad, en las que se trabajará en el mediano plazo, ya que cualquier esfuerzo que se dedique a ordenar con precisión estos ítems es muy probable que se deba invertirlo nuevamente al descubrir que las prioridades deben cambiar a partir del feedback o el aprendizaje.

Definitivamente, los ítems del Product Backlog a largo plazo no tiene ningún sentido que estén ordenados. A medida que se acerque a ellos en el tiempo, en los Refinamientos, el Scrum Product Owner los irá ordenando con mayor precisión.

Visibilizar el Product Backlog

El Scrum Product Owner es responsable de que el Product Backlog sea accesible y conocido por todos los involucrados, ya sean miembros del Equipo Scrum, stakeholders o cualquier persona en la organización.

Sin importar la herramienta que se utiliza para almacenar el Product Backlog, la cual podría ser Excel, Google spreadsheets, Trello, Monday, Jira, etc; el Product Owner debe asegurarse de que no haya restricción de acceso y que en cada comunicación o email que se envíe, siempre se incluya en el pie un link a la visualización del Product Backlog.

El Product Owner como Responsable del Producto vela por que el equipo tenga una visión clara y una estrategia (qué vamos a hacer) para la creación de ese producto (o servicio). Se espera que gestione eficientemente las variables de negocio involucradas y conozca profundamente los problemas que el producto pretende resolver a los usuarios. En resumen, el Scrum Product Owner es el responsable por el éxito del producto.

Los artefactos de Scrum

Según la Guía oficial de Scrum, los artefactos representan valor o trabajo y su objetivo es maximizar la transparencia de la información clave. La Guía menciona tres artefactos Scrum:el Product Backlog, el Sprint Backlog y el Incremento.

El Product Backlog y el ordenamiento de los PBIs

El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. - Guía de Scrum

El Backlog del Producto o Product Backlog es un listado de ítems (Product Backlog Ítems, PBIs) que representan las características del producto a construir. Esta lista de Ítems del Product Backlog o PBIs es un elemento vivo y emergente, que cambia constantemente a medida que se aprende más y más acerca del producto. Es mantenida y ordenada por el Scrum Product Owner y es la única fuente del trabajo que hace el Equipo Scrum.

Todos los PBIs que componen el Scrum Product Backlog tienen una razón de existir, y esa razón es cumplir con cierto Objetivo de Producto.

Todos los ítems del Product Backlog existen para lograr un cierto Objetivo de Producto. Dar un orden claro a los PBIs es esencial porque justamente este orden dentro del Product Backlog determinará la estrategia de evolución del producto y las prioridades con las cuales los desarrolladores transformarán los Product Backlog Items en Incrementos de producto.

Hago una distinción deliberada entre priorizar y ordenar. En mis años de experiencia he visto que cuando se habla de priorizar, una opción es acomodar el todo en tres grandes grupos: prioridad alta, media y baja. A diferencia de eso, los PBIs de un Product Backlog deben estar en una fila, nunca compartiendo un mismo grupo, salvo ciertas excepciones que ya veremos, por eso me refiero a ello como "ordenados" en fila.

El ordenamiento del artefacto Product Backlog es responsabilidad exclusiva del Scrum Product Owner y, aunque todos dentro del equipo pueden hacer sugerencias o recomendaciones, es el Scrum Product Owner quien tiene la última palabra acerca del orden definitivo de los ítems del Product Backlog (PBIs), teniendo en cuenta el contexto de negocio, el producto mismo y el mercado en el que está inserto.

Una forma en la que pueden ordenar los ítems del Product Backlog es según su aporte al objetivo del producto. Podemos entenderlo como la relevancia que un ítem tiene para el cumplimiento del objetivo del producto.

Un enfoque diferente para determinar la prioridad de un ítem del Product Backlog es calcular el beneficio económico que se obtendrá en función del esfuerzo que se deba invertir (ROI). Esto, si bien es una simple fórmula matemática, tiene implícita la problemática de encontrar o conocer el valor económico ganado por la incorporación de una determinada característica a un producto.

Ya sea que ordenes los ítems del Product Backlog por aporte al objetivo del producto o por ROI, en cualquier caso, llamémosle “ordenar por importancia”, éstos pueden verse afectados por el nivel de riesgo asociado a cada uno de ellos.

De esta manera, deberías aprovechar la construcción iterativa y evolutiva de Scrum para mitigar riesgos en forma implícita: construyendo primero aquellos Product Backlog Items con mayor riesgo asociado y dejando los que poseen menor riesgo para etapas posteriores. Se recomienda que los PBIs de baja importancia y alto riesgo sean evitados.

El Sprint Backlog es un plan deliberadamente incompleto

El Sprint Backlog se compone del Objetivo del Sprint (por qué), el conjunto de PBIs seleccionados para el Sprint (qué), así como un plan de acción para entregar el Incremento (cómo). - Guía de Scrum

En Scrum, el Sprint Backlog representa todo el trabajo a ser realizado en el Sprint. Está formado por el Objetivo del Sprint, un conjunto de Product Backlog Items y las tareas que los desarrolladores han identificado para poder entregar un Incremento al finalizar el Sprint.

El Objetivo del Sprint describe la razón por la cual vale la pena realizar el trabajo del Sprint y, si eres desarrollador, te proporciona un norte para que puedas determinar si el camino recorrido durante lo que va del Sprint te está conduciendo, a ti y a tu equipo, hacia el lugar esperado.

El Sprint Backlog es un plan incompleto, el trabajo surgirá y se terminará de consolidar durante el Sprint.

Contar con un objetivo permite inspeccionar su progreso y tomar decisiones de adaptación del plan del Sprint de manera frecuente. Hay muchos posibles caminos para alcanzar el mismo destino. Es posible que sea necesario renegociar el alcance o replantear el enfoque de solución de los desafíos que se presenten. El Objetivo del Sprint ayuda a enfocar en lo que se quiere lograr y da flexibilidad con respecto al cómo lograrlo.

Al mismo tiempo, el Objetivo del Sprint es un aspecto que valida la alineación que existe entre Equipo Scrum y stakeholders. Al final de cada Sprint se espera que el Equipo Scrum haya construido un Incremento que logre el Objetivo del Sprint. Ese es un compromiso, mientras que el trabajo a realizar, PBIs y tareas, son un mero pronóstico para alcanzar ese logro.

El Objetivo del Sprint se establece en el Sprint Planning y se llega a él de forma colaborativa entre el Scrum Product Owner y los Desarrolladores.

Inicialmente los Objetivos de Sprint estarán centrados en validar los supuestos más críticos, aquellos que podrían hacer fracasar el producto en su totalidad. Luego, se pasa a validar supuestos de usabilidad, de comportamiento específico de los usuarios de tu producto, de cumplimiento de ciertos hitos en outcomes de negocio y, por último, habrá objetivos de optimización, performance y terminaciones cada vez más finas.

Los PBIs del Product Backlog que finalmente queden seleccionados para el Sprint actual forman parte del Sprint Backlog.Este es un conjunto de PBIs que cobran cierta coherencia con respecto al Objetivo del Sprint. Heredan el orden que tenían en el Product Backlog, por lo tanto, no es lo mismo trabajar en cualquiera de ellos.

El plan de acción del Sprint consiste en las tareas que se necesitan llevar a cabo en el Sprint para construir el Incremento a partir de los Product Backlog Items seleccionados, y así lograr el Objetivo del Sprint. Estas tareas tienen una duración de un día o menos y son identificadas por los Desarrolladores durante el Sprint Planning, a sabiendas que muchas de ellas irán surgiendo a lo largo del Sprint.

Incremento de Producto como resultado del Sprint

Un Incremento es un escalón concreto hacia el logro del Objetivo del Producto. - Guía de Scrum

En Scrum, el Incremento de Producto representa un movimiento hacia el logro del Objetivo de Producto y respeta la Definición de Terminado (Definition of Done, DoD).

Un Incremento no tiene sentido si es considerado de forma aislada con respecto al resto del producto. El Incremento de un Sprint se integra a todos los Incrementos anteriores formando una coherencia de producto 100% terminada y funcional hasta ese momento. Nada ha quedado pendiente, nada ha sido creado a medias, nada será terminado en futuros Sprints.

Es tan fuerte esta intención en Scrum que es preferible no entregar nada a entregar un Incremento que no se pueda utilizar, ya que el efecto de falsa sensación de progreso y baja calidad es tan contundente que resulta más perjudicial para todo el Equipo Scrum y los stakeholders que el hecho de no haber construido el Incremento. Así que ya lo sabes, créeme, es preferible no entregar a entregar cosas a medio terminar.

La Definición de Terminado o Definition of Done es el compromiso con respecto a la entrega de un Incremento al finalizar un Sprint. La Definición de Terminado representa el nivel mínimo de calidad al que debe llegar un ítem del Product Backlog para poder ser considerado como parte del Incremento. Puede ser un estándar a nivel organizacional o un acuerdo a nivel de producto, ya sea que trabaje un solo equipo o lo hagan varios.

Cualquier construcción que no respete la Definición de Terminado no formará parte del Incremento y, por lo tanto, no participará del Sprint Review.

Los Eventos de Scrum

Todo el trabajo de inspección y adaptación de los artefactos de Scrum se realiza en momentos específicos llamados Eventos.

Los eventos de Scrum acontecen siempre al mismo momento del Sprint y tienen una duración específica. Estos eventos de Scrum son cinco: el Sprint, el Sprint Planning, la Daily Scrum, el Sprint Review y la Sprint Retrospective (o Retrospectiva).

El Sprint y la duración sugerida

El Sprint es un contenedor para todos los demás eventos… Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor. - Guía de Scrum

Al ser Scrum un proceso de desarrollo incremental y evolutivo, utiliza periodos consecutivos de tiempo corto para construir un producto, Incremento tras Incremento, para inspeccionar y adaptar frecuentemente tanto el producto como el proceso utilizado. A estos periodos de tiempo acotado, en Scrum, se los identifica como Sprints.

Todos los eventos de Scrum, Sprint Planning, Daily Scrums, Sprint Review y Sprint Retrospective, y todo el trabajo que sea necesario hacer para transformar los PBIs en un Incremento sucede dentro de un Sprint.

En general, Scrum recomienda una duración de Sprint de un mes o menos, siendo una o dos semanas lo más habitual que encontrarás en la industria. La duración de un Sprint no cambia una vez que se ha establecido. Como excepción podrían considerarse aquellas situaciones donde el equipo mismo decida probar con Sprints más largos o cortos. Esta decisión se basa principalmente en la volatilidad del contexto: mientras más volátil sea (negocio cambiante, necesidades desconocidas, tecnología que evoluciona, etc.) más corta será la duración del Sprint. Lo importante es recordar que se logra mayor ritmo y previsibilidad teniendo Sprints de duración constante.

Durante un Sprint, el Equipo Scrum podría atrasarse o adelantarse con respecto a su trabajo. En estos casos, la variable de ajuste será el alcance del Sprint, nunca su duración. Esto significa, en el caso de adelantarnos deberemos incrementar el alcance del Sprint agregando nuevos Product Backlog Items y reducirlo en el caso de retrasarnos, pero nunca acortar o alargar el tiempo de Sprint. Esta decisión de aumentar o reducir el alcance del Sprint es una potestad del Equipo Scrum y, por lo tanto, tomada entre los Desarrolladores y el Scrum Product Owner.

Como mencionamos anteriormente, el Sprint Backlog contiene el plan del Sprint. A medida que se avanza, se descubre y se aprende durante el Sprint, ese plan podría alterarse sin alterar el Objetivo del Sprint. Los cambios en el plan son gestionados por los Desarrolladores.

Un Sprint puede cancelarse si el Objetivo del Sprint se vuelve obsoleto. Esto sucede cuando las condiciones del entorno cambian tan drásticamente que ya no tiene sentido que el Equipo Scrum siga trabajando en lo que está trabajando y necesite mover su atención a algo mucho más importante.

El hecho de descubrir que no se llega a completar el trabajo del Sprint no es una razón válida para su cancelación dado que, aún construyendo un Incremento más pequeño que el esperado se podría lograr el Objetivo del Sprint.

Dos últimas consideraciones: Por un lado, la cancelación de un Sprint es una decisión que solo el Scrum Product Owner está en condiciones de tomar.

Con respecto a tomar pausas entre Sprints, tener un descanso entre Sprints no atenta contra el ritmo sostenido. El ritmo sostenido en Scrum es como su nombre lo indica: “ritmo", los latidos del corazón. Es decir, podemos tener un Sprint de longitud fija, sin alteraciones y una pausa de longitud fija, digamos de medio día. Si lo hacemos de esa manera, y preservamos esas longitudes en el tiempo, entonces todavía seguimos hablando de ritmo sostenido.

La situación podría ser completamente diferente si tenemos longitudes de tiempo aleatorias, como la mitad un día después del primer Sprint, dos días después del segundo Sprint y un día después del tercer Sprint. Esto atenta completamente contra el “ritmo sostenido”.

La siguiente pregunta sería determinar el destino que se daría a ese tiempo de pausa del Sprint.

Sprint Planning para construir el Incremento

La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint. - Guía de Scrum

La Sprint Planning es el primer evento que se realiza dentro del Sprint. La dinámica de este evento es de tipo taller donde todo el Equipo Scrum pone manos a la obra. La duración máxima de una Sprint Planning es de ocho horas para un Sprint de cuatro semanas, reduciéndose en longitud para Sprints más cortos.

En el Sprint Planning se deciden tres aspectos:

El Objetivo del Sprint, es decir, para qué hacer este Sprint

Los PBIs que formarán parte en este Sprint, es decir, qué Incremento construir

El plan del Sprint, o sea, cómo será construido el Incremento

Todo esto en conjunto formará el Sprint Backlog.

El Objetivo del Sprint describe la razón por la cual vale la pena realizar el trabajo del Sprint. El mismo surge de forma colaborativa y es creado por el Equipo Scrum a partir del input del Scrum Product Owner.

Mediante una conversación entre Scrum Product Owner y Desarrolladores se escogen los PBIs del Product Backlog que formarán parte del Sprint actual. Esta decisión se basa en el Objetivo del Sprint, el orden de los PBIs en el Product Backlog y un pronóstico de cuánto trabajo podrían hacer los Desarrolladores para transformar PBIs en Incrementos. Este último pronóstico se basa en las experiencias de Sprints pasados. Quienes finalmente determinan la cantidad de trabajo a realizar son los desarrolladores.

Durante esta conversación los Desarrolladores realizan todas las preguntas que crean necesarias para conocer los detalles de cada uno de los PBIs y así corroborar o ajustar sus supuestos.

Aún asumiendo que los Product Backlog Items ya han sido explorados en detalle durante los refinamientos previos, debido al principio del Manifiesto Ágil por el Desarrollo de Software que determina que una ventaja competitiva consta de “aceptar los cambios aun en etapas avanzadas del proyecto”, es posible que en esta reunión aparezcan PBIs que no habían sido refinados anteriormente. Esta situación se da muy seguido con PBIs que emergen o incrementan su prioridad debido al feedback recibido en el Sprint inmediato anterior. Frente a esta situación, el Equipo Scrum refina esos ítems del Product Backlog en el momento.

El Scrum Product Owner y los Desarrolladores son los protagonistas en la toma de esta decisión. El Scrum Master, al tiempo que facilita la reunión, también debe asegurar que cualquier stakeholder que sea requerido para profundizar en detalles esté presente o sea contactado.

Los Desarrolladores determinan la forma en la que llevarán adelante el trabajo. Esto implica la definición inicial de un diseño de alto nivel, el cual será refinado durante el Sprint mismo y la identificación de las actividades que deberán llevar a cabo en conjunto.

Si bien el Scrum Product Owner no participa de esta descomposición de PBIs en tareas, hace su aporte en el caso de que los Desarrolladores necesiten respuestas a nuevas preguntas con la finalidad de clarificar su entendimiento de las necesidades. Al finalizar esta reunión, el Equipo Scrum habrá arribado a un Sprint Backlog y estará en condiciones de comenzar con el trabajo del Sprint para transformar los PBIs en un Incremento de valor que respete la Definición de Terminado (DoD) y logre el Objetivo del Sprint.

La Daily Scrum Meeting de desarrolladores para desarrolladores

El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado por delante. - Guía Scrum

El control empírico de procesos se basa en ciclos continuos de inspección y adaptación en un entorno donde se fomenta la transparencia a todo nivel. Estos ciclos se aplican tanto al producto como al proceso y se llevan a la práctica a través de los Sprints que se realizan cada cuatro semanas, pero cuando hablamos de controlar el progreso hacia el Objetivo del Sprint el ciclo de control dura 24 horas y se lleva a la práctica en las reuniones que llamamos Daily Scrum.

En Scrum, la Daily Scrum no debería llevar más de 15 minutos. Para que esto suceda, el tiempo se utiliza únicamente para visibilizar lo hecho y no para intentar resolver problemas. Esto otro puede dejarse para un momento inmediato posterior a la Daily Scrum del cual no necesariamente deban participar todos los Desarrolladores, sino sólo quienes tienen incumbencia. Adicionalmente, se recomienda realizar la Daily Scrum todos los días a la misma hora y en el mismo lugar para reducir la complejidad.

Durante la Daily Meeting el objetivo es que los developers puedan hacer visible cualquier impedimento o desvío hacia el logro del objetivo del Sprint y ajustar el plan del Sprint de las próximas 24hs. Tradicionalmente se utilizaban tres preguntas: ¿Qué hice ayer?, ¿Qué voy a hacer hoy? y ¿Qué impedimentos tengo o tuve en mi trabajo?. Si bien este es el camino tradicional para seguir el progreso del Sprint, el uso de las preguntas no es un requisito, tal es así que la Guía de Scrum las ha omitido a partir del 2020.

Esta es una reunión de Desarrolladores para Desarrolladores. Es posible que al principio la facilite el Scrum Master pero, a medida que los Desarrolladores se van sintiendo cómodos, se transfiere la facilitación para que la puedan hacer ellos mismos.

Sabiendo que, tanto el Scrum Master o Scrum Product Owner, también podrían ocupar el rol de Desarrollador, entonces también participarían de la Daily Scrum como Desarrollador.

El Sprint Review para Inspeccionar el Incremento

El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. - Guía de Scrum

Al finalizar el Sprint se realiza una inspección del Incremento creado, este evento se llama Sprint Review.

En la Sprint Review colabora todo el Equipo Scrum con los stakeholders revisando el Incremento creado en el Sprint e integrado al resto del producto para decidir cuáles serán los próximos pasos hacia el logro del Objetivo de Producto.

La Sprint Review dura un máximo de cuatro horas para un Sprint de cuatro semanas. Si el Sprint es más corto, la Sprint Review durará menos.

Ten especial atención para que la Sprint Review no se convierta en una Demo donde el Equipo Scrum le muestra lo construido a los stakeholders. El mejor feedback y las mejores decisiones que pueden tomar emergen de la revisión activa, es decir, el uso del producto por parte de todos los involucrados y no por la simple observación de lo realizado.

Todo el feedback que emerja en la Sprint Review podría ser o no considerado para adaptar el producto. Eso dependerá de la decisión que tome quien ocupe el rol de Scrum Product Owner y del alineamiento que exista entre las adaptaciones posibles y el Objetivo del Producto. Si las adaptaciones no hacen al Objetivo del Producto, podrían no ser consideradas o consideradas como de baja prioridad. Por el contrario, si las adaptaciones son vitales para el logro del Objetivo del Producto serán consideradas y tendrán alta prioridad. La prioridad determinará el lugar que esa adaptación tome al convertirse en un PBI e ingresar en el Product Backlog.

La Retrospectiva del Sprint y cierre

El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad. - Guía de Scrum

La Retrospectiva del Sprint es el momento en el que el equipo inspecciona cómo le fue durante este último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado (Definition of Done). Este evento es el corazón de la mejora continua y las prácticas emergentes.

¿Para qué es la Retrospectiva del Sprint? En Scrum, la Retrospectiva ocurre inmediatamente después de la Sprint Review y se considera un cierre de Sprint. Mientras que la Sprint Review se destina a revisar el producto, la Sprint Retrospective se centra en el proceso. Su duración es de un máximo de tres horas para un Sprint de cuatro semanas, siendo más corta para Sprints más cortos.

La Sprint Retrospective necesita de un ambiente seguro donde el Equipo Scrum pueda expresarse libremente, sin censura ni temores. Utilizando técnicas de facilitación y análisis de causas raíz, se buscan tanto fortalezas como oportunidades de mejora. Luego, el Equipo Scrum decide cuáles serán las acciones de mejora a llevar adelante en futuros Sprints.

Por último, es importante señalar que la diferencia entre la Retrospectiva del Sprint y la Sprint review es que mientras la Sprint Review se enfoca en inspeccionar lo construido (el incremento), la Sprint Retrospective se enfoca en inspeccionar y adaptar el proceso de trabajo. Es importante evitar la confusión entre estos dos eventos (reuniones) de Scrum.

En conclusión

Podríamos afirmar que hay cinco cuestiones que son esenciales para la práctica de Scrum:

  1. Hacerlo de forma Iterativa, Incremental
  2. No querer abarcar todo desde el principio
  3. Controlar las expectativas de los primeros Sprints
  4. No abrumarse frente a los impedimentos que van a surgir
  5. Tener coraje, experimentar y dejar experimentar - Errar no es malo, lo malo es no aprender del error.

Si quieres aprender más puedes tomar gratis el curso introductorio a Scrum.