Facilitación de Sprint Planning

Hola, mis notas de la clase

Facilitación de Eventos de Scrum

Sprint Planning

1. Actividad de Check-in: Permite roper el hielo con el equipo para que esten concentrados , no mas de 5 min.
2. Acordar el objetivo del Sprint: Que el Product Owner explique el objetivo del sprint
3. Presentación de las prioridades: El Product Owner presenta la lista de prioridades que se van a atacar de mayor valor a menor valor
4. Definir compromisos del Sprint: El developer team definen los compromisos que van a asumir en el sprint. El compromiso va de los que genera mas valor en lugar de los mas facil de desarrollar
5. Refinar prioridades y estimar: Refinamiento del backlog
6. Conversación estratégica.: El developer team acuerdan de que forman van a trabajar las actividades que acaban de comprometer, esto deriva en el sprint backlog
7. Feedback y cierre: Cerrar la reunion teniendo en cuenta que pueden mejorar para el siguiente sprint planning

Facilitación de Sprint Planning:

Estructura de un buen Planning: 
[
	Actividad de Check-in,
	Acordar el objetivo del Sprint,
	Presentacion de las prioridades,
	Definir compromisos del Sprint,
	Refinar prioridades y estimar,
	Conversación estratégicas,
	Feedback y cierre
]

Facilitación de Sprint Planning:
Objetivo de este evento: adaptar el producto de cara al siguiente sprint, a través de incrementos y compromisos del equipo, para adaptar e producto.
.
estructura sprint planning:

1. actividad check-in o rompe-hielo (traer las mentes al espacio)
2. Acordar el objetivo de sprint. El product owner comparte su visión del siguiente sprint y en conjunto todo el equipo define el objetivo.
   el Product Owner no debe estar sobre los demás ni llegar a imponer.
3. Presentación de prioridades: el product Owner presenta el backlog de mayor valor a menor valor.
4. Definir compromisos del sprint: los developers son quienes definen los compromisos del sprint. //no necesariamente lo más fácil es lo más valioso, los developers deben comprometerse con lo que genera más valor hasta lo que genera menos valor.
   “5. es mejor refinar las prioridades antes de la sprint planning.”
5. Conversación estratégica: Aquí los developers conversar para definir de que forma harán el trabajo al que se acaban de comprometer. (esto deriva en el sprint backlog)
6. Feedback y cierre: que se puede hacer mejor para que la próxima sprint planning sea mas eficiente (cudando el objetivo de la sprint planning)

Estas serían mis acciones para atender los antipatrones establecidos en el pyecto dle curso:

1. Conversar con el Product Owner y con todo el equipo para enseñarles como funciona la metodología Scrum, y que así cada uno conozca el rol y las actividades que desempeña dentro del equipo para obtener un progreso y resultado éxito al concluir el proyecto.

2. Explicar a los desarrolladores que durante los Dailys Scrum deberían conversar sobre sus avances y limitaciones para avanzar, no detallar sobre cada actividad que realizan, de esta forma se puede visualizar el progreso que se está obteniendo y presentar soluciones para aquello que se vuelve una limitación.  Sugiriendo un mínimo de 2 a 5 minutos para la intervención de cada persona.

3. Conversar con el product Owner para que tome conciencia de que es importante que  el Product Backlog sea accesible para todos los actores involucrados, ya que de esta forma todo el equipo Scrum puede planificar el sprint planning, que al final debe tener un objetivo claro definido. También explicar qué es el equipo de desarrolladores quién define y ejecuta que items se van a desarrollar en cada Sprint.

4. Explicar al equipo del Definition Done para evitar ambigüedades o suposiciones, y que cada tarea realmente sea llevada a cabo como se espera para avanzar.

5. Invitaría a los skateholders a una reunión previa para que conozcan cómo funciona el proceso de desarrollo. También a los Sprint Review para que conozcan los avances, den opiniones y sugerencias, evalúen lo que se ha hecho hasta ahora y se pueda avanzar sabiendo que se han ido cumpliendo las expectativas o que hay algo que cambiar.

Hola a tod@s

De acuerdo al ejercicio planteado, les comparto lo que haría como SM para intervenir en el equipo del caso de estudio y hacer que su sprint planning sea mas eficiente:

1. Facilitar espacios de relacionamiento entre el PO y los developers dado que tienen una relación distante.
2. Orientar al PO sobre la distribución del trabajo entre los Developers ya que esta actividad debe realizarse en común acuerdo con el equipo y no por delegación del PO.
3. Capacitar al PO en el uso de herramientas de gestión agil que permitan la transparencia del product backlog y el trabajo colaborativo para la definición de historias de usuario y puntos de historia entre los integrantes del scrum team.
4. Orientar al PO sobre la definición de prioridades y la inclusión de nuevas características de ultima hora, esto genera desenfoque en el equipo de trabajo y puede generar reprocesos.
5. Facilitaría conversaciones con el presidente para que comprenda como funciona el marco de trabajo y la importancia de evitar incluir nuevas características “prioritarias” que retrasan la entrega y hacen menos productivo al equipo.
6. Capacitaria al equipo de trabajo en la estructura que se deberia manejar para el evento de Sprint Planning, con tiempos y objetivos definidos.

Saludos.
Magda 😉

Pre planning: Una sesión previa a la planning que permite la refinación de prioridades y estimaciones.

Clase 10: Facilitación de Sprint Planning

Características

