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

¿Cuáles son las características de Scrum, sus ventajas y desventajas?

"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 Oficial de 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 la ventaja de su capacidad de entregar valor temprano a los clientes y por brindar adaptabilidad a los equipos en contextos complejos donde, por lo general, los diseños predictivos fallan.

Generalmente se piensa que Scrum es una metodología. Pero Scrum es un diseño deliberadamente incompleto y minimalista, por eso no podemos llamarlo metodología. Cualquier persona, equipo u organización que desee crear productos de calidad gracias a los beneficios de Scrum deberá complementarlo con técnicas y prácticas específicas de su industria. En otras palabras, Scrum dice qué hacer y no dice cómo hacerlo. El Scrum Master es la persona que se encarga de velar por el correcto uso de Scrum.

Scrum proporciona herramientas innovadoras para el trabajo en equipo gracias a su enfoque de equipos multifuncionales y autogestionados 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 cuyos autores son Ken Schwaber y Jeff Sutherland. La guía oficial de Scrum en español nos brinda una explicación para poder comprender que sí es Scrum y que no es, qué es y qué hace un Scrum Master, un Product Owner y un Desarrollador.

Scrum es una manera de trabajar en equipo 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 realidades. La principal ventaja que ofrece Scrum es su falta de rigidez, lo que permite aplicarlo en entornos complejos con requerimientos cambiantes. La "desventaja" de Scrum es que no nos ofrece una guía paso a paso porque, precisamente, el sentido de su uso se encuentra en aplicarlo en contextos inciertos como aquellos que involucran la interacción permanente con lo usuarios. Es el típico ejemplo de los productos digitales, 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 de Product Discovery.

Otra ventaja de usar Scrum es que la generación de valor durante a creación de un producto implica que lo puedas ver funcionando a medida que se construye, crece y evoluciona. De esta manera lo podrás inspeccionar y adaptar tanto como consideres necesario.

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. Por ello, Scrum no funciona como enfoque tradicional 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.

Si quieres aprender más sobre Scrum, puedes tomar el siguiente curso gratis en español:

Fundamentos de Scrum

• La definición, cómo funciona y la filosofía detrás del Manifiesto Ágil y de este marco de trabajo.
• Qué hace el Scrum Master, el Product Owner y los Developers, así como sus responsabilidades, para entender la función de cada uno de los integrantes del Equipo Scrum. Multifuncionalidad y autogestión dentro de los Equipos. Tamaño ideal de los equipos ágiles.
• Qué es un Sprint (evento principal) y cómo se caracteriza el trabajo en Sprints. Los otros Eventos (reuniones): Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva del Sprint, junto con el propósito y qué se hace en cada uno de estos eventos.
• Los tres artefactos y sus características: el Product Backlog, el Sprint Backlog y el Incremento de Producto. Los Product Backlog Items (PBIs) y su ordenamiento. La relación entre el Product Backlog y el objetivo del producto. La relación entre el Sprint Backlog y el objetivo del Sprint. Cómo se asocian el Incremento y la Definition of Done (DoD). Refinamiento del Product Backlog.

 Inscribirme

Cuándo se aplica Scrum y cómo saber si me conviene

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 (The new dynamics of strategy: Sense-making in a complex and complicated world) 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 al 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.

Podemos identificar 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 es posible que no conozcas 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 y aprovechar sus beneficios.

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, puedes leer este artículo del Modelo Cynefin.

Al no ser una metodología, 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 obtengas ventajas con el uso de Scrum, 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.

¿Qué caracteriza al Equipo de trabajo 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 Oficial de Scrum

