Durante la Sprint Retrospective se han observado los siguientes aspectos:
Feedback reducido de stakeholders:
Si bien es cierto que la implicación del cliente es muy elevada y se preocupa por aportar cuanto sea necesario, a la hora de realizar las pruebas en el sistema es difícil encontrar un hueco. Pretendiendo que al menos cada actor realice cada uno de sus casos de uso en las distintas formas que proporciona la apliación, y dado el tiempo disponible del cliente, se puede considerar facilitar el acceso a la aplicación durante las pruebas a diplomados y deportistas para así poder conocer también los comentarios de los mismos y añadir las observaciones de los mismo que el cliente considere oportunas a la pila de trabajo. Se pretende facilitar el acceso al sistema en pruebas al menos a 2 diplomados y otros 2 deportistas para obtener su feedback.
Cierres de issues sin las pruebas adecuadas:
Se ha visto la necesidad en dos casos de reabrir un issue porque durante las pruebas de otro se ha detectado un fallo que afectaba directamente a los criterios de aceptación, lo que no hacía adecuado abrir un issue distinto como sí se ha hecho en otros casos. Por ello, se considera oportuno que durante la planning se especifiquen las pruebas que se van a realizar para el issue en cuestión, contemplando las distintas posibilidades que puedan afectar a la funcionalidad del sistema. Además, la falta de pruebas adecuadas ha generado issues con una carga de trabajo de casi el doble de las horas, porque si bien es cierto que los criterios de aceptación de los issues previos se cumplían, se producían errores o deficiencias que afectaban directamente al objetivo del sprint, por lo que era necesario solventarlas.