Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.
Comentarios: v01r02


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

Área de Gobernanza y Calidad

Contenido

Tabla de contenidos
maxLevel5
indent20px
exclude(Subdirección de las Tecnologías de la Información y Comunicaciones|Área de Gobernanza y Calidad)


Resumen
Sugerencia
  • Versión: v02r01 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.

Expandir
titleHistórico de cambios


Versiónv01r01Fecha publicación29 de Octubre de 2020Fecha entrada en vigor29 de Octubre de 2020
Alcance
  • Sprint Refinement: objetivo, contenido, agenda típica, responsabilidades, preparación de la sesión y buenas prácticas
Versiónv02r01v01r02Fecha publicación30 de Julio de 2021Fecha entrada en vigor30 de Julio de 2021
Alcance
  • Se alinea la nomenclatura utilizada con la Scrum Guide del 20 de Noviembre de 2020; sustituyéndose el término "rol" por el de "responsabilidades" y el de "equipo de desarrollo" por "desarrolladores"
  • Se añade el tema principal a tratar en forma de pregunta, como parte de los tres temas principales propuestos en la Planning, de acuerdo a la guía SCRUM del 20 de Noviembre de 2020




Introducción

Esta página pretende esclarecer los aspectos fundamentales de los refinamientos del Sprint (o Sprint Refinenement).



Objetivo

  • Backlog listo para sesión de Sprint Planning (cumpliendo DoR).

  • Dependencias y Riesgos identificados por adelantado.

  • Desarrolladores conscientes de próximas funcionalidades.



Contenido y Agenda típica

  • ¿Cómo se realizará el trabajo elegido? Planificar el trabajo necesario para crear un incremento que cumpla con el DoD.
  • Discutir las HU, escritas para los 2 próximos Sprints así como sus Criterios de Aceptación.

  • Identificar Riesgos y Dependencias que puedan impactar próximos Sprints.

  • Estimar las HU revisadas.







Responsabilidades

Responsabilidad ScrumDescripción
Proxy Product Owner
  • 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,…*
  • Establecimiento de prioridades entre Historias de Usuario y ayuda al entendimiento por parte de los desarrolladores de las mismas en caso de ausencia del Product Owner.
Scrum Master
  • 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,…
  • 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)
  • Recoger cualquier discusión/comentario relevante para el contenido de las Historias de Usuario, bien en JIRA o en Confluence dependiendo según sea pertinente.
  • Realizar resumen de acciones (minutas) para todas las HU que necesitan de inputs/acciones externas.
  • Asegurar alineamiento y entendimiento entre desarrolladores y el Product Owner (y/o con Proxy Product Owner).
  • Asegurar que dependencias y riesgos son identificados.
Desarrolladores
  • Pedir aclaraciones de alcance/visión de HU si fuese necesario para el correcto entendimiento del alcance.
  • Proveer estimaciones basadas en su entendimiento del nivel de complejidad y duración de cada HU.
Stakeholder OCA
  • Validación de criterios de aceptación en formato estructurado (Gherkin).
  • Revisión conjunta y de manera colaborativa con el equipo de las HUs para ayudar a que cumpla el DoR.
Product Owner
  • Asistir a Refinamientos para ayudar al entendimiento de las Historias de Usuario y criterios de aceptación por parte de los desarrolladores, así como establecimiento de prioridades entre Historias de Usuario.


(*) 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

InputDescripciónResponsable preparaciónFuente de informaciónCheckbox
Envío de convocatoriaEnví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 convocatoriaEn 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 ** 

Product Owner y Desarrolladores
  •   
Backlog estimado dos sprints por delante

Antes de cancelar una sesión de refinamiento, asegurar que el estado del backlog refinado cubre al menos dos sprints de adelanto.

En caso de que esto no fuese posible, se deberá señalar tanto a Product Owners como a Proxy Product Owners este hecho y alentar el refinamiento de mejoras con un carácter técnico.

Scrum Master ó

Proxy Product Owner **

Scrum Master ó

Proxy Product Owner **

  •   
Backlog priorizadoSe ha de asegurar que las Historias de Usuario han sido priorizadas, situándolas físicamente en los niveles más altos del Backlog en función de su prioridad

Proxy Product Owner

Product Onwer
  •   
Listado de Historias de UsuarioEl listado de Historia de Usuario se incluirá en la convocatoria o se señalará en el backlog de antemano, con el fin de que todos los interesados relacionados en la convocatoria puedan chequear y reposar su contenido antes de la sesión.

Scrum Master ó

Proxy Product Owner ** 

Product Owner y Proxy Product Owner (para HUs provenientes de la STIC)
  •   
Verificación de madurez mínima de Historias de Usuario

Deberá de asegurarse que las Historias de Usuario que se traten en el refinamiento tengan mínimo de madurez conceptual:

Proxy Product Owner

Proxy Product Owner junto con Product Owner

  •   
Chequeo de Historias de Usuario del Sprint en cursoAunque no es un patrón deseable si ocurre con frecuencia, en ocasiones puntuales los desarrolladores pueden requerir de clarificaciones adicionales con respecto a las Historias de Usuario del sprint en curso.Scrum MasterDesarrolladores
  •   



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




Buenas Prácticas

  • Mantener tiempos.

  • Asegurar buenas prácticas de escritura y gestión de Historias se están siguiendo.

  • Asegurar dependencias y riesgos son identificados.

  • Asegurar alineamiento y entendimiento entre los desarrolladores y el Product Owner.

  • Mantener un nivel apropiado de backlog: demasiado extenso y detallado VS el justo para dos iteraciones.

  • Asegurar que todos los miembros participan.

  • Invitar a Expertos y otras áreas en las que haya interdependencias.

  • Mantener la reunión en intervalos periódicos y regulares.

Anti-patrones

  • Llegar a una Sprint Planning sin que la mayoría de las HUs cumplan el criterio DoR.
  • No hacer consistentemente el Refinamiento del Backlog.

  • El equipo ve por primera vez HU durante la Sprint Planning.

  • Profundizar en cuestiones técnicas de una historia de usuario.