Este ejemplo sigue a un equipo Scrum que trabaja durante dos semanas para entregar un incremento funcional en una aplicación de delivery.
El objetivo es mostrar, paso a paso, cómo se coordinan los eventos y artefactos de Scrum cuando se busca habilitar la toma de pedidos y notificaciones push para clientes finales.
15.1 Contexto: equipo desarrolla una app de delivery
La startup QuickBite quiere lanzar una app móvil que permita pedir comida en barrios de alta demanda. El equipo Scrum está compuesto por seis personas y trabaja con sprints de dos semanas.
- Product Owner: Sofía coordina con marketing y comercios asociados para priorizar el valor.
- Scrum Master: Luis elimina impedimentos y protege la cadencia del equipo.
- Developers: Ana (frontend), Javier (backend), Mariana (UX) y Pedro (QA y automatización).
Restricciones iniciales: la app debe integrarse con un servicio de envío de SMS y con un gateway de pagos que todavía está en certificación.
📋 Backlog previo al sprint
- Historia EPIC: como cliente, quiero registrar mi dirección y medio de pago para completar pedidos rápido.
- Historia: como cliente, quiero recibir una notificación cuando el restaurante confirme mi pedido.
- Historia: como restaurante, quiero ver pedidos entrantes en tiempo real para aceptarlos o rechazarlos.
- Spikes técnicos: evaluar latencia del proveedor de SMS y definir arquitectura de colas para eventos.
15.2 Sprint Planning: definir historias principales
El Sprint Planning se realiza en dos bloques de 90 minutos. Primero se aclara el objetivo y luego se decide qué trabajo cabe en el sprint.
- Objetivo del Sprint: permitir que usuarios coloquen pedidos completos y reciban confirmaciones instantáneas.
- Historias seleccionadas:
- US-31: captura de dirección y medio de pago dentro del flujo de checkout.
- US-34: microservicio de confirmación de pedidos con envío de notificación push.
- US-36: panel para restaurantes con estado "pendiente/aceptado" y acciones asociadas.
- CHORE-12: automatizar pruebas end-to-end del flujo de pedido básico.
- Plan de ejecución: se descompone cada historia en tareas técnicas, se identifican dependencias y se estima capacidad disponible.
El equipo usa el siguiente formato para alinear definiciones y criterios de aceptación:
{
"storyId": "US-34",
"objetivo": "Confirmar pedidos y notificar al cliente",
"criteriosAceptacion": [
"Cuando el restaurante aprueba el pedido se genera un evento",
"El evento dispara una notificación push y un correo de respaldo",
"Queda traza de la confirmación en el panel del restaurante"
],
"dependencias": ["Servicio de autenticación", "Proveedor de SMS"]
}
La Definition of Done del equipo incluye revisión de código por pares, pruebas automatizadas que pasen en CI y actualización del manual de usuario.
15.3 Daily Scrum: bloqueos detectados y resueltos
Durante el sprint se registran los bloqueos más relevantes y cómo se solucionan:
- Día 2: la API de pagos en sandbox devuelve errores 500. Luis coordina con el proveedor y se habilita un entorno espejo para continuar pruebas.
- Día 4: Mariana detecta que los mensajes push se duplican en Android. Javier ajusta el idempotency key del servicio de eventos y se agrega prueba automatizada.
- Día 7: Ana necesita assets de diseño para la pantalla de confirmación. Se acuerda una sesión de co-diseño de 45 minutos para destrabar el entregable.
- Día 9: Pedro reporta que las pruebas end-to-end tardan 18 minutos; se habilita ejecución paralela en el pipeline reduciendo el tiempo a 9 minutos.
Las dailies se mantienen en 15 minutos. Los temas que exceden ese tiempo se mueven a salas de enfoque (after party) con las personas involucradas.
📈 Burndown diario
El equipo monitorea el burndown junto con un diagrama de flujo acumulado (CFD). Se observa una caída repentina en la mitad del sprint cuando se libera la integración de pagos y se cierran cuatro tareas bloqueadas.
15.4 Review: demo del módulo de pedidos
Asisten stakeholders de marketing, operaciones y dos dueños de restaurantes piloto. La demo muestra:
- Flujo completo de pedido desde la app: selección de restaurante, dirección, pago y confirmación.
- Panel del restaurante con pedidos entrantes y botones de aceptación/rechazo.
- Notificaciones push y correo automático al cliente cuando el pedido es aceptado.
El feedback incluye mejoras menores: mostrar tiempo estimado de entrega en la notificación y agregar filtro por horario en el panel de restaurantes. El Product Owner incorpora estas ideas al Product Backlog.
Métricas compartidas: 92% de las pruebas automatizadas cubren el flujo principal, el tiempo promedio de respuesta del microservicio de confirmación es de 280 ms y no se registran errores en los logs desde el despliegue en staging.
15.5 Retrospectiva: mejora de tiempos de comunicación
La retro se estructura con la técnica "Mad, Sad, Glad" y finaliza con acciones concretas:
- Fortalezas: buena colaboración entre frontend y backend, y visibilidad constante del tablero.
- Dolores: respuestas lentas del proveedor de pagos provocaron re-trabajo.
- Ideas: establecer acuerdos de servicio internos y definir un canal único para escalar incidencias externas.
Acciones acordadas:
- Crear un checklist de integraciones críticas con contactos y tiempos de respuesta esperados.
- Asignar una guardia rotativa para seguimiento de dependencias externas durante el sprint.
- Refinar historias con stakeholders antes del Sprint Planning para reducir supuestos en criterios de aceptación.
15.6 Resultado del sprint
📱 Resultado: la app permite tomar pedidos completos, manejar la confirmación por parte del restaurante y enviar notificaciones inmediatas al cliente. El incremento queda listo para pruebas con clientes beta en la siguiente iteración.