Retrospectiva Sprint 2

Que salio bien

Se completaron 17 historias por 32 story points planeados, más 2 historias añadidas durante el sprint (34 pts realizados en total), cumpliendo el 100% del compromiso original. Se entregó el flujo end-to-end de reserva y pago en web y móvil (carrito con hold temporal, pago en dos fases authorize/capture, refund automático), y se inició el portal de gestión para hoteles con dashboard, reportes de ingresos, confirmación/rechazo de reservas y promociones. Se implementó por primera vez la arquitectura event-driven (saga por coreografía con 7 tipos de eventos, 3 workers y mensajería RabbitMQ/EventBridge), y el proveedor de pago se integró como mock adapter detrás de un puerto hexagonal, demostrando que la arquitectura permite intercambiar proveedores sin tocar la lógica de negocio.

Que no salio bien

Agrupar todos los flujos asincrónicos en un mismo sprint (PaymentRequested/Authorized/Failed, BookingConfirmed/Rejected, RefundProcessed, email de confirmación) generó interdependencia entre historias: varias compartían contratos de eventos y consumidores, lo que dificultó paralelizar el trabajo y obligó a coordinar PRs en orden. La estimación se quedó corta — la aparición de 2 historias durante el sprint y el hecho de que varias demandaron más tiempo del previsto sugiere que el refinement no capturó toda la complejidad, sobre todo en historias que tocaban infraestructura nueva (workers, mensajería, two-phase payment). El sprint se sintió bastante más pesado que el Sprint 1 a pesar de ser de tamaño similar (32 vs 34 pts), por la naturaleza transversal de la arquitectura event-driven que se introdujo de golpe.

Mejoras para Sprint 3

• Debemos refinar aún más las historias, detallarlas a más nivel de manera que podamos tener mucho más claro lo que se va a implementar.
• Distribuir mejor el sprint para que no tengamos tanta interdependencia.