Dentro del Equipo Scrum puedes ocupar uno de tres roles: Desarrollador, Scrum Product Owner o Scrum Master. Es importante notar que la guía oficial de Scrum, escrita por Ken Schwaber y Jeff Sutherland, en verdad no habla de "roles" sino de "responsabilidades". Además, a diferencia de las estructuras tradicionales de trabajo, una de las características de la conformación de los Equipos en Scrum es no reconocer ningún tipo de jerarquía dentro del equipo, sub-equipos ni otros miembros que el Scrum Master, Product Owner y Desarrolladores.

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 iteración 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 puedes investigar acerca de 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. A esto se lo conoce como equipos multifuncionales e implica que no necesites de la intervención de personas externas a tu equipo.

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

¿Qué hace el Scrum Master?

"El Scrum Master es responsable de establecer Scrum como se define en la Guía oficial 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 Oficial de Scrum

Siguiendo la guía oficial de Scrum, el foco del Scrum Master está en el proceso de trabajo y 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.

En la práctica, 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. 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 desde su lugar que el desarrollo del producto tenga la mayor probabilidad de ser completado de forma exitosa, un buen Scrum Master pone 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

Siguiendo la versión en español de la Guía oficial de Scrum, otra de las responsabilidades del Scrum Master es entrenar 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.

La relación del Scrum Master con el 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

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

Por último, también brinda ayuda a los stakeholders a comprender y aplicar un enfoque empírico para el trabajo complejo y elimina barreras entre stakeholders y Equipos Scrum para evitar las fallas de comunicación.

¿Qué hace el Scrum Product Owner?

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

Dentro del Equipo Scrum, el Product Owner es el responsable del producto desde el punto de vista de negocio. El producto puede ser digital, físico, un servicio o, inclusive, algo más abstracto como una experiencia. Aunque puede recibir ayuda de otros, el trabajo de Scrum Product Ownership no es un trabajo que realiza un grupo de personas, lo realiza solo el Scrum Product Owner.

Los objetivos y la visión del producto

Para ser un buen Product Owner, es necesario 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 y visibilidad del Product Backlog

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. Para garantizar el entendimiento del Product Backlog, el Product Owner está en contacto permanente con el resto del equipo a lo largo de todo el ciclo. Si trabajan de forma remota, está accesible todo el tiempo. Si trabajan de manera presencial, se sienta junto a los desarrolladores.

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.

Un buen Product Owner se encarga 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.

Determinar el orden en el que se hace el trabajo

Todo lo que integra el 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 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.

¿Qué hacen los Developers?

"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 Oficial de Scrum

La designación de Desarrollador o Developer abarca cualquiera de los roles necesarios para construir el producto. Por ejemplo, si estamos 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:

Crear el Plan del Sprint

En principio, los Developers son 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 la iteración 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.

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

Adaptar el plan frecuentemente

En tercer lugar, los Desarrolladores son responsables 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. Esto se materializa en la reunión de sincronización Daily Scrum.

Finalmente, 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.

Fundamentos de Scrum

• La definición, cómo funciona y la filosofía detrás del Manifiesto Ágil y de este marco de trabajo.
• Qué hace el Scrum Master, el Product Owner y los Developers, así como sus responsabilidades, para entender la función de cada uno de los integrantes del Equipo Scrum. Multifuncionalidad y autogestión dentro de los Equipos. Tamaño ideal de los equipos ágiles.
• Qué es un Sprint (evento principal) y cómo se caracteriza el trabajo en Sprints. Los otros Eventos (reuniones): Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva del Sprint, junto con el propósito y qué se hace en cada uno de estos eventos.
• Los tres artefactos y sus características: el Product Backlog, el Sprint Backlog y el Incremento de Producto. Los Product Backlog Items (PBIs) y su ordenamiento. La relación entre el Product Backlog y el objetivo del producto. La relación entre el Sprint Backlog y el objetivo del Sprint. Cómo se asocian el Incremento y la Definition of Done (DoD). Refinamiento del Product Backlog.

 Inscribirme

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 Oficial de Scrum

¿Qué es el Product Backlog y para qué sirve? 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. La ventaja de dar un orden claro a los PBIs es que 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.

Existe una diferencia entre priorizar y ordenar. Cuando se habla de priorizar, una opción es acomodar 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 decimos que se encuentran "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 Oficial de Scrum

En Scrum, se llama Sprint Backlog a aquello que representa todo el trabajo a ser realizado en dicha iteración. Está formado por el Objetivo, 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 de ese ciclo y se establece en el Sprint Planning. Se llega a él de forma colaborativa entre el Scrum Product Owner y los Desarrolladores. Inicialmente los Objetivos 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.

El Objetivo 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. Ese es un compromiso, mientras que el trabajo a realizar, PBIs y tareas, son un mero pronóstico para alcanzar ese logro.

Los PBIs del Product Backlog que finalmente queden seleccionados para el ciclo 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 para construir el Incremento a partir de los Product Backlog Items seleccionados, y así lograr el Objetivo. 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 Oficial 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 nuevo Incremento 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 futuras iteraciones.

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 Scrum se realiza en momentos específicos llamados Eventos.

Los eventos de Scrum suceden siempre al mismo momento dentro del Sprint y tienen una duración específica. Los eventos de Scrum son cinco: el Sprint, la 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 Oficial de Scrum

Al ser un proceso de desarrollo incremental y evolutivo, Scrum 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, se los identifica como Sprints.

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

En general, se recomienda una duración de de un mes o menos, siendo una o dos semanas lo más habitual. La duración 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. Lo importante es recordar que se logra mayor ritmo y previsibilidad teniendo Sprints de duración constante.

Como mencionamos anteriormente, el Sprint Backlog contiene el plan del Sprint. A medida que se avanza, se descubre y se aprende, 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 su Objetivo se vuelve obsoleto. Esto sucede cuando las condiciones del entorno cambian tan drásticamente que ya no tiene sentido que el Equipo Scrum siga 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 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.

Dos últimas consideraciones: Por un lado, la cancelación 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 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 Oficial de Scrum

¿En qué consiste la Sprint Planning? 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.

El Scrum Product Owner y Desarrolladores escogen los PBIs del Product Backlog que formarán parte del Sprint actual. Esta decisión se basa en el Objetivo, 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 iteraciones pasadas. 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 (refinamiento).

Aún asumiendo que los PBIs 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.

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.

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 Oficial de 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.

¿Cuánto dura la Daily 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 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 Oficial 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.

Sprint Review para inspeccionar el Incremento

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

En la 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 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 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 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 Oficial de Scrum

La Retrospectiva 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? En Scrum, la Retrospectiva ocurre inmediatamente después de la Sprint Review y se considera un cierre de Sprint. Mientras que la Review se destina a revisar el producto, la 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 Retrospectiva 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 y la Review es que mientras la Review se enfoca en inspeccionar lo construido (el incremento), la Retrospectiva se enfoca en inspeccionar y adaptar el proceso de trabajo. Es importante evitar la confusión entre estos dos eventos (reuniones) de Scrum.

Pilares de Scrum

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, inspección y adaptación.

Transparencia

El pilar de la transparencia 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 ciclo 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 la 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.

Los 5 Valores de Scrum

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

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

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

Cualquier decisión que tomes sobre la mejora continua del proceso, debe resguardarlos y no ir contra ellos. Ahora, veamos a qué se refiere cada uno de los cinco.

Compromiso

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

Al trabajar en equipo, 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 de los procesos, a seguir los valores y principios del manifiesto ágil. A ser transparente y a desafiar el status-quo.

Una conducta frecuente es exigir 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. De esta forma se está desaprovechando el beneficio de Scrum.

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 Oficial de 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. ¿Qué es un Sprint?La definición de Sprint la veremos adelante pero básicamente el Sprint es un evento de tiempo preestablecido y fijo (a esto llamamos time-box) con un objetivo y un Incremento ya planificado que se utiliza en Scrum para la creación de productos. 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 Oficial de 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, podemos concebir la honestidad o franqueza en una doble via.

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 Oficial de 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 Oficial de 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.

En conclusión:

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

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