Diferencia entre revisiones de «Sesion De Ejemplo De Scrum»

Revisión actual del 16:23 11 ene 2011

Esta es la transcripción de una sesión de Scrum en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

Primera Reunión: Visión

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

• El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
• La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
• Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

Segunda Reunión: Exposición

Aquí el Dueño del Producto expone su Backlog Del Producto el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

Velocidad

Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el Scrum Master, los desarrolladores trabajarán 15 días ideales, el Scrum Master también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

Exposición de Historias

Y se genera el siguiente backlog de historias ordenada por importancia:

Backlog del Producto

• Pedido cambio plan - I=70
• Consulta de estado de pedidos - I=60
• Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

Cambio de Plan

• Pedido de cambio de Plan. - El Dueño del Producto cuenta la historia. -
  • El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
  • El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
  • Se verifica si el cliente está en condiciones de tomar este plan.
  • Se confirma la operación por parte del sistema

• Se preguntan los detalles convenientes para poder estimar la historia.
  • ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
  • ¿Cómo se identifica al cliente? Se explican las validaciones del mismo, para que pueda operar.
  • ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
  • ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
  • ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el Backlog Del Producto de esta manera, luego identificar la importancia de cada historia:

 Pedido cambio plan             - I=70
 Consulta de estado de pedidos  - I=60
 Pedido de Servicio             - I=50
 Modificar pedidos              - I=30
 Cancelar pedidos               - I=20
 Login                          - I=10
 Identificacion del cliente     - I=8
 Reset de la clave              - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.

• Se sugieren opciones:
  • Poner prioridad al Login
  • Usar un usuario ficticio hasta poder realizar la historia de Login
  • Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El Dueño Del Producto decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

 Login                          - I=100
 Identificacion del cliente     - I=90
 Reset de la clave              - I=80
 Pedido cambio plan             - I=70
 Consulta de estado de pedidos  - I=60
 Pedido de Servicio             - I=50
 Modificar pedidos              - I=30
 Cancelar pedidos               - I=20

Entonces se comienza nuevamente pidiendo al Dueño Del Producto que exponga la historia Login

Login

• Login -El Dueño Del Producto cuenta la historia-
  • El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
  • Si pasa correctamente el sistema le muestra el menú del sistema.
  • Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.

• No hay detalles a preguntar por parte del equipo.

Cambio de Plan (2)

• Cambio de Plan -El Dueño Del Producto cuenta la historia-
  • Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
  • Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
  • Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
  • Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
  • Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
  • Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
  • Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
  • Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
  • Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
  • Se piden algunos datos adicionales.
  • Aquí se comienza a hablar un poco de la arquitectura de la solución.
    • De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
    • Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
    • El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
    • Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
    • Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
    • Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.

• Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
• El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla

Identificación del Cliente

• Identificación del Cliente -El Dueño Del Producto cuenta la historia-
  • Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
  • Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
  • Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
  • Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
  • Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
  • Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

• Se preguntan los detalles convenientes para poder estimar la historia.
  • Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
  • El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

Reset de la clave

• El Dueño Del Producto cuenta la historia.
  • Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

Cambio de Plan (3)

• Cambio de Plan -El Dueño Del Producto cuenta la historia-
  • Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
  • Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
  • Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
  • Se piden algunos datos adicionales.
  • Aquí se comienza a hablar un poco de la arquitectura de la solución.
    • De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
    • Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
    • El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
    • Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
    • Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
  • Se decide no gestionar los errores en esta historia.

Estimación de Historias

Login

Entonces se procede a la estimación del Login

   - Miembro 1: 5
   - Miembro 2: 13
   - Miembro 3: 3

Al ser una diferencia importante, el Scrum Master decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.

• El miembro 2 explica:
  • Crear modelo de datos
  • Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
  • Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
  • Encriptación de pass.
  • Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.

• El miembro 3 explica:
  • Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
  • No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.

   - Miembro 1: 5
   - Miembro 2: 3
   - Miembro 3: 3

El Scrum Master toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

Cambio de Plan

Entonces se procede a la estimación de Cambio de Plan

   - Miembro 1: 20
   - Miembro 2: infinito
   - Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el Dueño Del Producto la divide en dos.

 Quedando el Backlog Del Producto:

   Login                          - I=100
   Identificación del Cliente     - I=90
   Reset de la clave              - I=80
   Pedido cambio plan             - I=70
   Consulta de estado de pedidos  - I=60
   Pedido de Servicio             - I=50
   Modificar pedidos              - I=30
   Cancelar pedidos               - I=20

Identificación del Cliente

Entonces se procede a la estimación de Identificación del Cliente

   - Miembro 1: 8
   - Miembro 2: 13
   - Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar. El Dueño Del Producto detalla un poco mas la historia.

Se vuelve entonces a estimar.

   - Miembro 1: 8
   - Miembro 2: 13
   - Miembro 3: 13

El Scrum Master decide tomar la estimación de 13 puntos de historia.

Reset de la clave

El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia Reset de la clave

   - Miembro 1: 5
   - Miembro 2: 3
   - Miembro 3: 3

El Scrum Master decide tomar la estimación de 4 puntos de historia.

Cambio de Plan (2)

Entonces se procede a la estimación

   - Miembro 1: 8
   - Miembro 2: 20
   - Miembro 3: 13

Al ser una diferencia importante, el Scrum Master decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.

• Miembro 1 explica:
  • Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
  • Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.

• Miembro 2 explica:
  • Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
  • Comenta que es la primer página que estarían haciendo del módulo.
  • Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
  • También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.

• Miembro 3 explica:
  • Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
  • Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.

     - Miembro 1: 13
     - Miembro 2: 20
     - Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

     - Miembro 1: 13
     - Miembro 2: 20
     - Miembro 3: 20

El Scrum Master decide tomar la estimación de 20 puntos de historia.

Compromiso

Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas. Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación. Entonces queda comprometido un Sprint con las historias de Login e Identificación del Cliente (17 puntos de historia) en el Backlog Del Sprint y quedando el Cambio de Plan como próxima historia estimada dentro del Backlog Del Producto.

El Backlog Del Sprint queda de esta manera

   Login                          - I=100   - E=4
   Identificación del cliente     - I=90    - E=13

Y de esta manera queda el Backlog Del Producto

   Reset de la clave              - I=80    - E=4
   Pedido cambio plan             - I=70    - E=20
   Consulta de estado de pedidos  - I=60
   Pedido de Servicio             - I=50
   Modificar pedidos              - I=30
   Cancelar pedidos               - I=20
   Circuito de errores            - I=15

Fin de la Planificación

Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.

- Objetivo del Sprint                      : Identificación del Cliente
- Reunión Diaria Reunion Diaria De Scrum   : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint                       : 3 semanas
- Reunión de Revision Del Sprint           : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown                         

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

Segunda Reunión: Resolución

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del Backlog Del Sprint, que es Login. El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:

  - Pantalla de Login
  - Método de autenticación

Ahora, se comienza la estimación de las tareas. Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar) Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

Tarea Pantalla de Login

Entonces se procede a la estimación

      - Miembro 1: 3
      - Miembro 2: infinito
      - Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

  - Pantalla de Error
  - Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

  - Pantalla de Login
  - Método de autenticación
  - Pantalla de Error
  - Pantalla de Ok

Pantalla de Login

Nuevamente se procede a la estimación

      - Miembro 1: 3
      - Miembro 2: 2
      - Miembro 3: 2

El Scrum Master decide tomar la estimación de 2 días ideales.

Método de autenticación

Entonces se procede a la estimación

      - Miembro 1: 1
      - Miembro 2: 1
      - Miembro 3: 1

El Scrum Master decide tomar la estimación de 1 dia ideal.

Pantalla de Error

Entonces se procede a la estimación

      - Miembro 1: medio
      - Miembro 2: 1
      - Miembro 3: 1

El Scrum Master decide tomar la estimación de 1 día ideal.

Pantalla de Ok

Entonces se procede a la estimación

      - Miembro 1: 1
      - Miembro 2: 2
      - Miembro 3: 2

El Scrum Master decide tomar la estimación de 2 días ideales.

Estimación del resto de las tareas

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales. AGREGAR AGREGAR Concepto de hecho del grupo de trabajo AGREGAR AGREGAR Que pasa si las estimaciones de las tareas exceden el sprint

Comienzo del Sprint:

• El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
• El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
• A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
• A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
• Cada mañana se hace la reunión diaria (Reunion Diaria De Scrum).

Reunión Diaria

La Reunion Diaria De Scrum se hace a las 10:00 todos los días en la sala 1 del 3er piso. Aquí asisten todos los que quieren y solo participan de la misma el equipo del Scrum.

• El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
• El Scrum Master le pregunta si tiene algún obstáculo para realizar el trabajo.
• El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
• El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
• El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
• El Scrum Master cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del Sprint, puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

Impedimentos e Imprevistos

En cualquier momento del Sprint, pueden surgir Impedimentos para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la Lista De Impedimentos, implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir Imprevistos, que son tareas que no tienen que ver con el Sprint y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

Revisión del objetivo

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:

• El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
• Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:

• El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:

• Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de Control De Versiones
• El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

Reunión de Revisión

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional. Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del Sprint, y cual era el plan original del mismo con las historias que se desarrollarían. Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo Sprint.

Al terminar la reunión, el Scrum Master pone la fecha de la próxima reunión de Revisión.

Reunión de Retrospectiva

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión. El Scrum Master dice como fue el Sprint, mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:

  - Bueno
  - A mejorar
  - Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas. Entonces de cada uno de los ítems expuestos en la columna A Mejorar se propondrá una forma Concreta de mejora. Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo. Entonces el Scrum Master, recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para poner mayor foco en el próximo Sprint. Cabe aclarar que aunque se ponga foco en pocos temas, esto no quiere decir que se intente hacer mejor lo que se consideró mejorable, solo quiere decir que es lo mas importante lo elegido. Aquí se da por finalizada la reunión de Retrospectiva Del Sprint.