Introducción al marco de trabajo Scrum

Qué es Scrum

Cuando hablamos de Scrum nos referimos a un marco de trabajo en el que equipos interdisciplinarios pueden crear productos o desarrollar proyectos de una forma iterativa e incremental.

El marco de trabajo Scrum es el modelo de gestión de procesos ágil más aceptado y difundido mundialmente.

Scrum se basa en un proceso iterativo e incremental con entregas de valor temprana al cliente.

La clave del marco de trabajo Scrum es que en cualquier momento pueden surgir cambios importantes en las necesidades del producto.

Scrum se estructura en ciclos de trabajo llamados Sprints (también conocidos como iteraciones).

Manifiesto ágil

El manifiesto ágil está compuesto por Valores y Principios.

  1. Individuos e interacciones sobre procesos y herramientas
  2. Producto funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan establecido

Los principios del manisfesto ágil son:

  1. La mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de valor.
  2. Se acepta que los requisitos cambien, incluso en etapas tardías del proyecto. Los procesos Ágiles aprovechan el cambio para proporcionar una ventaja competitiva al cliente.
  3. Se entrega un producto funcionando frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y el equipo de proyecto trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se realizan entorno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de proyecto y entre sus miembros es la conversación cara a cara.
  7. El producto funcionando es la medida principal de progreso
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los sponsors, el equipo del proyecto e interesados deben ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores ideas, requisitos y diseños emergen de equipos auto-organizados
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Componentes del marco de trabajo scrum

Se suelen llamar “ceremonias” a las reuniones claves del sprint y son:

Reunión de Inicio de Sprint, Reunión de Planificación, Sprint Planning, Reuniones Diarias o Daily, Retrospectiva o Retro, también llamada cierre de sprint.

 

Planificación

La Planificación es una reunión de trabajo colaborativo cuyos objetivos son:

  1. Entender y determinar el trabajo que el Equipo se compromete a terminar en el Sprint.
  2. Definir cómo se va a realizar este trabajo.

La Planificación es la primera actividad de cada Sprint, y tiene una duración máxima fija acordada (time-boxed).

La Planificación se compone de dos sub-ceremonias, que pueden ser manejadas como reuniones separadas: la primera parte: el “Qué” y la segunda parte: el “Cómo”

Requisitos

  1. Contar con una planificación de alto nivel:
    Durante la Planificación, se va a determinar la planificación de un Sprint de duración corta (entre 1 y 4 semanas en general). Este Sprint suele ser parte de una entrega más grande, Release, fase o etapa de duración mayor (entre 3 y 6 meses en general).
  2. Contar con un Backlog de Producto refinado:
    El artefacto sobre el cual se basa la ceremonia de Planificación es el Backlog de Producto.

Backlog del producto

El Backlog de Producto es una lista ordenada de ideas para el producto, mantenidas en el orden en el cual se espera que se resuelvan. Es la fuente única desde la cual fluyen todos los requerimientos. Eso implica que todo el trabajo del equipo viene del Backlog de Producto. Por ejemplo, cada idea de funcionalidad, mejora, resolución de incidente, necesidad de documentación se deriva de un ítem del Backlog de Producto. Cada ítem del Backlog de Producto incluye una descripción y una estimación de alto nivel.

El Backlog de Producto puede empezar como una larga o corta lista, puede ser de muy alto nivel o muy detallado. Generalmente empieza como una lista corta y de muy alto nivel, y con el paso del tiempo se vuelve más larga y detallada. Los elementos que van a ser implementados próximamente suelen ser “refinados”: clarificados, mejor definidos, divididos en varios elementos más chicos, como parte de la actividad de Refinamiento de Backlog de Producto.

El Dueño de Producto es responsable de mantener el Backlog de Producto.

Historia de usuario

Una Historia de Usuario describe una funcionalidad que será de valor para un usuario o cliente.

Se suele emplear el siguiente formato para documentar la historia de usuario:

Como <rol>, puedo <funcionalidad>, para <beneficio de negocio>

Por ejemplo: “El usuario pepe registrado en el sitio de turismo online, quiere reservar nuevos viajes para que se actualicé su bonus.”

Otro ejemplo: “Como cliente de PelisOnline, quiero buscar películas por actor, para que pueda encontrar más fácilmente las películas que quiero alquilar.”

Historia de usuario metodología INVEST

I – Independiente: se trata de lograr historias de usuario lo más independientes entre sí, para poder construirlas en cualquier orden según las prioridades del negocio. No siempre es factible, pero es importante tratar de tener historias de usuarios lo más independientes posibles.