• Estructura de un buen Planning, Es una forma pero no la única
  • Paso 1: Actividad de Check-in: Permite romper el hielo con el equipo para que esten concentrados , no mas de 5 min.
  • Paso 2: Acordar el objetivo del Sprint: Que el Product Owner explique el objetivo del sprint
  • Paso 3: Presentación de las prioridades: El Product Owner presenta la lista de prioridades que se van a atacar de mayor valor a menor valor
  • Paso 4: Definir compromisos del Sprint: El developer team definen los compromisos que van a asumir en el sprint. El compromiso va de los que genera mas valor en lugar de los mas fácil de desarrollar
  • Paso 5: Refinar prioridades y estimar: Refinamiento del backlog
  • Paso 6: Conversación estratégica.: El developer team acuerdan de que forman van a trabajar las actividades que acaban de comprometer, esto deriva en el sprint backlog
  • Paso 7: Feedback y cierre: Cerrar la Reunión teniendo en cuenta que pueden mejorar para el siguiente sprint planning

Notas

• PO debe presentar prioridades de la lista de mayor valor a menor valor.
• Aquí no pesa la voz de un desarrollador senior, es trabajo en equipo
• Se define el compromiso, el error que se comente es no hacer lo mas fácil primero y lo mas difícil después
• Recuerda se debe pesar el mayor valor para que lo developer puedan desarrollar
• Si en la Spring Planing hay que detallar o aterrizar muchas ideas se vuelva tediosa. hace que unas personas le tenga fastidio a este tipo de eventos

La conversación estratégica, es fundamental para la planificación 👍

Estructura de buen Sprint Planning:

• Breve apertura con conversaciones “rompe hielo”, para traer a cada individuo a integrarse al grupo.
• Revisar visión del PO del sprint
• Acordar el objetivo del sprint
• Presentar prioridades una vez refinado el backlog
• Definir compromisos del sprint.
• Refinar prioridades.
• Valorar si en vez de realizar las tareas más fáciles, se puede realizar lo que genera más valor
• Conversación estratégica
• Cierre con recomendaciones de mejoras y eficiencia.

**Estructura de Sprint Planning: **
1. Actividad de Check-in o rompehielos: Nos ayuda a maximizar las posibilidades de tener a los implicados muy presentes, enfocados y concentrados en lo que vayamos a trabajar y funciona porque muchas veces cuando asistimos a reuniones llegamos con situaciones de reuniones anteriores, con situaciones de estrés, preocupaciones, trabajos pendientes y muchas veces las personas pueden estar físicamente pero su mente en otro lado, como Scrum Master debemos asegurarnos de dar un lugar cómodo y traer la presencia a este espacio. Este espacio sirve para conocernos mejor, ver el estado de animo del equipo, pero no será el objetivo principal. Tiempo: 5 Minutos máximo
2. Acordar el objetivo del Sprint: El Product Owner comparte su visión para el siguiente Sprint y en conjunto todo el equipo define cual va a ser su objetivo como Sprint.
1. Anti-practica: Cuando el PO esta al nivel de jerarquía o posición por encima de los demás, llega a imponer su visión, imponer su vision de producto o prioridades, imponiendo tareas y actividades. Recordar Manifiesto de Metodología Agile: Colaboración con el cliente sobre negociación contractual, lo que significa que se debe buscar un ambiente de colaboración con el cliente y en este caso el equipo Scrum también debería colaborar desde su visión que es lo mejor de cara al siguiente Sprint.
3. Presentación de las prioridades: Una vez ya se tenga fijado el objetivo del Sprint el PO presenta al equipo el listado de prioridades, lo que se conoce como el Product Backlog priorizado por valor,
1. Anti-practica: Algunos PO presentan la lista del trabajo por hacer o la lista de características del producto pero en orden de llegada y no hacen el análisis exhaustivo de entender que es valioso realmente para el producto.
4. Definir compromisos del Sprint: Una vez teniendo las prioridades claras, se define los compromisos del equipo, en especial los developers, deciden que trabajo hacer. Entre ellos deben colaborar para definir que trabajo van a asumir para el siguiente sprint porque al final es responsabilidad de todo el equipo. La idea es que los desarrolladores se comprometan a realizar trabajo desde lo que genere más valor a lo que genera menos valor, debido a que suele pasar que algunos desarrolladores asumen las tareas más fáciles pero no suelen ser las que mas valor le dan al sprint.
5. Refinar prioridades y estimar: No incluir este paso en la Sprint planning si no es necesaria, solo si se debe si o si hacer debido a algún cambio de prioridad de ultimo momento debido a que algunas personas pueden empezar a ver este tipo de reuniones pesadas o con fastidio y la idea es que el equipo se mueva lo más eficiente posible. Lo que se hace acá es el proceso de refinamiento del Backlog.
6. Conversación estratégica: Conversación táctica donde en especial los developers conversan para ver acordar de que forma van a realizar el trabajo del que se acaban de comprometer.
7. Feedback y cierre: Conversar sobre que podemos hacer mejor para que la próxima sprint planning sea más eficiente, cuidando el propósito de la Sprint Planning, como por ejemplo: No tocar temas de estimación acá, o tampoco conversar sobre objetivos del Sprint.

Hola, mis notas:
Debemos ser muy efectivos en la Sprint Planning con el fin de que el Sprint Team no le coja pereza a estas sesiones de trabajo, se requiere que el equipo sea muy colaborativo, conversar y mirar que se puede mejorar para el siguiente Sprint.