Qué es Scrum: sprint, roles y burndown en la práctica.

Scrum es un marco de trabajo para equipos que necesitan entregar resultados en ciclos cortos, aprendiendo con cada entrega. El equipo trabaja en periodos de duración fija, llamados sprints. Al comienzo de cada uno, elige qué va a hacer; al final, muestra lo que ha quedado listo y debate cómo mejorar. Todo ello con pocos roles, pocas reuniones y tres listas bien definidas.

Esta guía explica las piezas del Scrum en el orden en que aparecen en la rutina: valores, roles, eventos, artefactos, la diferencia entre épica, historia de usuario y tarea, estimación por puntos, velocidad y burndown. Al final, muestra cómo adaptar el método a equipos ajenos a la tecnología y cómo aplicarlo todo en la Tasskee.

Qué es Scrum y de dónde viene

El nombre está tomado del rugby: la formación en la que todo el equipo empuja a la vez para ganar el balón. La comparación aparece en un artículo de 1986, de Hirotaka Takeuchi e Ikujiro Nonaka, publicado en la Harvard Business Review, que describía equipos de desarrollo de productos trabajando de forma integrada, en lugar de pasarse el trabajo de departamento en departamento como en una carrera de relevos.

Ken Schwaber y Jeff Sutherland formalizaron Scrum para el software en la década de 1990 y lo presentaron públicamente en 1995. Desde entonces, el método se describe en la Guía de Scrum, un documento breve, gratuito y actualizado de vez en cuando. La versión de 2020, que sirve de base para este texto, hizo la guía todavía más ligera.

Un punto que la propia guía se encarga de decir: Scrum es un marco, no un proceso completo. Define las reglas del juego, pero deja que el equipo decida cómo trabajar dentro de ellas. Eso explica por qué dos equipos de Scrum pueden parecer muy distintos desde fuera.

Los tres pilares y los cinco valores

Scrum se apoya en la idea de que el trabajo complejo no se planifica entero de antemano: se aprende haciéndolo. Por eso hay tres pilares.

• Transparencia. El trabajo y su avance tienen que ser visibles para quienes se ven afectados por ellos. Si el estado real vive en la cabeza de una persona, no hay nada que inspeccionar.
• Inspección. A intervalos regulares, el equipo mira lo que se ha hecho y cuánto se ha avanzado hacia el objetivo.
• Adaptación. Si la inspección muestra que algo se ha desviado, el equipo ajusta lo que haya que ajustar, cuanto antes.

Los cinco valores describen el comportamiento que hace que esto funcione: compromiso, enfoque, apertura, respeto y coraje. En la práctica, se traducen en cosas concretas: el equipo se compromete con el objetivo del sprint, se concentra en él, habla abiertamente de los problemas, respeta la opinión de los compañeros y tiene el coraje de decir "esto no cabe".

Los roles del equipo Scrum

Scrum tiene tres roles, todos dentro de un único equipo. No existe jerarquía entre ellos: el equipo es pequeño, por lo general de pocas personas, y responde colectivamente del resultado.

Product Owner

Es quien responde del valor del producto y del product backlog, la lista de todo lo que se pretende hacer. Decide qué va primero y por qué. Habla con clientes, dirección y áreas internas, y lleva sus necesidades al equipo en forma de elementos priorizados. Es una persona, no un comité: alguien tiene que tener la última palabra sobre el orden del backlog, o todo se convierte en prioridad.

Scrum Master

Es quien se ocupa de que Scrum se entienda y se practique. No es el jefe del equipo ni "el jefe de la reunión". Ayuda al equipo a eliminar impedimentos, facilita los eventos cuando es necesario, protege al equipo de las interrupciones y enseña a la organización a trabajar con el método. Cuando el equipo madura, el trabajo del Scrum Master disminuye, y eso es una buena señal.

Desarrolladores

Son quienes hacen el trabajo de entregar el incremento. El nombre viene del contexto del software, pero se refiere a cualquier persona que produce el elemento: un diseñador, una redactora, un analista, una ingeniera. El equipo es autogestionado, es decir, decide internamente quién hace qué y cómo.

¿Y el director de proyecto?

Ese cargo no aparece en Scrum. Sus funciones se reparten: el Product Owner se ocupa de la prioridad y del valor, el equipo organiza la ejecución y el Scrum Master cuida el proceso. En las empresas que adoptan Scrum sin cambiar la estructura, el director suele asumir uno de esos roles o pasa a ocuparse de la cartera de proyectos y de la relación con la dirección.

Los cinco eventos de Scrum

Los eventos existen para crear ritmo y dar oportunidad de inspeccionar y adaptar. Los tiempos de abajo son límites máximos de la Guía de Scrum para un sprint de un mes; en sprints más cortos, los eventos suelen ser proporcionalmente más breves.

El sprint

Es el corazón del método: un periodo de duración fija, de un mes como máximo, en el que se produce un incremento utilizable. Durante el sprint, el objetivo no se modifica, la calidad no se reduce y el alcance puede renegociarse entre el Product Owner y el equipo a medida que se aprende más. La duración constante es una regla práctica importante: sprints de distinto tamaño hacen imposible comparar la velocidad de un ciclo con la de otro.

La planificación

Responde a tres preguntas: por qué este sprint es valioso (el objetivo del sprint), qué se puede hacer (los elementos elegidos del backlog) y cómo se realizará el trabajo (la división en tareas). El Product Owner trae los elementos más importantes; el equipo dice cuánto cree que cabe, basándose en la velocidad de los ciclos anteriores.

La reunión diaria

Son 15 minutos, a la misma hora y en el mismo lugar, para que el equipo ajuste el plan de las próximas 24 horas. El formato de las tres preguntas (qué hice ayer, qué haré hoy, qué me lo impide) es una convención antigua; la guía actual deja el formato libre, siempre que el foco sea el objetivo del sprint. Una buena daily no es un informe para el jefe: es el equipo conversando entre sí delante del tablero.

La revisión

No es una presentación formal. Es una conversación en la que el equipo muestra lo que ha quedado listo y las personas interesadas (cliente, dirección, otras áreas) opinan. El resultado alimenta el backlog: elementos nuevos, elementos descartados, prioridades revisadas.

La retrospectiva

Se centra en el proceso, no en el producto. El equipo responde a qué ha funcionado, qué ha estorbado y qué va a cambiar en el próximo sprint. El criterio de calidad es sencillo: se sale con una o dos acciones concretas, con responsable, y la siguiente retrospectiva empieza comprobando si se han hecho. Una retrospectiva que solo genera desahogo se convierte en una reunión vacía.

Los artefactos y sus compromisos

Los artefactos son las listas y los resultados que hacen transparente el trabajo. Cada uno tiene un compromiso asociado, que sirve para dar enfoque.

Product backlog

Es la lista ordenada de todo lo que se sabe que el producto necesita. Nunca está "terminada": evoluciona a medida que se aprende. Los elementos de arriba son pequeños y bien entendidos, porque se harán pronto; los del final son grandes y vagos, porque pueden cambiar hasta entonces. El compromiso asociado es el objetivo del producto, la meta a largo plazo con la que se mide el backlog.

El trabajo de mantener el backlog en orden se llama refinamiento. No es un evento obligatorio de Scrum, pero la mayoría de los equipos reservan un hueco semanal para dividir elementos grandes, aclarar dudas y estimar.

Sprint backlog

Es lo que el equipo ha tomado del product backlog para el sprint, más el plan de cómo hacerlo. Pertenece a los desarrolladores, que lo actualizan durante el sprint. El compromiso es el objetivo del sprint: una frase que explica por qué existe el ciclo, como "permitir que el cliente pague con PIX en el checkout". Si el alcance cambia durante el ciclo, el objetivo orienta qué se queda y qué sale.

Incremento

Es el resultado concreto y utilizable del sprint, sumado a los anteriores. No es "una parte del trabajo a medias": es algo que podría entregarse. El compromiso es la definición de terminado.

Definición de terminado

Es la lista de criterios que un elemento tiene que cumplir para considerarse concluido. Sin ella, "terminado" significa una cosa para el desarrollador, otra para el Product Owner y una tercera para el cliente. Ejemplo de definición de terminado de una agencia de marketing: texto revisado por otra persona, diseño aprobado por el cliente, enlace comprobado y pieza programada en la herramienta de publicación. Ejemplo de un equipo de software: código revisado, pruebas pasando, documentación actualizada y desplegado en el entorno de preproducción.

Épica, historia de usuario y tarea

Estas tres palabras aparecen en todo backlog y causan confusión. La forma más sencilla de entenderlo es pensar en tamaños. La sección siguiente resume la idea; el artículo Épica, historia de usuario y tarea profundiza con más ejemplos.

Ejemplo 1: tienda online

La Casa do Café, una tienda online de Pouso Alegre, quiere vender una suscripción mensual.

• Épica: suscripción mensual de café.
• Historias de usuario: "Como cliente, quiero elegir el tipo de grano y la frecuencia de entrega, para recibir el café como me gusta" y "Como cliente, quiero pagar la suscripción con PIX o tarjeta, para no depender de un solo medio de pago".
• Tareas de la primera historia: diseñar la pantalla de selección, crear el registro de los tipos de grano, programar el cálculo del envío, escribir los textos, probar en el móvil.

Ejemplo 2: RR. HH.

El departamento de personas de la Metalúrgica Serra Azul, en Sorocaba, quiere mejorar la incorporación de los nuevos empleados.

• Épica: incorporación de nuevos colaboradores.
• Historias de usuario: "Como nuevo empleado, quiero recibir el cronograma de la primera semana antes de empezar, para saber qué esperar" y "Como responsable, quiero una checklist de accesos y equipos, para que el nuevo compañero lo encuentre todo listo el primer día".
• Tareas de la segunda historia: identificar los accesos de cada área, montar la checklist, acordar el flujo con TI, publicar la plantilla en el sistema.

Cómo escribir una buena historia

El formato clásico es "Como [quién], quiero [qué], para [por qué]". Sirve para forzar la pregunta sobre el valor: si no consigues completar el "para", quizá el elemento sea una tarea disfrazada. Además del enunciado, una historia necesita criterios de aceptación, que dicen cuándo está cumplida. "El cliente puede pagar con PIX y recibe el correo de confirmación en menos de un minuto" es un criterio comprobable; "el pago funciona bien" no lo es.

Una prueba útil de tamaño: si la historia no cabe en un sprint, es una épica y hay que dividirla. Dividir por rebanadas verticales (una versión sencilla que funciona de punta a punta) suele ser mejor que dividir por capas (solo la base de datos, luego solo la pantalla).

Puntos y velocidad

Qué son los puntos de historia

Los puntos son una medida relativa de esfuerzo, complejidad e incertidumbre. En lugar de estimar en horas ("esto lleva 6 horas"), el equipo compara elementos entre sí: "esta es el doble de trabajosa que aquella". Las escalas más usadas siguen la secuencia de Fibonacci (1, 2, 3, 5, 8, 13), porque cuanto mayor es el elemento, más incierta es la estimación, y los saltos crecientes lo reflejan.

La ventaja de los puntos es que no prometen una precisión que no existe y no varían según quién ejecute. La desventaja es que son un concepto abstracto para quien está fuera; fuera de TI, muchos equipos prefieren estimar en horas o simplemente contar el número de elementos, siempre que tengan aproximadamente el mismo tamaño.

Planning poker, en una línea

Es una técnica para estimar en grupo: cada persona elige, en secreto, una carta con un valor, y todas las muestran a la vez. Si los valores divergen mucho, quien dio el mayor y el menor explica su razonamiento, y el grupo vota de nuevo. La ganancia está en la conversación, no en el número.

Velocidad

La velocidad es la suma de los puntos de los elementos concluidos en un sprint. Si el equipo cerró 21, 24 y 27 puntos en los tres últimos sprints, la media es 24. Para la siguiente planificación, el equipo toma en torno a 24 puntos, y no los 40 que sugiere el optimismo.

Tres precauciones evitan el mal uso de la velocidad:

• Solo vale lo concluido. Un elemento al 90 % cuenta cero. Eso incentiva terminar en lugar de empezar.
• No compares equipos. Un punto en el equipo A no es un punto en el B. La velocidad sirve para que el propio equipo prediga.
• No la uses como meta. Si la velocidad se convierte en exigencia, el equipo infla las estimaciones y el número pierde sentido.

Burndown: cómo leer el gráfico del sprint

El burndown muestra, día a día, cuánto trabajo falta aún en el sprint. El eje horizontal son los días; el vertical es el trabajo restante (en puntos, horas o número de elementos). La línea ideal baja desde el total hasta cero el último día; la línea real muestra lo que ha sucedido de verdad.

• Línea real por encima de la ideal: el equipo va retrasado respecto al plan.
• Línea real por debajo de la ideal: va adelantado, y quizá se pueda tomar algún elemento más.
• Línea recta durante varios días seguida de una caída brusca: el trabajo se está concluyendo en bloque al final, señal de elementos demasiado grandes o de un tablero poco actualizado.
• Línea que sube: ha entrado alcance nuevo a mitad del sprint.

El valor del gráfico está en avisar pronto. El miércoles de la primera semana, ver la línea por encima de la ideal aún da tiempo de sacar un elemento del alcance o de pedir ayuda. El artículo Burndown: cómo leerlo trae ejemplos de cada forma.

Scrum fuera de TI

El mecanismo de Scrum, que es ciclo corto, backlog ordenado, revisión y retrospectiva, funciona en cualquier área. Lo que suele salir mal es importarlo todo de golpe, con los nombres y la ceremonia. El artículo Sprints fuera de TI trata esto con calma; aquí va un resumen por área.

En una administradora de comunidades de vecinos de Porto Alegre, por ejemplo, el equipo de mantenimiento separó el trabajo en dos frentes: la cola de avisos del día a día sigue en flujo continuo, y la quincena se reserva para lo planificado, como pintar el garaje, cambiar bombillas por LED y revisar los extintores. La reunión de inicio de quincena elige los servicios; la de final comprueba lo que ha aprobado el administrador. No hay "Product Owner": prioriza la responsable de contratos. Funciona, y nadie ha tenido que memorizar el vocabulario.

Errores comunes al adoptar Scrum

1. Cambiar el alcance del sprint a cada rato. Si todo cambia a mitad de camino, es flujo continuo, y quizá Kanban sirva mejor.
2. Sprint sin objetivo. Sin una frase que explique por qué existe el ciclo, se queda en una simple lista de tareas.
3. Product Owner sin poder de decisión. Si toda prioridad necesita la aprobación de tres directivos, el backlog se atasca.
4. Scrum Master como jefe. Cuando reparte tareas y exige cuentas, el equipo deja de autogestionarse.
5. Backlog como trastero. Doscientos elementos que nadie lee. Descarta lo que no se va a hacer.
6. Terminado sin definición. Sin criterios claros, el elemento vuelve como retrabajo en el sprint siguiente.
7. Usar la velocidad para exigir. Existe para predecir, no para presionar.
8. Daily convertida en reunión de estado. Todos hablan con el jefe, nadie habla con el equipo.
9. Saltarse la retrospectiva. Es donde el equipo mejora. Sin ella, los mismos problemas se repiten en cada ciclo.
10. Sprint demasiado largo. Cuanto mayor es el ciclo, más tarde se descubre que se ha desviado.
11. Estimar en puntos sin entender el concepto. Si al equipo no le gustan los puntos, estima en horas o cuenta elementos.
12. Ignorar lo que se quedó fuera. El elemento que no se terminó vuelve al backlog y se reevalúa, en lugar de pasar automáticamente al siguiente sprint.

Cómo empezar tu primer sprint

1. Elige la duración. Dos semanas es un buen estándar. Fíjala y mantenla.
2. Reúne el backlog. Todo en un único lugar, en orden de prioridad, con los elementos de arriba bien descritos.
3. Define quién prioriza y quién dirige. ¿Quién es el Product Owner? ¿Quién facilita el proceso? Pueden ser personas con otro cargo.
4. Escribe la definición de terminado. De tres a cinco criterios bastan para empezar.
5. Planifica con holgura. En el primer sprint, toma cerca del 60 % de lo que crees que cabe. Estimar sin historial es adivinar; el primer ciclo sirve para crearlo.
6. Haz la daily y actualiza el tablero. Quince minutos, a la misma hora.
7. Cierra con revisión y retrospectiva. Sin ellas, es solo un calendario con un nombre bonito.

Después de dos o tres sprints, la velocidad empieza a tener significado y la planificación pasa a apoyarse en datos. La plantilla de backlog y sprint trae una hoja de cálculo rellenada para que la adaptes.

Scrum y Kanban juntos

Muchos equipos usan los dos: Scrum marca el ritmo (ciclos, planificación, revisión), y el tablero Kanban muestra el avance dentro del sprint, con límite de trabajo en curso en las columnas del medio. La guía de Kanban explica la otra cara. Una regla práctica: si tu trabajo se puede planificar por quincenas, usa sprints; si llega de forma impredecible y necesita respuesta rápida, usa flujo continuo; si es una mezcla, separa los dos frentes, como en el ejemplo de la administradora de comunidades.

Cómo hacerlo en la Tasskee

Los sprints de la Tasskee cubren el ciclo entero, del backlog al informe de cierre. Forman parte del plan Pro.

• Backlog. Las tareas que aún no han entrado en ningún ciclo quedan en el backlog, en orden de prioridad.
• Planificación del ciclo. Tomas del backlog lo que cabe en el sprint, con estimación y responsable, y cierras el alcance con todos viéndolo.
• Un sprint, varios proyectos. El mismo ciclo puede reunir tareas de proyectos distintos, que es como trabajan de verdad muchos equipos.
• Tablero del sprint. Las tareas del ciclo aparecen en el tablero Kanban, que se puede agrupar por responsable, prioridad o sprint.
• Burndown diario. Sigue el gráfico desde el primer día y descubre a mitad del ciclo, no la víspera, si va a dar tiempo.
• Velocidad. La media de los ciclos anteriores sirve de base para la siguiente planificación.
• Informe de cierre. Muestra lo que se planificó, lo que se completó y lo que volvió al backlog, sin borrar el historial.
• Números de flujo. Lead time, cycle time y flujo acumulado en los informes, para encontrar la etapa donde se atasca el trabajo.

Para que el equipo empiece con algo ya rellenado, usa la plantilla de backlog y sprint. Y si los ciclos tienen que impulsar objetivos mayores, enlázalos con las metas del trimestre.