El equipo debe repasar la Vision de la solución y los Términos de Referencia en conjunto con el Scrum Product Owner para validar que aún mantienen vigencia las necesidades allí expuestas. El Scrum Product Owner puede dar más detalles en caso de ser requerido.

Luego de esclarecer la visión de la solución requerida, el Scrum Product Owner debe explicar lo que le gustaría que el equipo entregase en el próximo período, a menudo una cuarta parte del proyecto. Esto no debería ser una lista detallada de requerimientos. De hecho, es muy común que en las reuniones de lanzamiento ni siquiera se llegue a un nivel de historias específicas de usuarios individuales. Debe ser una descripción de alto nivel del trabajo que se realizará en el próximo período.

Es importante que el equipo genere una discusión de cómo el equipo definirá el éxito. Hay muchas formas válidas, como por ejemplo:

• ¿Liberaremos el producto durante este período? Idealmente, ¿con qué frecuencia? ¿Quizás incluso en qué fecha?
• ¿Qué será completamente desarrollado y entregado?
• ¿Qué se desarrollará lo suficiente como para que se pueda entregar un subconjunto?
• ¿Qué otros entregables se necesitan? ¿Hay documentos que deben actualizarse?
• ¿Qué nivel de calidad se espera? ¿El proyecto tendrá éxito, por ejemplo, si se cumple el plazo pero se cortaron algunas pruebas de bajo riesgo (según el equipo)?

A menudo hay algunos interesados del proyecto que colaboran en una comunicación específica, adicional o más personal. Y puede valer la pena identificar quiénes son y quién en el equipo se comunicará con ellos regularmente.

Más allá de decidir cómo será la comunicación con los que están fuera del equipo, esta primera reunión es un buen momento para discutir cómo los miembros del equipo colaborarán entre sí. Esto puede incluir lo siguiente:

• Acuerdos de trabajo que definen el comportamiento apropiado del equipo. Esto podría incluir si es importante llegar a tiempo a las reuniones, si está bien usar su teléfono móvil durante las reuniones, qué tan rápido se deben responder los correos electrónicos, etc. Cualquier respuesta a estos problemas puede estar bien siempre que los miembros del equipo lo acuerden.
• Qué herramientas usar para qué conversaciones. El equipo debe llegar a un acuerdo sobre qué tipos de debates son los más adecuados para el correo electrónico, las herramientas de mensajería como Slack, etc.
• Definir las políticas y las herramientas para el trabajo colaborativo. Para este punto sugerimos revisar la Guía para la gestión de versiones y definición de políticas de versionado.

También se sugiere acordar cuestiones específicas del proceso, como ser:

• La duración de los sprints.
• El día de la semana en que comienza el sprint.
• La definición del equipo de hecho (Definition of done)
• Cualquier límite de "trabajo en proceso"
• Otros

El equipo debe identificar los riesgos del proyecto y realizar un análisis de riesgos cualitativo para evaluar su orden de magnitud. El equipo debe decidir sobre los riesgos a los que deben responder y los riesgos que deben monitorear.

Las acciones ante los riesgos pueden incluir evitar o mitigar riesgos, explorar oportunidades o aumentar la probabilidad y los impactos positivos del riesgo. Como no es factible planificar respuestas para todos los riesgos identificados, el equipo puede decidir aceptar algunos de ellos. Los riesgos a observar se comunicarán a las partes interesadas y las acciones se determinarán solo si ocurren.

Consultar la guía para la gestión de riesgos para más detalles.

En algunos casos, dependiendo de la tecnología que se utilice y de los riesgos del proyecto identificados, podría resultar de utilidad esbozar un plan para las pruebas de desarrollo y pruebas UAT que incluya la forma de preparar los entornos de prueba y las estrategias de pruebas.

Para realizar estas actividades, puede ser útil revisar las actividades de Planificar las de pruebas del desarrollo y Planificar pruebas UAT del enfoque MCS-OpenUp.

Independientemente del grado en el cual se puedan planificar las pruebas, también es importante definir los ambientes con los cuales interactuará el equipo para la realización de las diferentes pruebas de la versión. Para esto, sugerimos revisar la Guia para la definición de ambientes.