Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Contenido

Resumen

Versión: v01r01
Fecha publicación: 29 de Octubre de 2020
Entrada en vigor desde: 29 de Octubre de 2020

Histórico de cambios

Los cambios en los estándares vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Versión	v01r01	Fecha publicación	29 de Octubre de 2020	Fecha entrada en vigor	29 de Octubre de 2020
Alcance
Sprint Planning: Objetivo, contenido, agenda típica, roles y responsabilidades, preparación de la sesión y buenas prácticas

Introducción

Esta página pretende esclarecer los aspectos fundamentales de la Sprint Planning.

Objetivo

Conocer el trabajo próximo: Para que el equipo comience con el trabajo que tiene por delante en las próximas 2/3 semanas, deben primero entender el alcance y tamaño de las HUs de mayor valor del backlog del producto (localizadas en la parte superior del mismo), con este entendimiento, eligen qué HUs se ajustan al sprint (idealmente ya debe haberse discutido previamente en el refinamiento), se desglosan las tareas relacionadas con las diferentes HUs (si el equipo lo conviene necesario) para que finalmente cada miembro sea capaz de ofrecerse voluntario para cubrir dichas tareas según el sprint progresa.
Empezar un nuevo ciclo: Independientemente de cómo se haya terminado el anterior sprint, el equipo comienza un nuevo ciclo, un nuevo sprint. Por ello es importante afrontar el nuevo sprint con un aire renovado basado en los compromisos y acuerdos obtenidos por el equipo durante la retrospectiva del sprint anterior.
Compromiso con unos objetivos comunes del sprint: Todos los miembros del equipo deben de entender todo el alcance del sprint y conjuntamente comprometerse a completar las Historias de Usuario seleccionadas para el sprint. Para crear foco y dirección, el equipo resume el alcance planificado con unos objetivos para el sprint (generalmente de 2 o 3).

Contenido y Agenda típica

El Product Owner da la visión del producto y prioridades para el siguiente SPRINT.
El equipo de desarrollo selecciona las Historias de Usuario que van a implementar en el siguiente Sprint en función de su capacidad.

Marco de gestión ágil en el SAS > Sprint Planning > image2020-8-17_13-44-2.png

Roles & Responsabilidades

Rol SCRUM	Descripción
Product Owner	Asistir al Sprint Planning y establecer la visión del producto para el siguiente SPRINT así como de establecer prioridades.
Proxy Product Owner	Acudir al Sprint Planning y brindar apoyo para establecer la visión del producto para el siguiente SPRINT así como brindar apoyo a establecer prioridades entre los diferentes interesados del proyecto (STIC y otros interesados). Facilitación de la sesión (mantener tiempos, mantener el foco de la sesión, asegurar que las acciones y decisiones quedan grabadas, incentivar la participación de todo el mundo, etc) * Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… *
Scrum Master	Facilitación de la sesión (mantener tiempos, mantener el foco de la sesión, asegurar que las acciones y decisiones quedan grabadas, incentivar la participación de todo el mundo, etc) * Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… * Asegurar cumplimiento con el DoR de todo el alcance del Sprint. Asegurar que el equipo conoce de antemano su disponibilidad para el próximo Sprint, incluyendo indisponibilidades por vacaciones, formaciones, etc. Asegurar disponibilidad de los recursos provenientes del proveedor de desarrollo (por ejemplo: si se requiere de un arquitecto por parte del proveedor para un sprint, el Scrum Master deberá garantizar que este estará disponible para ejecutar dicho sprint). Actualización en Confluence de la planificación del Sprint.
Equipo de desarrollo	Comunicar la capacidad individual disponible al Scrum Master. Selección de las historias de usuario de acuerdo a capacidad disponible.
Stakeholder OCA	Verificación de que las US que se van a incluir en el Sprint cumplen el DoR.

(*) En cada proyecto es importante que Scrum Master y Proxy Product Owner alineen conjuntamente cuál de estos dos roles gestionará la convocatoria y facilitará la sesión. Es importante notar que la persona finalmente encargada de gestionar la convocatoria, deberá prestar especial atención a preparar una agenda relevante para la sesión además de evaluar, comunicar y coordinar proactivamente posibles disrupciones que comprometan la sesión (p.ej. falta de asistencia de invitados clave, urgencias, etc)

Preparación de la sesión

Input	Descripción	Responsable de la preparación	Fuente de información
Envío de convocatoria	Envío con suficiente antelación de la convocatoria, asegurando la relevancia de la lista de invitados a la sesión	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **
Gestión de la convocatoria	En caso de avisos de no asistencia o indisponibilidad, se deberá gestionar de manera proactiva la convocatoria para asegurar que se mantiene la eficiencia de la misma (p.ej. buscando fecha alternativa, asegurando que los roles y responsabilidades son correctamente delegados, etc)	Scrum Master ó Proxy Product Owner **	Interesados relevantes del Sprint
Prioridades del proyecto	Asegurar que las prioridades del proyecto se han comunicado de manera concisa y se han alineado entre los Product Owners de antemano	Proxy Product Owner	Product Owner y Proxy Product Owners
Backlog priorizado	Se ha de asegurar que las Historias de Usuario prioritarias han sido efectivamente priorizadas, situándolas físicamente en los niveles más altos del Backlog en función de su prioridad	Proxy Product Owner	Product Onwer
Cumplimiento de DoR	Antes de cerrar la planificación se ha de asegurar el cumplimiento del DoR, con especial énfasis en la gestión de dependencias.	Scrum Master	Scrum Master
Asegurar asistencia de interesados relevantes externos al proyecto	Identificar de manera proactiva todas aquellas dependencias con otras áreas externas al equipo de desarrollo y asegurar que, en caso de que se prevea necesaria la colaboración de interesados externos al equipo durante el sprint, estos asistan a la sprint planning o en su defecto hayan sido informados de las expectativas hacia ellos para el próximo incremento	Scrum Master ó Proxy Product Owner **	Scrum Master y Proxy Product Owner
Confirmar disponibilidad de recursos externos del equipo dentro de la propia factoría de desarrollo	En caso de requerirse de perfiles adicionales dentro la factoría de desarrollo que son externos al equipo de desarrollo, se ha de asegurar la disponibilidad de los mismos	Scrum Master	Scrum Master
Cálculo previo de capacidad del equipo	Cálculo de la capacidad efectiva del equipo para el sprint, asegurando que se ha tenido en cuenta el impacto de cualquier evento no relacionado con el sprint (vacaciones, formaciones, etc)	Scrum Master	Equipo de desarrollo
Preparación de la agenda	Preparación de la agenda de manera que se obtengan los resultados esperados de la sesión: Asunciones del Sprint Cumplimiento DoR del alcance del Sprint Backlog del Sprint Objetivos del Sprint Estrategia de gestión de riesgos del Sprint	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **

(**) Scrum Master ó Proxy Product Owner según se convenga para cada proyecto.

Buenas Prácticas

Mantener tiempos.
Facilitar buena comunicación entre Product Owner y el Equipo.
Asegurar que los objetivos del SPRINT fijados son relevantes para el Product Owner.
Asegurar que el equipo conoce su disponibilidad de antemano.
Asegurar que las historias planificadas cumplen con los criterios DoR fijados por OCA.
Asegurar que el equipo se compromete con los objetivos del SPRINT.
Asegurar que el equipo no se ve influenciado para comprometerse en exceso.
Desafiar al equipo a superarse en cada Sprint.
Asegurar que los elementos de mejora identificados en las retrospectivas se ponen en práctica.
Asegurar que se reserva tiempo para resolución de Deuda Técnica.

Anti-patrones

Entrar en profundas discusiones técnicas.
El compromiso del equipo no es realista.
La velocidad y la capacidad sean exactamente iguales.
El Scrum Master asume un rol más técnico que un rol de facilitación de la sesión.
El equipo se compromete por debajo de su capacidad por miedo al fracaso.
No se reserva tiempo para actividades de soporte (gestión de actividad no planificable)