¿Qué es el tablero de tareas de sprint?

---

¿Qué es un tablero de tareas de sprint?

Una caja de tareas de sprint es un periodo de tiempo. Cada sprint tiene una fecha de inicio y una fecha de finalización durante las cuales se deben completar y confirmar un conjunto de historias de usuario seleccionadas. La siguiente imagen muestra los elementos clave de un sprint, que incluyen un conjunto de historias de usuario, los miembros de Scrum involucrados, la asignación de trabajo, la duración y la fecha de finalización (esquina superior derecha).

Al inicio de un sprint, el propietario del producto, los interesados y el equipo de desarrollo se reúnen para priorizar y luego seleccionar las historias de usuario que se deben completar en el sprint. Dado que diferentes partes tienen preferencias, consideraciones y preocupaciones distintas respecto al proyecto y al cronograma del proyecto, el propósito de la reunión es brindar a los participantes la oportunidad de escuchar y comprender las opiniones de los demás, y llegar a un conjunto de historias de usuario que sea acordado por todas las partes.

Duración del sprint

La entrega rápida de trabajo de calidad es una de las razones por las que los equipos de software desean adoptar metodologías de desarrollo ágil. Por lo tanto, aunque no existe una elección única que se ajuste a todos los casos para la duración del sprint, comúnmente se acepta que la duración debe ser tan corta como sea posible. ¿Pero cuán corta debería ser?

Aunque no se prefiere una duración larga del sprint, una duración irrazonablemente corta puede debilitar la motivación del equipo de desarrollo para completar trabajos importantes, o incluso puede llevar a una mala calidad de los entregables.

Por lo tanto, la selección de la duración del sprint es el resultado de una discusión entre todo el equipo: propietario del producto, scrum master y miembros de Scrum como diseñadores de bases de datos, programadores, diseñadores de UX, testers, analistas, etc. Pero al final, alguien debe tomar una decisión. En ese momento, el scrum master suele ser quien da la respuesta.

Tradicionalmente, un sprint dura entre tres semanas y un mes, pero actualmente cada vez más equipos han tenido éxito con sprints de dos semanas. Después de todo, aún no existe una selección fija para la duración del sprint. Un buen scrum master tiene habilidades colaborativas y facilitadoras para determinar la duración del sprint, asegurando que el trabajo se complete según lo esperado. A continuación se presentan algunos factores que un scrum master podría considerar:

1. Cronograma del proyecto acordado
2. Disponibilidad de clientes/interesados/proprietario del producto (quien puede aclarar dudas potenciales)
3. Cultura de trabajo de los clientes
4. Capacidad del equipo Scrum
5. Experiencia en Scrum

Una vez que el equipo ha alcanzado un consenso, todos los sprints futuros seguirán la misma duración sin cambiarla frecuentemente de sprint en sprint. Sin embargo, es una buena práctica que el equipo Scrum siga revisando la efectividad del sprint y busque una duración óptima que funcione mejor para todos.

Confirmación de trabajos (historias de usuario) en el sprint

Las actividades de desarrollo se organizan alrededor de las historias de usuario después de que comienza un sprint, y se van implementando más y más historias de usuario a medida que avanza el sprint. Sin embargo, la implementación completa de una historia de usuario no es el final de la historia. Aún hay un paso importante que debe recorrerse: la confirmación.

Confirmar una historia de usuario consiste en probar la característica implementada y decidir si se ha implementado según lo esperado. El juicio debe basarse únicamente en los criterios establecidos al detallar las historias de usuario, escritos en forma de elementos de confirmación. Durante la confirmación, al propietario del producto se le proporciona un entorno de pruebas o dispositivo para probar el trabajo implementado. El propietario del producto revisará uno por uno los elementos de confirmación escritos en la historia de usuario. Si todos los elementos se confirman como completados, se dice que la historia de usuario está confirmada. Si se encuentra algún elemento pendiente o que no funciona según lo esperado, el propietario del producto solicitará al equipo de desarrollo una corrección. Los procesos de corrección y confirmación se repetirán hasta que la historia de usuario esté completamente confirmada.

¿Cuándo confirmar?

El sprint, y de hecho el ágil, es un proceso de entrega continua. En lugar de confirmar las historias de usuario al final de un sprint, la confirmación debe realizarse justo después de completar cualquier historia de usuario. Sin embargo, si el propietario del producto no puede participar en la confirmación continua, puede organizarse una reunión semanal que dure entre 1 y 2 horas. Durante la reunión, el propietario del producto trabajará con el equipo para confirmar las historias de usuario completadas. La reunión también incluye una sesión de discusión que aclarará las dudas encontradas al implementar las otras historias incluidas en el sprint.

La confirmación no es equivalente a la prueba

Como se dijo, el propósito de la confirmación es asegurarse de que la historia de usuario se haya implementado correctamente. El juicio se basa únicamente en los elementos establecidos como elementos de confirmación durante el detalle de la historia de usuario, ni más ni menos. El nivel de verificación es mucho menos que suficiente para garantizar que la característica esté lista para su uso en producción. Entonces, ¿cuándo realizar una ‘prueba real’?

Diferentes equipos tienen prácticas distintas en cuanto a pruebas de software. Algunos equipos prefieren una prueba por sprint que implica la realización de pruebas como pruebas de integración y pruebas de regresión al final de un sprint. Algunos equipos prefieren establecer un sprint de estabilización, como su nombre indica, para pruebas y corrección de errores. No se realizarán nuevas actividades de desarrollo en ese sprint.

No importa qué enfoque elijas, ten en cuenta que la decisión no es de una sola persona, sino de todos.

Visual Paradigm proporciona todas las herramientas que necesitas en desarrollo de software ágil, que incluye herramienta de diagrama de casos de uso UML, (ágil) historia de usuario, sprint, storyboard y wireframes para diseño de experiencia de usuario, herramienta de gestión de tareas, etc.