¿Cómo realizar Sprint planning más efectivas?

¿Modifican el objetivo del sprint frecuentemente?...
‍Revisemos algunos datos que nos pueden ayudar a mejorar nuestro sprint planning.

1. Realizar una  preparación previa, es importante salir del espacio de la herramienta donde llevamos nuestro tablero y tengamos registradas nuestras historias (Jira, Trello, Azure, etc), para de esta forma incentivar la participación de toda la célula. Si nos encontramos de forma presencial, preparemos post its con nuestras historias y preparemos un panel en la pizarra donde toda la información necesaria se encuentre visible.  Por el contrario, si nos encontramos trabajando de forma remota entonces crear un tablero remoto (Mural, Miro, Jambo, etc. donde en post its escribamos posibles historias qué podríamos incluir).
   
   Es una excelente práctica en este mural, dejar visible la DoD, en ambos casos es muy importante incluir en un lugar donde todos puedan consultar de forma rápida y no tener dudas de lo que se necesita para dar un PBI por terminado.
   ‍
2. Una vez iniciada la sprint Planning el product owner propone cómo hacer más valioso este sprint, basado en sus últimas inspecciones, trae una propuesta para que sea discutida por todo el equipo, con todos los datos recolectados y de esta forma definir el objetivo del próximo sprint. Para que esto sea más fácil, es fundamental que el equipo haya participado en las reuniones de refinamiento y en las reviews del proyecto, que conozca la visión de producto para que pueda colaborar de forma objetiva en la elección del objetivo del sprint. Siempre tratar de asociar nuestro objetivo del sprint a un outcome de nuestro producto, de esta forma podremos identificar de manera más certera si cumplimos con nuestro objetivo del sprint.
   ‍
3. Luego de definido el objetivo, el equipo scrum irá revisando que PBI tomar y como esté agrega valor y ayuda a completar el objetivo. Es importante empoderar a los desarrolladores para que no se transformen en tomadores de pedidos y por el contrario sean capaces de cuestionar el valor e importancia de desarrollar un PBI.
   
   No olvidar, que deben ser los desarrolladores quienes definan cuánto trabajo realiza durante el sprint. El Scrum Master deberá velar porque esto ocurra.
   ‍‍
4. Definir el trabajo necesario para completar los PBI seleccionados de acuerdo a nuestra DOD. En ocasiones, como buena práctica se pueden priorizar las subtareas asociadas al PBI, así ayudamos a mantener el foco de nuestros desarrolladores.
   ‍
5. Finalmente, si bien esto no se menciona en la guía scrum, en mi experiencia lo recomiendo, es definir en conjunto con el equipo scrum, los posibles riesgos a los que nos podríamos ver enfrentados en la siguiente iteración.