Cómo Gestionar un equipo Scrum con Rally Software

El flujo de Scrum con Rally Software

---

1. Definición de los Sprints​

El Product Owner deberá definir los sprints/iteraciones desde el menú ‘Plan > Timeboxes’ seleccionando en el desplegable la opción ‘Iterations’. Es importante definir la velocidad planeada del sprint, para indicar cuantos puntos de historia se estiman que se van a a llevar a cabo en el sprint.​

2. Product Backlog

Previamente de realizar el backlog del producto, el equipo de gestión habrá generado la estructura de elementos de portfolio que haya creído conveniente para este proyecto. El Product Owner crea el backlog del producto con las historias de usuario que se van a llevar a cabo. Para ello habrá que acceder en el menú ‘Plan > Backlog’.​

3. Sprint Planning (Sprint Backlog)

El Team del proyecto tiene una reunión para preparar el backlog del sprint, reunión en la cual se debe indicar la disponibilidad de los miembros del equipo en puntos de historia (PH) para el siguiente sprint/iteración desde el menú ‘Track > Team Status’. Esta estimación se hace para cada proyecto/team, es decir, si el usuario está en varios equipos a la vez, tendrá que repartir su disponibilidad.​

En esa misma reunión se deben realizar las siguientes acciones desde el menú ‘Plan > Team Planning’ con la vista de Backlog: ​

1. Estimar en puntos de historia las US basándose en el esfuerzo necesario para completarlas.​
2. Asignar usuarios a cada US que serán los responsables de que se complete (no tienen porque trabajar en las tareas de la US).​
3. Crear para cada US las tareas necesarias. Estas tareas deben tener una estimación en horas.
4. Asignar las US al siguiente sprint (el cual estará en la reléase correspondiente) arrastrando las US al sprint (vista Planning). De haber estimado las US previamente, se podrá ver los puntos de historia respecto a la velocidad estimada para la iteración, y de esta manera saber si estamos excediendo de puntos de historia la iteración, o si nos estamos quedando cortos y podemos agregar mas US.​
5. Desde el menú ‘Plan > User Stories’ se procede a desglosar las US que sean muy grandes en US mas pequeñas creando una jerarquía con US padres y HU hijas. En este apartado también es posible editar el sprint, la estimación en puntos de historia y el dueño de las US.

4. Daily Scrum

Cada día habrá una pequeña reunión de máximo 15 minutos donde se modificarán los avances sobre las HU con las que haya trabajado el equipo el día anterior. Para esto lo mejor será acceder al menú ‘Track > Iteration Status’, que permite ver las HU de una iteración e ir actuando con las HU para realizar las siguientes acciones:​

• Cambiar de estado las HU.​
• Marcar como Ready una HU para que el PO pueda pasarla al siguiente estado.
• Marcar como Bloqueada y asignar un motivo para que el PO pueda observar el bloqueo del trabajo.​
• Permite crear nuevas HU y Defectos.​
• Administrar las tareas de las HU. ​
• Añadir carriles (Swimlines) para tener segmentado el backlog del sprint.

5. Finished Work + Sprint Review

Antes de presentar al cliente los avances del sprint, será necesario que el Scrum Team revise y se cerciore de que todo el trabajo se ha efectuado correctamente.​

Posteriormente, se llevará a cabo una reunión de con el cliente para la demostración de los requisitos completados en la cual:​

• Se presenta al cliente los requisitos completados en forma de incremento de producto preparado para ser entregado y usado con el mínimo esfuerzo.​
• En función de los resultados mostrados, de la velocidad de desarrollo del equipo y de los cambios que haya habido en el contexto del proyecto, el cliente identifica las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.​
• Se muestra un diagrama de avance del proyecto.

En Rally existen una serie de informes que pueden aportar valor al Scrum Master para hacer una revisión del trabajo realizado durante el sprint/iteración. Se puede acceder al listado de reports desde el menú ‘Reports > Reports’.​

• Iteration Cumulative Flow Diagram: Permite visualizar el estado de los puntos de historia a lo largo de la iteración. Desde que han sido definidos hasta que han sido aceptados.
• Iteration Defect State: Permite visualizar el estado de los defectos a lo largo de la iteración, desde que son descubiertos hasta que son fixeados.
• Iteration Burndown: Permite visualizar el to do de las tareas a lo largo de la iteración. También permite visualizar los puntos aceptados a lo largo de la iteración. Lo ideal: El to do tiene que ir disminuyendo a lo largo de la iteración, mientras que los puntos aceptados tienen que ir aumentado según va terminando la iteración.

Después de haber realizado la revisión del sprint (Sprint Review) con el cliente, se llevará a cabo una reunión de retrospectiva donde se indicarán las conclusiones de ese sprint esta reunión tiene dos fases:​

Análisis y mejoras:​

• Revisión de US completadas al final del sprint respecto las planificadas al principio.​
• Revisión de cantidad de Defectos encontrados y solucionados.​
• Revisión de puntos de historia realizados al final del sprint respecto a la velocidad planificada al principio.​
• Revisión de carga de trabajo por miembro del equipo para encontrar sobre adjudicaciones o falta de adjudicación respecto a la capacidad.​
• Análisis interno del funcionamiento del equipo.
• Propuestas y aprobación de mejoras.

Mediante la APP ‘Iteration Retrospective’ es posible registrar las conclusiones de la reunión de retrospectiva.