2.9.4 Forma de trabajo

Una vez que ya se tienen definidas las User Stories la forma de trabajar es mediante varias reuniones.

  • Sprint Planning: Al inicio de cada sprint se tiene una reunión inicial, donde se eligen las User Stories que se van a entregar en el sprint. Se revisan los tiempos estimados y se revisa de forma general para aclarar las posibles dudas. La duración suele ser entre 1 y 4 horas. Se define el objetivo del sprint, es una frase que servirá como meta para todo el equipo. Para nuestra aplicación de ejemplo una meta podría ser: Incrementar la seguridad de acceso a los productos, permitiendo que cada vendedor solamente acceda a las categorías de productos que tiene asignado. De esta forma las user stories estarian relacionadas para cumplir este objetivo y todos los miembros del equipo conocen cual es la meta final, estimando las user stories para entregar la funcionalidad básica y luego irla mejorando.

  • Daily Stand Up: Es una junta diaria de máximo 15 minutos en el cual cadaa integrante del scrum comenta de forma breve que es lo que hizo el día anterior, que es lo que hará en el día actual y si tiene algún impedimento como falla en la red, en el servidor, etc. De esta manera todoss los miembros del equipo estan enterados de los avances.

  • Backloog groming: Opcionalmente se puede tener una junta pocos días antes del final del sprint para revisar los user stories para aclarar dudas o remover algún user story que por algún motivo no se pudo realizar, por ejemplo durante el sprint hubo mucho soporte.

  • Iteration Review: Al final del sprint se hace una reunión en donde cada miembro del equipo muestra los avances de lo que desarrollo durante el sprint, se le presenta al product owner y a algún usuario que puede estar interesado en la nueva función, se observa el avance y se pueden solicitar mejoras para el siguiente sprint.

  • Retrospective: También al final del sprint se reunen los miembros del equipo para platicar acerca de las cosas que se realizaron bien en el equipo, las cosas que se pueden mejorar, y las cosas que no salieron bien para tomar un plan para por ejemplo mejorar el proceso, por ejemplo se puede sugerir definir mas las user stories o los casos de prueba si en algún sprint no fue muy claro, o agregar otras opciones para estimar los tiempos.

Puedes ver algunas sugerencias y recomendaciones de microsoft para el scrum

Es importante que no se cambien ni se agregan nuevas tareas no planeadas durante el sprint. Si el sistema ya esta en prducción y el equipo scrum es encargado tambien de dar soporte al sistema se pueden planear un tiempo para atender soportes.