Informe de Trazabilidad y Retroalimentación (RTF) de documentos SCRUM

Proyecto: Logbait

Repositorio: Enlace

---

1. RTF - Retrospectiva

Fecha: 14/11/2025

Base de Criterios: Criterios para la RTF

Revisora: Inés Pérez Herrera

---

1.1. Resumen de la revisión

El documento presente es complejo, detallado y resulta útil en el marco de la metodología SCRUM, presentando las siguientes fortalezas:

• ✅ Narrativa clara y cronológica del trabajo realizado.
• ✅ Detalles técnicos específicos y contribuciones individuales bien documentadas.
• ✅ Documentación de hitos significativos alcanzados.

Sin embargo, el documento aborda diferentes temas que son más propios del Review Sprint que de una Retrospectiva. En particular el documento no se ajusta a una Retrospectiva en los siguientes aspectos:

• ⚠️ No se ajusta a un marco metodológico propio de una retrospectiva: aunque no es obligatorio, seguir un marco, como por ejemplo el método estrella ("Start doing", "Keep doing", "More of", "Less of", "Stop doing") es muy útil para centrar el propósito de este documento.
• ❌ Ausencia de reflexión crítica estructurada sobre qué salió bien, qué no y por qué, en cuestión de personas, relaciones y procesos.
• ❌ No hay acciones de mejora concretas. En la retrospectiva del equipo, se identifican problemas que se han dado a lo largo del Sprint, pero no se aborda a qué se deben esos problemas, y cómo puede mejorar la dinámica del equipo en un futuro.

En definitiva, se recomienda recordar que el propósito del Sprint Retrospective es evaluar cómo funciona el equipo en cuanto a personas, relaciones, procesos y herramientas. Por ejemplo, cómo es la comunicación del equipo, qué aspectos de la metodología SCRUM se están aplicando bien y cuáles son mejorables, reflexiones sobre el trabajo en equipo, cómo de manejable está siendo la carga de trabajo... Es decir, el documento de Retrospectiva debe mantener el foco en procesos y colaboración, y debe evidenciar una reflexión por parte del equipo.

1.2. Evaluación por criterios de aceptación de la Retrospectiva

Criterio	Estado	Observación	Recomendaciones
Método de retrospectiva explícito	❌	No se especifica qué metodología se usa.	Utilizar la metodología Estrella (u otra similar) en futuros Sprints.
Qué salió bien, qué no salió bien	⚠️	El equipo identifica claramente bloqueos técnicos específicos. Reconoce logros significativos (multijugador funcional en producción). Documenta problemas reales en lugar de ocultarlos.	Incorporar este tipo de reflexiones de manera más explícita, también para los procesos y dinámicas de desarrollo en equipo.
Mejoras concretas	✅	El equipo identifica qué debe completarse/mejorarse (póker, Carreras de Caballos multijugador), demostrando capacidad de planificación futura.	Incorporar también mejoras para la capacidad de desarrollo del equipo (por ejemplo, mejorar la gestión de trabajo).
Seguimiento del sprint anterior	✅	Se explica qué logros se han conseguido en base al Sprint anterior.	Valorar también cómo ha sido la comunicación, gestión y capacidad de desarrollo del equipo nuevo Sprint en función del anterior.
Reflexión vs. lista	⚠️	Hay un gran detalle técnico en cada contribución, se identifica la dependencia entre tareas y la complejidad incremental.	Añadir reflexiones explícitas sobre por qué ha habido ciertas dificultades y cómo se pueden abordar. Por ejemplo: ¿por qué ha resultado complejo el póker? ¿Cómo han afectado a las dependencias de tareas a la gestión de la carga de trabajo del equipo?
Dinámicas de equipo (personas)	❌	No se menciona colaboración, conflictos o aprendizajes.	Añadir este tipo de reflexiones y análisis puede ser útil para mejorar la coordinación del equipo.
Análisis de procesos/herramientas	✅	Identifica problemas específicos y se demuestra proactividad en la resolución de conflictos.	Se recomienda mantener este nivel de detalle en el futuro.
Especificidad de acciones	⚠️	Las acciones futuras son genéricas ("póker en Sprint IV").	Reformular tareas pendientes con cómo se van a desarrollar. ¿Cómo se va a afrontar la deuda técnica en el futuro?

