Entregas y logros

¿Qué entregamos este sprint que aportó valor?

Lanzamos el nuevo flujo de onboarding antes de lo previsto y los registros ya están subiendo.
La investigación rápida que hicimos sobre el bug de pagos acabó en un arreglo limpio que redujo los tickets de soporte.
Cerramos la brecha en el traspaso de diseño a desarrollo y, por primera vez, entregamos con el diseño exacto desde el primer día.
Qué nos frenó

¿Qué bloqueos o fricciones nos quitaron velocidad?

Demasiados cambios de contexto entre proyectos, así que nunca llegué a concentrarme de verdad.
Estuvimos bloqueados dos días esperando a que otro equipo nos diera acceso a la API.
Como los criterios de aceptación no estaban claros, tuvimos que rehacer la funcionalidad dos veces.
Qué aprendimos

¿Qué nueva idea o aprendizaje validado obtuvimos?

En realidad los clientes no quieren más funcionalidades. Quieren menos y más claras.
Programar en parejas los tickets más difíciles nos ahorró tiempo en conjunto, no nos lo hizo perder.
Nos equivocamos con lo que suponíamos del uso en móvil; la mayor parte del tráfico viene de escritorio.
Pivotar o perseverar

¿En qué apostar más fuerte, qué cambiar o qué eliminar?

Perseverar con el trabajo de onboarding, porque los datos lo respaldan claramente.
Pivotar y dejar la funcionalidad para grandes empresas; nuestra tracción real está en las pymes.
Eliminar el informe semanal de estado que nadie lee y recuperar ese tiempo.

¿Qué es la retrospectiva de sprint de startup de Silicon Valley?

La retrospectiva de sprint de startup de Silicon Valley plantea la retro como lo haría el equipo de una startup. Se basa en el ciclo construir-medir-aprender del pensamiento lean startup, popularizado por Eric Ries en The Lean Startup: cada sprint se trata como un experimento, se analiza lo que realmente mostraron los resultados y se decide qué hacer a continuación a partir de esa evidencia. El tablero tiene cuatro áreas. Entregas y logros recoge lo que el equipo entregó y el impacto que tuvo en los clientes. Qué nos frenó cubre los bloqueos y las fricciones que os costaron velocidad. Qué aprendimos registra lo que suponíais y lo que dijeron los datos. Pivotar o perseverar es el momento de decidir: en qué apostar más fuerte, qué cambiar y qué eliminar. Encaja con equipos de producto, fundadores y equipos de innovación que quieren seguir avanzando sin perder el rumbo, y con cualquier equipo que tenga que decidir si continúa o no con un trabajo. Terminad con decisiones claras y un responsable para cada una, para que el siguiente sprint empiece con una dirección.

Formato de retrospectiva de sprint de startup de Silicon Valley

Entregas y logros

¿Qué entregamos este sprint que aportó valor?

Empezad por los logros: funcionalidades entregadas, hitos alcanzados y pequeños experimentos que salieron bien. Pide al equipo que piense como un fundador que mide la tracción. ¿Qué marcó la diferencia para el producto o para el cliente? Invita también a las personas más calladas a compartir sus pequeños logros.

Qué nos frenó

¿Qué bloqueos o fricciones nos quitaron velocidad?

Aquí el equipo pone nombre a los cuellos de botella, las dependencias y las distracciones que restaron impulso. Trátalos como frenos del sistema, no como culpa de nadie. Busca patrones que se repitan de un sprint a otro, porque arreglar uno de ellos suele ser lo que más compensa, y pregunta por qué ocurrió cada problema.

Qué aprendimos

¿Qué nueva idea o aprendizaje validado obtuvimos?

En esta área se recoge lo que el equipo aprendió este sprint sobre los clientes, el producto o la forma de trabajar. Plantea cada punto como una hipótesis: ¿qué suponíamos y qué nos dijeron los datos? Dejar por escrito lo aprendido hace que cada sprint se apoye en el anterior.

Pivotar o perseverar

¿En qué apostar más fuerte, qué cambiar o qué eliminar?

Este es el momento de decisión del fundador. Con lo que habéis entregado, aprendido y sufrido, ¿hacia dónde vais ahora? Anima al equipo a tomar decisiones claras: perseverar en lo que funciona, pivotar donde lo indiquen los datos y eliminar lo que no compensa. Asigna un responsable a cada decisión para que el siguiente sprint empiece con una dirección.

Cuándo utilizar este estudio retrospectivo

  • Al final de un sprint de producto, cuando quieres una revisión rápida y con la vista puesta en lo que viene.
  • Para equipos de startups, fundadores y equipos de innovación que quieren avanzar rápido sin perder de vista al cliente.
  • Cuando el equipo tiene que decidir si pivotar, perseverar o eliminar un trabajo.
  • Cuando vuestras retrospectivas se han vuelto rutinarias y un enfoque de construir-medir-aprender cambiaría la conversación.

Preguntas sugeridas para romper el hielo

  • Si vuestro equipo fuera una startup presentándose en un demo day, ¿cuál sería vuestro elevator pitch en una frase?
  • ¿La mentalidad de qué fundador tecnológico famoso te gustaría canalizar en este sprint y por qué?

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

  • Marca el tono desde el principio: se trata de aprender rápido, no de buscar culpables. La gente comparte más cuando equivocarse no supone un riesgo.
  • Usa el lenguaje de las hipótesis: ¿qué suponíamos y qué mostraron realmente los resultados?
  • Limita el tiempo de cada tema para mantener el ritmo. Una lista corta de puntos reales vale más que una exhaustiva.
  • En Pivotar o perseverar, insiste en decisiones claras con responsables, no en intenciones vagas.
  • Usa las aportaciones anónimas de TeamRetro para que la voz más fuerte no sea la que decida los logros y las decisiones.
  • Haz seguimiento de los bloqueos que se repiten entre sprints para detectar los problemas que merecen una solución de más calado.

Preguntas frecuentes

¿Cuánto dura una retrospectiva de sprint de startup de Silicon Valley?
La mayoría de los equipos terminan en 45 a 60 minutos. Limita el tiempo de cada tema para mantener el ritmo.
¿Cuándo debería usar este formato de retrospectiva?
Úsalo al final de un sprint o de un ciclo de producto, sobre todo cuando tu equipo trabaja en iteraciones rápidas y necesita decidir qué seguir construyendo y qué cambiar.
¿En qué se diferencia de una retrospectiva de sprint estándar?
Analiza el sprint desde las ideas de lean startup: valor entregado, aprendizaje validado y una decisión explícita de pivotar o perseverar. Una retro estándar suele quedarse en lo que fue bien y lo que no.
¿Qué significa «Pivotar o perseverar» en este contexto?
Es una idea de The Lean Startup, de Eric Ries. A partir de la evidencia, el equipo decide si mantiene el rumbo, cambia de dirección o abandona por completo un trabajo.
¿Este formato sirve para equipos que no son de una startup?
Sí. Cualquier equipo ágil, de producto o de innovación puede aprovechar su estructura centrada en las decisiones. El enfoque de startup aporta ritmo y mantiene al cliente a la vista.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva