En este artículo de nivel introductorio analizamos la mecánica de un Sprint y cómo se espera que los miembros del equipo colaboren para producir un incremento de calidad de lanzamiento.

El primer día: Planificación de Sprint

Todo el equipo, incluido el Propietario del Producto, se reúne el primer día del Sprint y realiza una sesión de Planificación de Sprint. Esto es lo primero que sucede tan pronto como comienza el Sprint.

Preparación

La planificación del Sprint debe estar preparada. La preparación más importante es garantizar que el Backlog de Productos se haya refinado a un nivel de detalle adecuado, con estimaciones y criterios de aceptación (este es el propósito del Refinamiento del Backlog de productos). A continuación, el Propietario del Producto debería haber ordenado el trabajo en el Backlog del Producto y tener una idea general de cómo negociar un valioso Objetivo de Sprint con el equipo. Las opciones para negociar un Objetivo también deberían haberse considerado durante el perfeccionamiento y haberse reflejado en los pedidos atrasados. Además, el equipo debe tener una idea de su capacidad para este Sprint, es decir, cuánto trabajo cree que puede asumir. Es posible que puedan usar su experiencia con Sprints anteriores para ayudarles a determinar el tamaño de este presupuesto.

Primer plan el valor que se entregará

Cada Sprint debe resultar en un valioso incremento de trabajo completado, en forma y listo para su lanzamiento inmediato. El Propietario del Producto es totalmente responsable de lo que significa «valor», y debería haber ordenado el Backlog de Productos de tal manera que el equipo pueda maximizar el valor, sprint a sprint. Por lo tanto, lo primero que debe hacer el equipo es planificar en qué artículos del Backlog de productos se debe trabajar en este Sprint, para que se pueda entregar el mejor valor al final del mismo.

Para hacer esto, el equipo trabaja con el Propietario del Producto para seleccionar los artículos más valiosos del Backlog de Productos que se ajusten a su capacidad proyectada para el Sprint. Tenga en cuenta que el equipo debe haber dado una estimación de cada elemento en el Backlog de productos, para que sepan aproximadamente cuánto trabajo es probable que esté involucrado.

Asegúrese de acordar un Objetivo de Sprint

Esta selección de trabajo debe ser coherente, y no solo una agrupación de elementos no relacionados y dispares. Recuerda que un Sprint es una oportunidad en caja de tiempo para lograr algo significativo. Por ejemplo, al final del Sprint, es posible que se haya entregado una función coherente o que se haya mitigado un riesgo significativo. El Objetivo de Sprint es una expresión simple de este propósito, de la importancia general del trabajo seleccionado y de la coherencia detrás de la selección.

Un buen Objetivo de Sprint le permitirá al equipo demostrar enfoque y compromiso, y permitir la colaboración y la re-planificación del trabajo para que se cumpla.

Siguiente plan de cómo se realizará el trabajo

Un Backlog de Sprint es más que una selección de trabajo con un objetivo final en mente. También es un plan de cómo se logrará ese objetivo y cómo se realizará el trabajo asociado. Esto se puede hacer identificando y ordenando las tareas técnicas que probablemente estén involucradas. En efecto, el Backlog de Sprint es un plan para alcanzar la Meta de Sprint y un pronóstico del trabajo que se tendrá que hacer.

El Propietario del Producto no necesita estar presente en esta parte de la Planificación de Sprint, ya que depende del equipo planificar este pronóstico a nivel técnico. Sin embargo, el Propietario del Producto debe estar disponible, aunque solo sea de forma remota, para responder cualquier pregunta que el equipo pueda tener y para proporcionar cualquier aclaración que pueda ser necesaria sobre el alcance del trabajo. Si se espera más de una versión durante el Sprint, esto debe acordarse con el PO y contabilizarse en el Backlog de Sprint.

Al final de la Planificación del Sprint, un equipo debe estar seguro de que ha hecho un buen pronóstico del trabajo que se necesitará para alcanzar el Objetivo del Sprint. Habrá capturado ese plan en el Backlog de Sprint que el equipo posee en su totalidad. El equipo debe ser capaz de comenzar a implementar ese plan de inmediato y con una comprensión clara, como una reducción de velocidad, de cuánto trabajo queda en un momento dado.

Cada día, cada día

una Vez que el equipo ha planificado su Sprint Backlog se puede empezar a trabajar. Si han planeado las cosas como tareas, colaborarán entre sí, como equipo, para asegurarse de que esas tareas se completen. Podrán hacer un seguimiento de su progreso utilizando su tablero de tareas y su Quema de Sprint del trabajo restante.

Cada miembro del equipo se asegurará de mantener actualizado el Tablero de Tareas de Scrum y el Registro de Sprint, para que otros puedan confiar en la información. Un radiador de información siempre debe decir la verdad.

Realice un Scrum Diario

Todos los días laborables, al mismo tiempo, el Equipo de Desarrollo se reunirá y planificará lo que hará para acercarlos a la Meta de Sprint. Esta reunión se llama el Scrum Diario y nunca debe tomar más de 15 minutos.

Solo los miembros del equipo de desarrollo deben participar, ya que el plan de trabajo les pertenece por completo. Es una oportunidad en caja de tiempo para volver a planificar la acumulación de Sprints como resultado de nuevos descubrimientos y lecciones aprendidas durante el Sprint. Todo el equipo debería participar. Cada miembro del equipo debe ser capaz de dar cuenta de:

• Lo que hicieron ayer para ayudar al equipo a alcanzar el Objetivo de Sprint
• Lo que pretenden hacer hoy para ayudar al equipo a alcanzar el Objetivo de Sprint
• Cualquier impedimento que se interponga en su camino

Al final del Scrum Diario, el equipo debe tener un plan claro para las próximas 24 horas y una comprensión de cómo necesitarán colaborar para lograrlo. También deben tener una lista de cualquier impedimento que requiera la atención del Maestro de Scrum.

Refinar el Backlog de productos

En Scrum, el Refinamiento del Backlog de productos no es un evento formal, sino una actividad continua: el proceso de agregar detalles, pedidos y estimaciones a los Elementos del Backlog de productos, como las Historias de usuarios. Depende de los propios equipos de Scrum decidir con qué frecuencia hacer esto, aunque sin duda es una buena idea para ellos agregar refinamiento a su rutina diaria. El refinamiento no debería tomar más del 10% del tiempo total de un equipo durante un Sprint. Para la mayoría de los equipos, media hora al día puede ser adecuada, aunque algunos pueden preferir pasar una hora o dos un par de veces a la semana. Lo importante es asegurarse de que el Backlog de productos se refine de manera oportuna para que la Planificación de Sprint pueda ocurrir sin impedimentos. Todo el equipo, incluido el Propietario del producto, debe participar.

Una sesión de refinamiento generalmente comienza con el Propietario del Producto presentando el Backlog de Productos actual al equipo. El atraso puede guardarse en varios formularios, como un tablero de Scrum electrónico u otra herramienta de colaboración, o simplemente puede ser una hoja de cálculo. Un proyector o pantalla compartida puede ser muy útil.

El equipo comienza en la parte superior del Backlog de productos y trabaja hacia abajo, refinando cada artículo a su vez. Examinarán cada uno y discutirán su alcance, y los criterios de aceptación que serán necesarios para su finalización. Cada elemento se estimará utilizando una técnica como la Planificación de Poker. Un objeto grande puede dividirse en otros más pequeños que capturan un mayor detalle. Las epopeyas pueden descomponerse en historias de usuarios, por ejemplo.

El equipo se detiene una vez que se agota la casilla de tiempo de la sesión. Se reanudarán donde lo dejaron la próxima vez, y eventualmente comenzarán de nuevo en la parte superior para que el trabajo atrasado se mantenga actualizado.

Siempre colabore

En la práctica ágil, los miembros del equipo nunca trabajan aislados; si lo hicieran, no serían un equipo. De hecho, el trabajo en equipo es tan importante que el papel es el Equipo de Desarrollo en lugar del Desarrollador.

Esto significa que cada miembro del Equipo de Desarrollo debe colaborar con sus compañeros durante todo el día, ya que son responsables conjuntamente del progreso del trabajo. Cualquier problema o fracaso es propiedad conjunta del equipo, así como sus éxitos. La colaboración no es algo que se limite a eventos como el Scrum Diario, sino que se aplica a todo lo que el equipo hace a lo largo de todo el Sprint.

Los ejemplos de colaboración incluyen:

• Ayudar a los compañeros a completar el trabajo en curso antes de traer trabajo nuevo de un backlog
• Programación de pares, como turnarse para usar el teclado y ayudar y verificar el trabajo de los demás
• Revisión por pares
• Pedir ayuda, y estar dispuesto a darla
• Ir a donde está el trabajo y ayudar, en lugar de esperar a que el trabajo se les pase
• Asegurarse de que todo el trabajo cumpla de hecho con la Definición de Hecho
• Llamar a un Scrum para resolver problemas que necesitan la atención inmediata del equipo
• el Scrum Master para que puedan manejarse de manera oportuna
• Actualizar un tablero de tareas de Scrum y un gráfico de quemado para que la información esté actualizada y se pueda confiar en
• Compartir habilidades y conocimientos

El último día: Revisión y retrospectiva

Realizar una Revisión de Sprint

Si un equipo ha colaborado de manera eficiente, habrán trabajado juntos para alcanzar el Objetivo de Sprint, gestionar cualquier riesgo y ajustar sus planes según sea necesario. Habrán demostrado control durante todo el Sprint a través de una reducción uniforme del trabajo restante, donde cada miembro vio como su responsabilidad personal ayudar a completar el trabajo en curso. Tendrán un incremento valioso que demostrar al Propietario del Producto y a cualquier parte interesada invitada. Una revisión es algo que un equipo debe esperar con ansias.

También es algo para lo que un equipo debe prepararse. Se debe dar tiempo suficiente para una demostración del trabajo que se ha realizado. Las tareas pueden planificarse en un Backlog de Sprint para este propósito, para asegurarse de que la Revisión haga justicia al trabajo realizado y al valor que ahora está disponible. Además, si el Propietario del producto cree que sería una buena idea invitar a las partes interesadas, entonces esas invitaciones deberían haberse enviado. La revisión es una oportunidad para celebrar el trabajo que se ha realizado y mostrar sus logros, por lo que la confianza se inspira y una inversión continua en el equipo podría estar justificada.

Una revisión de Sprint también es una oportunidad de inspeccionar y adaptar. Es un buen momento para que el Propietario del producto explique qué tan bien está funcionando el producto, para obtener comentarios de primera mano de las partes invitadas y para extraer lecciones que puedan usarse para mejorar aún más el Backlog de productos. Si algún trabajo no se ha completado, por la razón que sea, también se revisará y volverá a estimarse en el Backlog de Productos para una posible planificación en futuros sprints.

Luego realice una Retrospectiva de Sprint

La Revisión de Sprint analizó el Producto y el valor entregado, el trabajo que se ha realizado y, honesta y francamente, cualquier trabajo que no se haya realizado, cualquiera que sea la razón.Lo siguiente que hay que hacer es realizar una retrospectiva de Sprint. Una retrospectiva considera el proceso que el equipo está siguiendo. ¿Están trabajando tan eficazmente como pueden? Por lo general, es mejor realizar la Retrospectiva inmediatamente después de la Revisión, porque la primera puede introducir ideas para su consideración en la segunda.

Todo el Equipo de Desarrollo, el Propietario del Producto y el Scrum Master deben asistir a la Retrospectiva, porque todos son responsables conjuntamente del éxito del trabajo del equipo. Es muy importante tener una sesión gratuita y abierta que llegue al corazón de cualquier problema e identifique acciones que ayuden a resolverlo. Una retrospectiva puede comenzar con la siguiente declaración:

» Independientemente de lo que descubramos, entendemos y creemos verdaderamente que todos hicieron el mejor trabajo que pudieron, dado lo que sabían en ese momento, sus habilidades y habilidades, los recursos disponibles y la situación en cuestión.»

En un «Retro», todos tienen la misma voz. Un enfoque, que el Scrum Master puede facilitar, es identificar:

• Cosas que salieron bien
• Cosas que no salieron tan bien
• Ideas para mejorar
• Saludos para los miembros del equipo que hicieron algo excepcional

Establecer una línea de tiempo puede ayudar a refrescar los recuerdos de los asistentes sobre eventos significativos durante el Sprint.