N – Negociable: Las historias de usuario deberían permitir al equipo negociar con el representante de negocio sobre el alcance detallado de la misma, para lograr una exploración conjunta de la funcionalidad y llegar a un acuerdo.

V – Valorable: A cada historia de usuario se debería poder asociar un valor claro para el negocio. Una historia de usuario con un valor de negocio ambiguo suele ser muy difícil de priorizar.

E – Estimable: Se debería poder estimar el esfuerzo necesario para construir la historia de usuario.

S – Pequeña: Se debería tratar de tener historias de usuario lo más pequeño posible, para facilitar su estimación y minimizar el tiempo de construcción correspondiente.

T – Testeable: Se debería tratar de tener historias de usuario que se puedan testear (verificar, validar) para asegurar su cumplimiento.

 

 

La Parte I de la Planificación se centra en “qué” es lo que el Dueño de Producto quiere que se desarrolle en el Sprint y “por qué” es necesario.

1. Definición de Sprint

El Scrum Master agenda o repasa con el Equipo y el Dueño de Producto las fechas claves del Sprint:

  • Inicio y fin del Sprint, y eventuales feriados o días que no se pueden contar en el Sprint.
  • Fecha, horario y lugar de las ceremonias de Reunión Diaria, Revisión y Retrospectiva.

2. Revisión de Elementos

El Dueño de Producto y el Equipo revisan los elementos de mayor prioridad del Backlog de Producto que al Dueño de Producto le interesa desarrollar durante este Sprint. Se discuten los objetivos, la motivación y el contexto correspondiente a cada uno de los elementos, de tal forma que el Dueño de Producto pueda transmitir al Equipo la visión del producto a desarrollar, y se aclaran todas las dudas que puedan surgir. Si no estuviera hecho anteriormente, se pueden definir criterios de aceptación para cada uno de los elementos.

3. Definición del Objetivo del Sprint

El Dueño de Producto y el Equipo pueden formular un objetivo del Sprint. Se trata de una declaración que resume la finalidad del Sprint, en el caso que este mismo tenga un tema central.

4. Estimaciones de Alto-Nivel

El Equipo determina una estimación de alto nivel de cada uno de los elementos del Backlog de Producto presentados, en el caso que no lo hayan estimado previamente (por ejemplo, en Sprints anteriores o en reuniones de Refinamiento de Backlog).

Una característica bastante común de las estimaciones en las metodologías ágiles es que sean relativas. Eso significa que no se busca una estimación universal de la complejidad o del esfuerzo de construcción un elemento del Backlog de Producto, sino una comparación de su complejidad

contra otros elementos conocidos. En particular no se busca una estimación en horas del esfuerzo de construcción del elemento, sino poder comparar su complejidad de desarrollo contra la de otros elementos. Para lograr este objetivo, se suele usar una unidad de estimación abstracta de comparación entre elementos, como por ejemplo el (Story Point).

Punto de historia (Story Point)

Un Punto de Historia es una unidad arbitraria pero fija que describe cuánto esfuerzo requiere un elemento del Backlog de Producto para ser entregado al cliente.

Esta medida relativa suele ser útil para pensar en forma más abstracta las estimaciones y compararlas contra elementos conocidos. La escala de Puntos de Historia y su correspondencia promedia con el esfuerzo son características propias de cada equipo de proyecto.

Se suelen usar técnicas de estimaciones como Planning Poker, T-Shirt Sizing, Wideband Delphi u otras.

5. Acuerdo Preliminar de Alcance

A partir de las prioridades expuestas por el Dueño de Producto en el paso 2. Y de las estimaciones definidas en el paso 4, el Equipo determina el alcance del Sprint: que elementos del Backlog de Producto se comprometen a terminar.

 

 

1. Identificación de tareas

El Equipo colabora para identificar todas las tareas necesarias para terminar cada uno de los elementos del Backlog de Producto comprometidos para el Sprint. Lo ideal es que cada tarea dure entre 1-8hs. División sub-tareas para mejor granularidad.

2. Estimación de tareas

El Equipo estima el esfuerzo requerido para cada una de las tareas identificadas. Se registra el esfuerzo en horas de cada tarea, y si fuera necesario se agrupa o se divide la tarea para llegar a la granularidad esperada.

3. Chequeo de Alcance

El Scrum Master ayuda al Equipo a realizar distintos chequeos para validar la factibilidad de cumplir con el alcance preliminar comprometido para el Sprint (por ejemplo, horas estimadas vs. horas disponibles del equipo).

Si fuera necesario se acuerda un cambio al alcance del Sprint con el Dueño de Producto.

De esta forma queda fijado el alcance del Sprint.

4. Armado Backlog de Sprint / Tablero de Sprint

En este paso, el Scrum Master ayuda al Equipo a terminar de registrar o armar el Backlog de Sprint / Tablero de Sprint.

 

Ejemplo de Tablero de Sprint

 

5. Asignación de Primeras Tareas

El Equipo determina en conjunto las primeras tareas que se van a realizar en las próximas 24h (o hasta la próxima Reunión Diaria), y se asignan las responsabilidades correspondientes.

Resultados

La Planificación genera un entendimiento común por el Equipo y el Dueño de Producto de la cantidad y complejidad de lo que debe completarse durante el Sprint. También genera el compromiso del Equipo entero de completarlo razonablemente (dentro de un rango de circunstancias racionales).

En cuanto a artefactos, estos resultados se reflejan en el Backlog de Sprint construido durante la Planificación, en particular por los elementos del Backlog de Producto elegidos para el Sprint, las tareas identificadas para terminar cada uno de estos elementos y sus estimaciones de esfuerzo restante asociadas.

Reunión diaria (Daily)

Objetivos

La Reunión Diaria o “Daily” es una reunión de equipo diaria muy breve cuyos objetivos son:

  1. Compartir en el equipo el avance del trabajo comprometido para el Sprint.
  2. Coordinar las actividades del equipo para terminar el trabajo comprometido para el Sprint.

La Reunión Diaria tiene una duración máxima fija (time-boxed) de 15 minutos.

 

 

Requisitos

El éxito de la Reunión Diaria es fuertemente influenciado por el cumplimiento de los siguientes requisitos y preparaciones:

  • Contar con una Planificación del Sprint
    Para poder hacer la ceremonia de Reunión Diaria, es necesario haber realizado la ceremonia de Planificación al inicio del Sprint.En particular es fundamental contar con un Backlog de Sprint bien armado, que identifiqué claramente los elementos del Backlog de Producto comprometidos para el Sprint, las tareas necesarias para lograrlo y sus estimaciones de esfuerzo restante.
  • Contar con el espacio adecuado
    El horario de la ceremonia de Reunión Diaria debe ser fijo y acordado con anticipación. Es necesario contar con la presencia del Scrum Master y de todos los miembros del Equipo, con puntualidad, para poder mantener breve la ceremonia.


 

  • ¿Cuál fue mi avance desde la última Reunión Diaria? Se identifican las tareas involucradas terminadas, y eventualmente se re-estima el esfuerzo restante de las tareas en curso correspondientes.
  • ¿En cuales tareas me comprometo a trabajar hasta la próxima Reunión Diaria? Se identifican las tareas involucradas que pasan al estado “En curso”, se les asigna la persona correspondiente, y eventualmente se reestima sus esfuerzos restantes.
  • ¿Qué problemas tengo que me frenan o bloquean? Eventualmente se pide ayuda al Equipo para resolverlos.

Resultados

Los principales resultados a esperar de la ceremonia de Reunión Diaria son los siguientes:

  • El Equipo compartió su avance real entre si y hacía eventuales participantes presentes.
  • El Scrum Master detectó los principales impedimentos que frenan o bloquean el trabajo del Equipo.
  • El Equipo re-organizó el trabajo restante para poder cumplir con los compromisos del Sprint.
  • El Scrum Master identificó los puntos que ameritan reuniones adicionales (típicamente se pueden hacer justo después de terminar la Reunión Diaria).

Revisión o Demo

Objetivos

La Revisión es una reunión de fin de Sprint cuyos objetivos son:

  1. Demostrar concretamente y claramente el progreso del equipo.
  2. Recibir retroalimentación (feedback) periódica de los usuarios/clientes sobre los productos/resultados generados.

La Revisión es la penúltima actividad de cada Sprint, ocurre al final del mismo y tiene una duración máxima fija acordada.

 

 

Requisitos

  • Contar con una Planificación del Sprint
    Para poder hacer la ceremonia de Revisión, es necesario haber realizado la ceremonia de Planificación al inicio del Sprint.En particular es fundamental haber identificado claramente los elementos del Backlog de Producto comprometidos para el Sprint, y haber definido para cada elemento los criterios de aceptación correspondientes.
  • Poder mostrar el Incremento de Funcionalidad generado durante el Sprint
  • Contar con el espacio adecuado