Comentarios: El documento presenta un detalle técnico y de avances satisfactorio, pero no cumple con la estructura ni el espíritu de una retrospectiva SCRUM. Es fundamentalmente un informe de progreso por integrante, por lo que considero que el documento sería más correcto en el contexto de una Revisión de Sprint, puesto que se abordan incrementos netos, avances, dificultades técnicas encontradas...

La información aportada es útil, pero el foco de este documento debería centrarse en las dinámicas del equipo.

1.3. Recomendaciones adicionales

Se recomienda incluir los avances de cada integrante como información adicional para complementar las Revisiones del Sprint, puesto que, como Revisión de proyecto, es un documento muy completo que cumple con los criterios de aceptación de este documento.

Por otro lado, la redacción de una Retrospectiva que cumpla con los siguientes aspectos será muy útil en el desarrollo Scrum del equipo. Para que la Retrospectiva cumpla con su propósito se recomienda seguir una estructura estándar, como la estrella de mar vista en clase, para mantener el foco de este documento:

• Start doing: Evaluar qué acciones de mejora se pueden tomar en este Sprint para mejorar el desarrollo del Proyecto. Identificar qué no se está haciendo pero podría ser beneficioso para el equipo. Estos puntos de mejora deben ser concretos y estar bien definidos, para que su aplicación real sea efectiva.
  • ¿Qué deberíamos empezar a hacer para mejorar?
• Keep doing: Valorar qué cuestiones han sido satisfactorias en este Sprint y cómo se pueden mantener en el futuro.
  • ¿Qué estamos haciendo bien y debemos continuar?
• More of: Identificar aspectos positivos que ya se están haciendo y que se pretenden mantener en el futuro.
  • ¿En qué áreas deberíamos invertir más tiempo, esfuerzo o recursos?
• Less of: Identificar qué aspectos han dificultado el avance del proyecto y cómo se pueden evitar.
  • ¿En qué áreas deberíamos reducir tiempo, esfuerzo o recursos?
• Stop doing: Identificar qué aspectos empeoran la dinámica de trabajo del equipo y cómo se van a dejar de hacer.
  • ¿Qué estamos haciendo que no funciona y debemos dejar?

Otros aspectos que podría ser interesante abordar en una Retrospectiva son: la velocidad de desarrollo del equipo, el tiempo de bloqueo, el número de impedimentos surgidos o la tasa de completitud de las historias de usuario marcadas como Done.

---

2. RTF - Review

Fecha: 15/11/2025

Base de Criterios: Criterios para la RTF

Revisora: Carla Tomás Aguilar

---

3.1 Revisión General

El documento informa y desarrolla de forma muy precisa y bien detallada los avances producidos tras cada sprint, pero desde la perspectiva de Scrum se acerca más a un informe de progreso que a una revisión, dado que falta mencionar y referenciar tanto el backlog como las tareas e historias de usuario que han ido siendo completadas. Haría falta un poco más de feedback. Aun así la calidad de la descripción de la implementación es alta, y muestra un trabajo significativo y progresivo a lo largo de cada sprint.

3.2 Evaluación por Criterios

3.2.1. Análisis del Sprint

Aunque se detalla perfectamente el progreso que ha tenido lugar durante cada sprint, sería necesario relacionarlo con las historias de usuario. Además de mencionar aquello que quedó incompleto, el motivo y otros problemas a los que se haya enfrentado el equipo durante el sprint.

3.2.2. Demostración o resumen de funcionalidades entregadas.

Dado que recientemente hemos comenzado a compartir los prototipos con los compañeros para recibir feedback y reaccionar a este, no considero que este sea un criterio evaluable por el momento.

3.2.3. Medidas o compromisos para próximos Sprints.

Se pueden intuir en la narrativa, aunque recomendaría mencionarlo de forma más clara y específica.

3.2.4. Expectativas y planes para el próximo Sprint.

