Sprint Review: cómo obtener feedback del cliente
Contenido del curso
Diego Andrés Meléndez Orozco
Hugo Ocampo
Edwin Rivera Ballesteros
Ixcoatl Francisco Pérez
Fabrizio Hidalgo
Ixcoatl Francisco Pérez
Jorge Bernaola
Paola Restrepo Vargas
Ernesto Arturo Bonilla Ramos
Carlos Roberto Doblado Ochoa
Diego Diaz
ORLANDO ERNESTO ARBAIZA AVILES
Leonardo Ippolito
Hola! Alguien sabe como desactivar el sonido de las preguntas interactivas durante las clases? Agradeceria mucho esta informacion.
Me hice la misma pregunta, ese sonido me desconcentra demasiado y me hace perder el hilo del tema.
Genera una atmosfera de presion totalmente innecesaria.
¿Qué es y para qué sirve el sprint review?
El sprint review es una reunión colaborativa donde el scrum team y las partes interesadas inspeccionan el resultado del sprint y recogen feedback accionable. No es un reporte de estado: es un momento para observar el incremento, discutir lo aprendido y decidir próximos pasos ajustando el product backlog con base en esa retroalimentación.
¿Cuáles son sus características clave?
El qa tester es parte del grupo de desarrolladores en el scrum?
Hola, Fabrizio. ¡Excelente pregunta!
En Scrum, el término "desarrolladores" no se refiere solo a programadores de código. Se refiere a cualquier persona que realice el trabajo necesario para crear un incremento terminado en cada Sprint.
Por lo tanto, sí: un QA tester es parte del grupo de desarrolladores.
Como el equipo es multifuncional, el QA aporta su conocimiento especializado para asegurar la calidad, al igual que otros miembros aportan diseño, análisis o desarrollo de software. Todos comparten la responsabilidad de entregar un producto funcional y de valor.
Para profundizar en cómo se organiza este equipo, te recomiendo revisar:
¿Qué errores comunes debes evitar en sprint review?
La efectividad del evento se ve afectada cuando se cae en dinámicas de presentación unilateral o se muestran avances no listos. Evítalo así:
🧩 Ejemplo aplicado (App de idiomas)
En el Sprint Review:
Este tipo de sesión no solo valida el trabajo, sino que orienta el desarrollo hacia lo que realmente importa.
Un equipo no invita usuarios y pierde la oportunidad de obtener feedback valioso. Al mostrar código sin terminar, tampoco logra validar la usabilidad del producto.
¿Cuál es la mejor forma de recopilar feedback?
La mejor forma de recopilar feedback es mediante la observación directa y la escucha activa. No te limites a preguntar «¿Les gusta?», ya que la gente suele ser complaciente. En su lugar, plantea escenarios de uso reales.
Por ejemplo, diles: «Por favor, intenten cambiar su contraseña usando esta nueva pantalla». Mientras lo hacen, observa dónde hacen clic, si dudan o si se frustran. Complementa esta observación con preguntas de impacto: «¿Qué fue lo más confuso de este proceso?» o «¿Qué le falta a esta función para que la uses todos los días?». Además, es vital que el Product Owner centralice todas estas observaciones en un solo lugar, documentando no solo las quejas, sino también los descubrimientos de valor. Un buen feedback no es solo una lista de errores, es la materia prima para la innovación continua.
Incluso los equipos con experiencia caen en las mismas trampas. Detectarlas a tiempo protege el valor del evento.
• Convertir la sesión en una presentación unidireccional en lugar de un debate abierto.
• Mostrar un trabajo incompleto genera confusión y dificulta la obtención de comentarios útiles, ya que el producto aún no es utilizable.
• Realizar la revisión sin la participación de las partes interesadas anula por completo el propósito de inspeccionar la mejora con las personas que la van a utilizar.
En la compañia para la cual trabajo es poco común el feedback, y a veces se llega a sesiones de prueba donde el usuario desea cambiar algunas cosas, y es donde seria oportuno tener estos espacios de Sprint Review que permitan ajustar rumbo y features sobre lo analizado en las funcionalidades.
¿Con qué frecuencia pedir feedback?
el feedback en Scrum debería de darse continuamente, ya sea diario o semanal si se tiene una relación cercana con el Product Owner o un cliente interno. También debe darse al final de cada Sprint (de 1 a 4 semanas). Este es el momento donde el Equipo Scrum y los interesados revisan el Incremento de producto. Cuanto más alto sea el riesgo o la incertidumbre del proyecto, más cortos deben ser los Sprints para obtener feedback.
Métodos para recoger feedback
Scrum no indica una herramienta específica, pero sí sugiere dinámicas que fomenten la colaboración. Como por ejemplo:
En Scrum, el tiempo de entrega de un sprint es inamovible (time-boxed). Las modificaciones se gestionan a través del feedback en la Sprint Review, permitiendo inspección y adaptación del Product Backlog para el siguiente sprint, manteniendo la flexibilidad sin alterar el sprint actual, como se menciona en la clase.
