Los artefactos de Scrum aportan transparencia y foco. Cada uno describe el trabajo pendiente, el trabajo planificado o el valor ya entregado, lo que permite tomar decisiones informadas sobre el progreso del producto.
El Product Backlog es la lista ordenada de todo lo que se conoce necesario para el producto. El Product Owner lo gestiona y ordena de acuerdo con el valor, el riesgo y la urgencia.
Guía práctica: mantener sesiones de refinement regulares con el equipo garantiza que el backlog esté listo al menos para los próximos dos sprints y evita sorpresas durante la planificación.
Ejemplo descriptivo: La empresa ficticia AgroSmart comercializa sensores IoT y servicios de datos para productores agrícolas; su Product Owner prioriza un portal que centraliza monitoreo y alertas para tomar decisiones en campo.
Especificación de Product Backlog: la siguiente vista muestra cómo AgroSmart ordena su backlog inicial combinando evidencias de adopción y riesgo técnico.
| Orden | Item | Tipo | Hipótesis de valor | Métrica |
|---|---|---|---|---|
| 1 | Como productor quiero ver alertas de humedad por parcela | Historia de usuario | Reducir pérdida de cosecha al anticipar riegos | Tasa de respuesta a alertas |
| 2 | Integración con pasarela de mensajería SMS | Mejora técnica | Asegurar cobertura en zonas sin datos móviles | Porcentaje de alertas entregadas |
| 3 | Definir protocolo de seguridad SOC2 | Tarea legal y de cumplimiento | Habilitar contratos con cooperativas reguladas | Checklist de auditoría aprobado |
| 4 | Pruebas de usabilidad con 5 clientes piloto | Investigación | Validar que la interfaz actual reduce tiempo de consulta | Net Promoter Score piloto |
| 5 | Automatizar despliegues de microservicios | Infraestructura | Disminuir fallas de publicación en un 80% | Tiempo medio de despliegue |
El Product Owner usa las sesiones de refinement para desglosar cada ítem, ajustar estimaciones y confirmar si las métricas siguen alineadas con los objetivos de negocio.
El Sprint Backlog se crea durante el Sprint Planning. Incluye el objetivo del sprint, los ítems seleccionados del Product Backlog y el plan de trabajo necesario para entregarlos.
Ejemplo AgroSmart: durante el Sprint 5 el equipo define el Sprint Goal "Validar alertas proactivas en campo" para confirmar que los productores reciben información accionable sin importar la conectividad.
Los Developers seleccionan ítems del Product Backlog y los descomponen en tareas visibles:
| Ítem del Product Backlog | Subtareas planificadas | Evidencia esperada |
|---|---|---|
| Alertas de humedad por parcela | Configurar reglas de disparo; construir vista de alertas en el portal; validar datos con clientes piloto | Usuarios piloto reciben alertas oportunas con ratio de lectura >80% |
| Integración con pasarela SMS | Implementar webhook bidireccional; pruebas de entrega en zonas sin datos móviles; ajustar costos con proveedor | Entrega de SMS con una tasa de éxito del 95% en ambientes de prueba |
| Automatizar despliegues de microservicios | Agregar pipeline de despliegue azul/verde; instrumentar monitoreo; plan de rollback documentado | Despliegues repetibles en <10 minutos sin intervención manual |
El tablero del Sprint se actualiza a diario; cuando la pasarela SMS requiere certificación adicional, el equipo coordina con el Product Owner para incorporar una tarea de compliance y el Scrum Master desbloquea la participación del área legal, protegiendo el Sprint Goal.
El Incremento es la suma de todo el trabajo completado durante el sprint más el valor de los incrementos previos. Debe estar en condiciones de uso, incluso si el Product Owner decide no liberarlo aún.
Para que un incremento sea aceptable, necesita cumplir con la Definición de Done (DoD). Esto asegura que el producto mantiene estándares de calidad y que no se acumulan tareas “casi terminadas”.
Incremento AgroSmart: al cerrar el Sprint 5 el portal ofrece alertas de humedad visuales y vía SMS, pipelines de despliegue automáticos y evidencias de cumplimiento disponibles para que el Product Owner decida su liberación.
La Definición de Done (DoD) es un acuerdo explícito entre los Developers y el Product Owner sobre el nivel mínimo de calidad requerido para considerar un ítem completado. Funciona como un checklist de verificación que evita ambigüedades y asegura que cada incremento sea realmente utilizable.
Una DoD clara responde a tres preguntas: ¿qué condiciones deben cumplirse antes de decir «listo»?, ¿quién verifica cada condición? y ¿en qué repositorio queda registrada la evidencia? Además, cubre tanto atributos funcionales (que el usuario percibe) como no funcionales (seguridad, rendimiento, mantenibilidad).
DoD AgroSmart: el equipo formaliza un checklist que combina los estándares globales de la compañía con acuerdos específicos del portal de alertas.
| Condición | Responsable | Evidencia |
|---|---|---|
| Pruebas automatizadas y revisión de código aprobada | Developers | Reporte CI en Jenkins y aprobación en pull request |
| Validación funcional en portal y SMS con clientes piloto | Product Owner + Developers | Registro de sesiones y feedback en Confluence |
| Checklist SOC2 y cifrado de datos en reposo | Equipo de compliance | Formulario SOC2 firmado y resultado de escaneo de seguridad |
| Documentación operativa y runbooks actualizados | Scrum Master + DevOps | Enlace a wiki actualizado y checklist de handover |
La DoD se revisa cada dos sprints en una sesión conjunta con los demás equipos de la compañía para homologar criterios y detectar nuevos requisitos regulatorios.
Consejo: cuando un ítem no cumple la DoD, debe volver al backlog con ajustes claros; “casi listo” no incrementa el valor del producto.
Scrum se sostiene sobre el pilar de la transparencia. Los artefactos deben reflejar la realidad para que la inspección y la adaptación ocurran a tiempo.
Transparencia AgroSmart: el equipo mantiene una radiografía diaria del portal y comparte el contexto con Product Owner, agrónomos y compliance para sostener decisiones rápidas.
Para documentar hallazgos de retrospectivas, el equipo recurre a técnicas como Start-Stop-Continue, 4Ls y Mad-Sad-Glad; cada enlace despliega una descripción más extensa en el diálogo reutilizable.
Stakeholder: cualquier persona u órgano con interés en el producto: clientes, usuarios finales, patrocinadores, áreas internas o entes reguladores. Su participación aporta contexto al Product Owner y ayuda a validar decisiones de valor.
Ejemplo AgroSmart: cuando la cooperativa Los Tréboles consulta por la postergación de una integración, el Product Owner comparte el registro de decisiones con la métrica de impacto y el requerimiento SOC2, manteniendo la confianza gracias a la transparencia del backlog.