Una vez revisado el sprint, es recomendable mencionar brevemente como se pretende abarcar el siguiente en base a lo sucedido durante el Sprint revisado. Es bien sabido que tanto la retrospectiva como el planning ya se encargan de esta tarea en detalle. Pero está bien reflejar como la revisión del Sprint da lugar a cierta reflexión.

3.3 Recomendaciones

Para mejorar la alineación con una Sprint Review, se recomienda añadir en futuras entregas mayor información sobre las historias completadas. Así como de aquellas que no lograron serlo, especificando las causas. Sería bastante valioso reflejar las dificultades a las que el equipo se ha ido enfrentando y reflexionar los cambios que se podrían llevar a cabo para evitarlas en otros Sprints. Incluso se podría comentar si el sprint se ha desarrollado como se esperaba previamente.

Dicho esto, considero muy de valorar la gran explicación y narración del progreso en cada sprint y eso es algo muy bueno a seguir manteniendo. Con eso y estos detallitos ya se acercará mucho más a una revisión característica de un Scrum.

---

3. RTF - Planning

Fecha: 14/11/2025

Base de Criterios: Criterios para la RTF

Revisor: David Morales Bravo

---

3.1 Revisión General

El Sprint Planning presentado contiene una descripción detallada de objetivos y tareas técnicas relevantes. No obstante, se identifican múltiples aspectos que requieren ajustes o mejoras formales para alinearse con las buenas prácticas de planificación ágil y con los criterios definidos para IS1. A continuación, se revisan punto por punto los criterios establecidos.

3.2 Evaluación por Criterios (siguiendo los citados al principio del documento)

3.2.1. Sprint Goal

• Estado: No Adecuado

• Observación: Aunque se expresan los objetivos del sprint, no se formulan como un Sprint Goal claro y conciso en una o dos frases.

• Recomendación: Reformular el Sprint Goal como una frase concisa y específica.

3.2.2. Relación con la Estrategia y el Product Backlog

• Estado: Adecuado

• Observación: Las tareas propuestas corresponden con una evolución clara del sistema y son coherentes con los objetivos globales del proyecto.

3.2.3. Estimaciones

• Estado: Ausente

• Observación: No se presentan estimaciones de esfuerzo (ni en horas, ni en puntos de historia).

• Recomendación: Incluir una tabla o lista con estimaciones por tarea para facilitar el seguimiento y control del sprint, junto con la estimación inicial de tareas en el sprint backlog.

3.2.4. Capacidad del Equipo

• Estado: Ausente

• Observación: No se especifica la capacidad de trabajo del equipo.

• Recomendación: Añadir un resumen de la capacidad y velocidad estimada con base en sprints anteriores y horarios de los desarrolladores previstos para el sprint.

3.2.5. Plan Tentativo de Trabajo

• Estado: Parcialmente Adecuado

• Observación: Las tareas están ordenadas temáticamente, pero no se explica cómo se distribuirán ni cuál será su secuencia lógica o dependencia.

• Recomendación: Dedicar un apartado incluyendo esta información.

3.2.6. Riesgos o Impedimentos Previsibles

• Estado: No Adecuado

• Observación: No se mencionan riesgos técnicos, de integración o de alcance, pese a que se abordan funciones complejas como el multijugador en tiempo real.

• Recomendación: Incluir al menos los riesgos identificados más importantes según la valoración en la gestión de riesgos del proyecto, citando su plan de mitigación.

3.2.7. Criterio de Aceptación Común / Definition of Done

• Estado: Ausente

• Observación: No se referencia una DoD común explícita.

• Recomendación: Citar directamente los puntos de la Definition of Done acordada para este proyecto.

3.2.8. Ajustes Derivados de Retrospectivas Anteriores

• Estado: Ausente

• Observación: No se hace referencia a problemas o aprendizajes de sprints anteriores.

• Recomendación: Incluir una sección breve al final con ajustes de planificación derivados de retrospectivas previas.

3.3 Conclusión

El Sprint Planning III cubre una gran cantidad de trabajo y muestra una intención clara de avance, sin embargo, requiere mejoras sustanciales para considerarse formalmente correcto según los criterios establecidos previamente.