Pasos:

  • Revisión objetivo del sprint
  • Demostración de Elementos de Backlog de Product
  • Actualización Backlog de Producto
  • Actualización Backlog de Sprint

 

 

Resultados

Los principales resultados a esperar de la ceremonia de Revisión son los siguientes:

  • Que todos los invitados a la Revisión tengan una medición concreta del avance del producto y una imagen clara de los resultados logrados en el Sprint.
  • Para cada uno de los elementos del Backlog de Producto comprometidos para el Sprint, una definición del Dueño de Producto, en la cual participan los otros participantes de la ceremonia: se acepta, se rechaza o se proponen mejoras.
  • Eventuales nuevos elementos de Backlog de Producto identificados.

Retrospectiva

Objetivos

  1. Escuchar distintos puntos de vista dentro del equipo sobre lo ocurrido en el Sprint.
  2. Identificar colaborativamente las causas de los principales problemas del equipo durante el Sprint.
  3. Idear, consensuar y seleccionar acciones de mejora concretas que pueda ejecutar el equipo en el próximo Sprint.

 

 

Requisitos

  • Haber terminado el Sprint y la ceremonia de Revisión
  • Contar con un Diseño de Retrospectiva
  • Contar con el espacio adecuado

Dinámica

  1. ¿Qué procesos de trabajo, interacciones o herramientas han funcionado bien en este Sprint?
  2. ¿Qué procesos de trabajo, interacciones o herramientas hay que mejorar?
  3. ¿Qué acciones de mejora concretas podría encarar el Equipo durante el próximo sprint para mejorar la situación?

Estructura

  1. Apertura
  2. Recolección de Datos
  3. Indagación
  4. Decisión
  5. Cierre

Resultados

  • Un entendimiento común de los principales problemas del Equipo.
  • Una lista de algunas acciones de mejora al alcance del Equipo a probar durante el próximo Sprint para intentar resolver algunos de los problemas detectados. Cada acción de mejora suele tener identificado uno o varios responsables, y eventualmente una fecha estimada de fin.

Herramientas de Scrum

Sprint 0

Es un Sprint inicial, previo a los sprints “normales” para preparar todo lo necesario para la ejecución de Scrum.

Objetivos

  • Acordar los roles y sus interacciones
  • Armar un plan preliminar de entregas
  • Preparar el ambiente de trabajo y sus herramientas
  • Consolidar un Backlog de Producto
  • Definir aspectos logísticos de los sprints (Duración, Ceremonias, etc.)
  • Comunicar el inicio del proyecto (Kick-Off)
  • Resolver aspectos técnicos con incertidumbre que puedan tener impacto en el proyecto
  • Definir la Visión del Proyecto

Es un Sprint inicial, previo a los sprints “normales” para preparar todo lo necesario para la ejecución de Scrum.

Sprint H

El Sprint H suele ocurrir luego de varios sprints “normales” (típicamente cada 4 a 10 sprints) para mejorar técnicamente el producto generado a través de pruebas, refactoring, documentación, capacitación, etc.

Objetivos

  • Pruebas que no fueron ejecutadas previamente
  • Corrección de defectos
  • Refactoring
  • Documentación para la entrega
  • Capacitación/soporte a usuarios – Armado final de la entrega

Aterrizaje de emergencia

¿Qué podemos hacer si en el medio del Sprint el equipo llega a la conclusión de que no podrán entregar nada o muy poco al final del mismo?

Recomendaciones

  1. Remover drásticamente impedimentos
  2. Solicitar Ayuda
  3. Reducir el alcance
  4. Cancelar el Sprint

Antes de cancelar el Sprint:

  • ¿Podemos cambiar algo en nuestra manera de trabajar?
  • ¿Realmente nadie externo puede ayudarnos?
  • ¿Podemos eliminar alguna historia o requisito del Sprint?
Compartir
Publicado el 19/08/2019
Daniel Minichiello Anderson
Project Manager

Ingeniero Electrónico egresado de la Universidad Tecnológica Nacional, con amplia experiencia en gestión de proyectos en diversas áreas de negocio, principalmente en los sectores aeroespacial, salud y energía, adquiridas durante 20 años, donde ha trabajado y vivido en Europa (Reino Unido y España). Se unió a la compañía hace dos años, donde se desempeña como Project Manager, gestionando proyectos para el área de gestión de contenidos, Datawarehouse y comercio electrónico, entre otros.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *