Actividades y artefactos de Scrum
A continuación se explican no solo las actividades y artefactos más importantes de Scrum, sino también cómo se relacionan entre sí.
El Product Owner parte de una determinada visión de producto.
Dado que el producto puede ser muy complejo, se descompone mediante el llamado refinamiento del backlog en features o elementos más pequeños, que se organizan en una lista priorizada: el Product Backlog.
Un Sprint comienza con la planificación del Sprint, incluye el trabajo de desarrollo (Sprint Execution) y finaliza con la revisión y la retrospectiva.
La cantidad de elementos en el Product Backlog suele ser mayor de lo que un equipo de desarrollo puede completar en un Sprint.
Por ello, al inicio, el equipo selecciona los elementos del Product Backlog que cree poder finalizar durante la iteración (Sprint Planning).
El objetivo es tener al final del Sprint un incremento de producto potencialmente entregable.
Una nota sobre las actividades en Scrum
En 2011, una modificación en “The Scrum Guide” (Schwaber y Sutherland, 2011) generó un debate sobre si el término más adecuado para describir el resultado de la planificación del Sprint debía ser “forecast” (pronóstico/estimación) o “commitment” (compromiso).
Los defensores del término forecast argumentan que incluso la mejor estimación puede cambiar durante un Sprint conforme se adquiere nueva información.
Por otro lado, algunos opinan que un compromiso podría afectar la calidad del trabajo si el equipo intenta cumplirlo a toda costa o si, por el contrario, fija metas demasiado bajas para asegurarse de alcanzarlas.
No cabe duda de que todo equipo de desarrollo debe ofrecer una estimación de lo que cree que puede lograr durante un Sprint.
Sin embargo, muchos equipos podrían beneficiarse al transformar ese forecast en un commitment.
Los compromisos fortalecen la confianza entre el Product Owner y el equipo de desarrollo, así como entre los propios miembros del equipo.
Además, facilitan la planificación a corto plazo y una toma de decisiones más efectiva dentro de la organización.
Cuando varios equipos participan en el desarrollo de un producto, los compromisos ayudan a coordinar mejor sus planes —un equipo puede basar sus decisiones en el compromiso de otro—.
No obstante, el compromiso debe centrarse principalmente en el objetivo del Sprint, no en las tareas individuales.
A medida que el conocimiento del equipo crece, es común que encuentre nuevas formas de alcanzar la meta, diferentes a las inicialmente planificadas.
(En adelante se utilizará principalmente el término commitment, aunque el contexto puede requerir ocasionalmente el uso de forecast).
Para garantizar que el equipo de desarrollo establezca un compromiso significativo, durante la planificación del Sprint los miembros crean un segundo backlog, llamado Sprint Backlog.
En él se detallan las tareas específicas que describen cómo planean diseñar, desarrollar, integrar y probar los elementos seleccionados del Product Backlog durante el Sprint.
El siguiente paso es la ejecución del Sprint (Sprint Execution).
Aquí el equipo de desarrollo lleva a cabo las tareas necesarias para implementar las funcionalidades seleccionadas.
Durante esta fase se realizan los Daily Scrums, reuniones diarias en las que se llevan a cabo actividades de sincronización, inspección y planificación adaptativa.
Esto permite al equipo gestionar mejor su flujo de trabajo.
Al final de la ejecución, el equipo ha producido un incremento de producto potencialmente entregable, que ya representa parte de la visión del Product Owner.
El equipo Scrum concluye el Sprint con la revisión e inspección (inspect and adapt) tanto del producto como del proceso Scrum.
El producto se evalúa en la Sprint Review, junto con los stakeholders, y el proceso se revisa en la retrospectiva, donde el equipo identifica posibles mejoras en el Product Backlog o en su forma de trabajar.
A partir de ahí, el ciclo del Sprint comienza de nuevo:
el equipo de desarrollo selecciona los siguientes elementos del Product Backlog que puede completar.
Tras varios Sprints, la visión del Product Owner habrá sido alcanzada y el resultado podrá presentarse.
En las siguientes secciones se explican en detalle cada una de estas actividades y artefactos.
Product Backlog
Al trabajar con Scrum, siempre se abordan primero las tareas de mayor valor.
El Product Owner es el responsable —en colaboración con el equipo de desarrollo y los stakeholders— de establecer el orden de prioridad del trabajo y comunicarlo en una lista llamada Product Backlog.
En el desarrollo de nuevos productos, los elementos del Product Backlog suelen ser inicialmente las funcionalidades necesarias para hacer realidad la visión del Product Owner.
En la evolución de productos existentes, el Product Backlog puede incluir nuevas funcionalidades, modificaciones de las ya existentes, corrección de errores o mejoras técnicas, entre otros elementos.
El Product Owner colabora con los stakeholders internos y externos para recopilar y definir los Product Backlog Items.
Luego debe asegurarse de que todos los elementos estén ordenados correctamente —según su valor, coste, conocimiento y riesgo—, de modo que los ítems más valiosos aparezcan al principio del Product Backlog y los menos prioritarios más abajo.
El Product Backlog es un artefacto vivo y en constante evolución.
A medida que cambian las circunstancias del negocio o el equipo Scrum amplía su comprensión del producto (gracias al feedback recibido durante los Sprints), el Product Owner puede agregar, eliminar o modificar elementos del backlog.
El proceso de diseñar, detallar, estimar y priorizar los elementos del Product Backlog se conoce como Backlog Grooming o Backlog Refinement.
Antes de poder priorizar los elementos, es necesario conocer su tamaño o alcance, ya que este determina el coste, y el Product Owner necesita esta información para asignar prioridades.
Scrum no prescribe una unidad de medida específica, pero en la práctica muchos equipos utilizan unidades relativas como los Story Points o los Ideal Days.
Estas unidades no expresan el esfuerzo absoluto de un ítem, sino su tamaño en relación con otros elementos del backlog.
Sprints
En Scrum existen iteraciones o ciclos de hasta un mes llamados Sprints.
Cada Sprint completado debe generar siempre un resultado de valor tangible para el cliente o usuario.
Todos los Sprints tienen una timebox o límite de tiempo definido, con una fecha de inicio y finalización establecida, que debería mantenerse constante entre los distintos Sprints.
Una vez finalizado un Sprint, comienza inmediatamente el siguiente.
Aunque durante un Sprint no deberían realizarse cambios que afecten al alcance o al equipo —ya que esto podría poner en riesgo el objetivo del Sprint—, en ocasiones pueden producirse excepciones por necesidades empresariales inevitables.
Planificación del Sprint (Sprint Planning)
El trabajo contenido en un Product Backlog puede extenderse durante varias semanas o meses, mucho más de lo que puede completarse en un solo y corto Sprint.
Durante la planificación del Sprint, el Product Owner, el equipo de desarrollo y el Scrum Master determinan cuáles son los Product Backlog Items más importantes para el próximo Sprint.
En esta sesión de planificación, el Product Owner y el equipo de desarrollo acuerdan un objetivo del Sprint, es decir, una definición clara de lo que debe lograrse durante el siguiente ciclo de trabajo.
Con esta orientación, el equipo de desarrollo revisa el Product Backlog y selecciona los elementos de mayor valor que realmente puede completar en el próximo Sprint.
La velocidad de trabajo, también conocida como Sustainable Pace, debe fijarse de manera que pueda mantenerse sin dificultad durante un periodo prolongado.
Para tener una mejor idea de lo que es factible, muchos equipos dividen cada elemento del Product Backlog en distintas tareas (tasks).
Estas tareas, junto con los elementos correspondientes, conforman un segundo backlog llamado Sprint Backlog.
Posteriormente, los equipos de desarrollo estiman el esfuerzo necesario para cada tarea, normalmente en horas.
Dividir los elementos del Product Backlog en tareas es una forma de diseño y planificación “justo a tiempo” para completar las funcionalidades.
En Sprints que duran de una a cuatro semanas, la planificación del Sprint suele requerir entre dos y ocho horas, y no debería extenderse más allá de ese límite.
Existen diferentes enfoques para realizar la planificación.
Uno de los más comunes sigue un ciclo simple:
se selecciona un elemento del Product Backlog (idealmente el siguiente en la lista de prioridades del Product Owner), se divide en tareas y se evalúa si encaja dentro del Sprint en función de los demás elementos ya seleccionados.
Si encaja y aún hay capacidad disponible, el proceso se repite hasta que el equipo haya alcanzado su límite de carga para el Sprint.
Otro enfoque consiste en que el Product Owner y el equipo identifiquen primero todos los elementos deseados del Product Backlog.
A continuación, solo el equipo de desarrollo los descompone en tareas y confirma que puede completar todos los ítems planificados dentro del Sprint.
Ejecución del Sprint
Una vez que el equipo Scrum ha finalizado la planificación del Sprint y acordado el contenido del próximo ciclo, el equipo de desarrollo comienza a trabajar en las tareas necesarias para completar las funcionalidades planificadas.
En este contexto, “completar” significa que se han realizado todas las actividades necesarias para entregar funcionalidades de alta calidad.
Nadie le indica al equipo de desarrollo cómo ni en qué orden debe ejecutar las tareas del Sprint Backlog.
Por lo tanto, los miembros del equipo son libres de organizar su propio trabajo y definir la secuencia de tareas que consideren más adecuada para alcanzar el objetivo del Sprint.
Daily Scrum / Daily Standup
Cada día durante el Sprint, preferiblemente a la misma hora y en el mismo lugar, los miembros del equipo celebran una reunión llamada Daily Scrum.
Esta reunión no debe durar más de 15 minutos.
Este proceso de inspect and adapt también se conoce como Daily Stand-up, ya que en la práctica los participantes suelen permanecer de pie para mantenerlo breve y enfocado.
Una práctica común en el Daily Scrum consiste en que cada miembro del equipo responda tres preguntas clave, muy útiles para el resto del grupo:
- ¿Qué he logrado desde el último Daily Scrum?
- ¿En qué voy a trabajar hasta el próximo Daily Scrum?
- ¿Qué me está impidiendo avanzar?
Las respuestas a estas preguntas permiten que todos tengan una visión clara de lo que está ocurriendo, los avances hacia la meta del Sprint, los posibles ajustes al plan diario y los problemas que deben abordarse.
Para garantizar un flujo de trabajo ágil y flexible dentro del Sprint, el Daily Scrum es una práctica indispensable.
Los problemas no se resuelven durante el Daily Scrum.
Después de la reunión, los equipos pueden reunirse en pequeños grupos con los interesados para tratarlos en detalle.
Tampoco es una reunión de estatus tradicional como las que suele convocar un jefe de proyecto para recibir informes de progreso.
El propósito del Daily Scrum es compartir el estado de los elementos del Sprint Backlog dentro del equipo de desarrollo.
En esencia, es una actividad de inspección, sincronización y planificación adaptativa que permite al equipo autoorganizado mejorar continuamente su desempeño.
Definition of Done
En Scrum, los resultados de los Sprints se denominan incrementos de producto potencialmente entregables.
Esto significa que todo lo que el equipo Scrum se propuso completar se ha realizado de acuerdo con la Definition of Done —la definición de lo que se considera “terminado” o “hecho”―.
Esta definición especifica el nivel de calidad y completitud que debe tener el trabajo para considerarse listo y potencialmente entregable.
En el desarrollo de software, por ejemplo, la Definition of Done debería incluir, como mínimo, que una funcionalidad del producto esté diseñada, desarrollada, integrada, probada y documentada.
Con una Definition of Done exigente, una organización puede decidir en cada Sprint si desea entregar lo desarrollado a clientes internos o externos.
Es importante entender que “potencialmente entregable” no significa que deba entregarse realmente.
La entrega es una decisión de negocio que depende de diversos factores, como:
“¿Tenemos suficientes funcionalidades nuevas o suficiente valor para el cliente?” o
“¿Pueden nuestros clientes asumir otro cambio si les entregamos una actualización hace apenas dos semanas?”.
“Potencialmente entregable” debe entenderse más bien como el grado de completitud real alcanzado durante el Sprint.
Es decir, no debe quedar ningún trabajo importante pendiente (como pruebas o integración) que deba completarse antes de que el incremento pueda entregarse.
La Definition of Done no es estática; al igual que otros aspectos de Scrum, debe revisarse y ajustarse regularmente.
En la práctica, muchos equipos van evolucionando su Definition of Done con el tiempo, adaptándola a su madurez y contexto.
Revisión del Sprint (Sprint Review)
Al final de cada Sprint se llevan a cabo dos actividades de inspect and adapt.
Una de ellas es la Sprint Review.
El objetivo de esta actividad es revisar y adaptar el producto desarrollado.
Una parte fundamental de la revisión es la comunicación entre el equipo Scrum, los stakeholders, patrocinadores, clientes y miembros interesados de otros equipos.
El enfoque principal está en evaluar las funcionalidades recién completadas dentro del contexto del esfuerzo total de desarrollo.
Todos los participantes obtienen una visión clara del estado actual del producto y tienen la oportunidad de influir en los próximos pasos, contribuyendo así a encontrar la mejor solución para la organización.
Una revisión exitosa genera un flujo de información bidireccional:
las personas ajenas al equipo Scrum se informan sobre el progreso del producto y pueden aportar ideas para los próximos pasos,
mientras que los miembros del equipo Scrum adquieren una mayor comprensión de los aspectos empresariales y de marketing, gracias al feedback constante sobre si el producto está avanzando en la dirección que entusiasmará a los usuarios y clientes.
La Sprint Review es, por tanto, una oportunidad planificada para inspeccionar y adaptar el producto.
Además, personas externas al equipo Scrum pueden realizar revisiones de funcionalidades durante el Sprint y proporcionar comentarios, lo que ayuda al equipo a alcanzar su objetivo del Sprint.
Retrospectiva del Sprint
La segunda actividad de inspect and adapt al final de un Sprint es la Retrospectiva del Sprint, que se realiza regularmente después de la Sprint Review y antes de la planificación del siguiente Sprint.
Mientras que la Sprint Review se centra en revisar y ajustar el producto, la Retrospectiva del Sprint ofrece una oportunidad para revisar y mejorar el proceso.
Durante una Retrospectiva del Sprint, el equipo de desarrollo, el Scrum Master y el Product Owner se reúnen para analizar qué aspectos del trabajo con Scrum están funcionando bien y cuáles no.
El objetivo principal es la mejora continua del proceso, ayudando al equipo a evolucionar de ser un buen equipo Scrum a convertirse en uno excelente.
Al final de la Retrospectiva, el equipo Scrum debe identificar un conjunto concreto y viable de acciones de mejora, que se implementarán en el siguiente Sprint.
Una vez finalizada la Retrospectiva del Sprint, el ciclo vuelve a comenzar, iniciando con una nueva planificación en la que el equipo determina cuáles son las tareas más valiosas en las que enfocarse durante el próximo Sprint.
Descubre cómo los artefactos y las actividades en un equipo Scrum te ayudan a mejorar tu trabajo.
Si deseas profundizar en el mundo del Agile Leadership, te recomendamos nuestra certificación para líderes: Agile Leader.
Para los Scrum Masters, ofrecemos las siguientes formaciones y oportunidades de desarrollo gratuitas: