Los artefactos de Scrum son los tres documentos vivos que mantienen al equipo alineado: el Product Backlog, el Sprint Backlog y el Incremento.
Era martes por la mañana en las oficinas de una empresa de tecnología en Guadalajara. Sofía, Product Owner de un equipo de cinco personas, entró a la Daily Scrum con cara de confusión. Nadie sabía con certeza qué había quedado comprometido para ese Sprint. Un desarrollador estaba trabajando en una función que nadie había priorizado. Otro esperaba instrucciones que nunca llegaron. El Sprint llevaba tres días y el equipo ya estaba perdido.
¿Qué salió mal? No fue la falta de talento ni de esfuerzo. Fue la ausencia de artefactos bien construidos y actualizados. Cuando los artefactos de Scrum no existen o están desactualizados, el equipo navega sin mapa.
Los artefactos como sistema de navegación
Scrum define exactamente tres artefactos. No son reportes para la gerencia ni documentos burocráticos. Son herramientas de trabajo activas que el equipo consulta todos los días.
Cada artefacto responde una pregunta diferente. El Product Backlog responde: ¿qué queremos construir en total? El Sprint Backlog responde: ¿qué construiremos en este Sprint y cómo? El Incremento responde: ¿qué hemos entregado hasta ahora que funciona de verdad?
La relación entre los tres es secuencial. El Product Backlog alimenta al Sprint Backlog. El Sprint Backlog produce el Incremento. Y el Incremento se acumula Sprint tras Sprint hasta formar el producto final.
El Product Backlog: la lista maestra del producto
El Product Backlog es una lista ordenada de todo lo que el producto necesita. Lo mantiene el Product Owner y nunca está "terminado" mientras el producto exista.
Imagina que Liverpool lanza una nueva app de compras. Al inicio, el Product Backlog puede tener 40 elementos: registro de usuario, búsqueda de productos, carrito de compras, integración con OXXO Pay, notificaciones push, historial de pedidos, y decenas más. Con el tiempo, los usuarios dan retroalimentación, el mercado cambia y aparecen nuevas ideas. El backlog crece, se modifica y se reordena constantemente.
Lo que distingue al Product Backlog de una lista simple es el orden. El elemento más importante siempre está hasta arriba. El Product Owner decide ese orden basándose en valor para el negocio, riesgo técnico, dependencias y retroalimentación de usuarios.
Cada elemento del Product Backlog se llama Product Backlog Item o PBI. Los PBI más prioritarios deben estar detallados y listos para trabajarse. Los de menor prioridad pueden ser vagos por ahora, porque todavía cambiarán. Este proceso de refinar y detallar los PBI se llama refinamiento del backlog y es una actividad continua del equipo.
Un dato que sorprende a muchos: según estudios del Scrum Alliance, los equipos que refinan su backlog semanalmente completan un 30% más de trabajo por Sprint que los que no lo hacen. La claridad previa al Sprint Planning marca una diferencia enorme.
El Sprint Backlog: el plan del equipo para este Sprint
El Sprint Backlog es el conjunto de PBI que el equipo seleccionó para el Sprint actual, más el plan detallado para completarlos.
A diferencia del Product Backlog, que pertenece al Product Owner, el Sprint Backlog pertenece al equipo de desarrollo. Solo el equipo puede modificarlo durante el Sprint. Nadie más.
Volvamos a Sofía y su equipo en Guadalajara. Si hubieran construido bien su Sprint Backlog en el Sprint Planning, cada persona sabría exactamente qué tarea tiene asignada, qué dependencias existen y cuánto trabajo queda. El desarrollador que estaba trabajando en una función no priorizada habría visto que esa tarea no estaba en el Sprint Backlog. Habría parado y lo habría comentado en la Daily.
El Sprint Backlog tiene dos partes. La primera es la lista de PBI comprometidos para el Sprint. La segunda es el plan de trabajo: las tareas concretas que el equipo define para completar cada PBI. Esas tareas pueden durar horas, no días. Cuanto más pequeñas, más fácil es detectar bloqueos.
Una práctica muy común en México y en todo el mundo es usar un tablero Kanban para visualizar el Sprint Backlog. Las columnas típicas son: Por hacer, En progreso, En revisión y Terminado. Herramientas como Jira, Trello o incluso un pizarrón físico con notas adhesivas sirven perfectamente.
El Sprint Backlog debe actualizarse todos los días. Es el termómetro del Sprint. Si a mitad del Sprint el equipo ve que el tablero apenas avanzó, puede actuar antes de que sea demasiado tarde.
El Incremento: la prueba de que algo funciona
El Incremento es la suma de todos los PBI completados durante el Sprint actual más todos los Incrementos de Sprints anteriores. Y debe ser funcional y utilizable.
Esta es la parte que más confunde a los equipos nuevos. El Incremento no es "lo que alcanzamos a hacer". Es trabajo terminado según la Definition of Done del equipo. Si una función está programada pero no probada, no es parte del Incremento. Si un módulo funciona pero no está integrado con el resto del sistema, no cuenta.
Piensa en FEMSA desarrollando un sistema interno para gestión de inventarios en sus tiendas OXXO. Al final del primer Sprint, el Incremento podría ser: el módulo de inicio de sesión funcionando, con pruebas completas, integrado al sistema y listo para usarse. No es un demo. Es software real que alguien podría usar mañana si el negocio lo decide.
Esto es crítico: el Incremento debe estar potencialmente listo para liberarse al final de cada Sprint. No significa que siempre se libere. Significa que siempre podría liberarse. Esa disciplina obliga al equipo a no acumular deuda técnica y a no dejar trabajo "casi terminado".
Según el informe Chaos Report de 2020, los proyectos que entregan incrementos funcionales cada dos o tres semanas tienen un 42% más de probabilidad de terminar exitosamente. La frecuencia de entrega no es un capricho ágil: es una estrategia probada.
Errores comunes con los artefactos
El primer error es confundir el Product Backlog con una lista de tareas técnicas. Frases como "configurar servidor" o "migrar base de datos" no describen valor para el usuario. Los PBI deben expresar necesidades reales: "como comprador, quiero filtrar productos por talla para encontrar lo que necesito más rápido".
El segundo error es no actualizar el Sprint Backlog durante el Sprint. Si el tablero se ve igual el miércoles que el lunes, algo está mal. O nadie está trabajando, o nadie está registrando el avance. En ambos casos, la transparencia —uno de los pilares de Scrum— está rota.
El tercer error es aceptar trabajo "casi terminado" como parte del Incremento. Bimbo, por ejemplo, no sacaría al mercado un pan "casi horneado". De la misma manera, un equipo Scrum no debe incluir en el Incremento una función que le falta el 10% para estar lista. Ese 10% siempre cuesta más de lo esperado.
El cuarto error es que el Product Owner abandone el Product Backlog. El backlog no es un documento que se escribe una vez al inicio del proyecto. Es un organismo vivo que necesita atención constante. Un backlog desactualizado lleva a Sprint Plannings caóticos donde el equipo no sabe qué priorizar.
El regreso de Sofía
Dos Sprints después de aquel martes caótico, el equipo de Sofía adoptó una rutina diferente. Cada miércoles, dedicaban 45 minutos a refinar el backlog juntos. El Sprint Backlog se actualizaba cada mañana después del Daily Scrum. Y al final de cada Sprint, solo mostraban trabajo que cumplía su Definition of Done.
El resultado no fue magia. Fue estructura. El equipo comenzó a completar consistentemente lo que comprometía. La confianza entre Sofía y el equipo creció. Y los stakeholders del proyecto, que antes dudaban del avance, empezaron a ver Incrementos reales cada dos semanas.
Los artefactos de Scrum no son papeleo. Son el sistema nervioso del equipo: sin ellos, las señales no llegan y el cuerpo no puede coordinarse.