Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Contenido
Resumen
- Versión: v01r02
- Fecha publicación: 30 de Julio de 2021
- Entrada en vigor desde: 30 de Julio de 2021
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.
Introducción
Esta página pretende esclarecer los aspectos fundamentales de la Sprint Planning.
Objetivo
Conocer el trabajo próximo: Para que los desarrolladores comiencen 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 desarrolladores 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, los desarrolladores resumen 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.
Los desarrolladores seleccionan las Historias de Usuario que van a implementar en el siguiente Sprint en función de su capacidad, tratando de abordar lo siguientes temas:
¿Por qué este Sprint es valioso? Definir un objetivo de Sprint que comunique por qué el Sprint es valioso para las partes interesadas.
¿Qué se puede hacer este Sprint? Seleccionar los elementos del Product Backlog para incluir en el Sprint actual.
Responsabilidades
| Responsabilidad SCRUM | Descripción |
|---|---|
| Product Owner |
|
| Proxy Product Owner |
|
| Scrum Master |
|
| Desarrolladores |
|
| Stakeholder OCA |
|
(*) En cada proyecto es importante que Scrum Master y Proxy Product Owner alineen conjuntamente quién gestionará la convocatoria. La persona finalmente encargada de gestionar la convocatoria deberá prestar especial atención a comunicar y gestionar 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 | Checkbox |
|---|---|---|---|---|
| Revisión de la agenda | Revisar la agenda de manera que se obtengan los resultados esperados de la sesión:
| Scrum Master ó Proxy Product Owner ** | Scrum Master ó Proxy Product Owner ** | |
| 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 las responsabilidades son correctamente delegadas, 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 a los desarrolladores 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 los desarrolladores, 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 | Desarrolladores |
(**) 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 resto del 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 una postura más técnica, en vez de la de facilitador 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)