Planifiación y Estimación
La fase de Planificación y Estimación consiste en procesos relacionados a la planificación y estimación de tareas, los cuales incluyen: Crear historias de usuario, Estimar historias de usuario, Comprometer historias de usuario, Identificar tareas, Estimar tareas y Crear el Sprint Backlog.
1. Crear historias de usuario
En este proceso se crean las historias de usuario y sus respectivos criterios de aceptación. Las historias de usuario generalmente las escribe el Dueño de Producto y se diseñan para garantizar que los requerimientos del cliente estén claramente representados y que todos los interesados las pueden entender completamente.
Se pueden llevar a cabo talleres de redacción de historias de usuario donde se involucre a los miembros del Equipo de Desarrollo en su creación; dichas historias se incorporan al Backlog Priorizado del Producto.
Experiencia en la redacción de historias de usuario
Basado en la interacción con los interesados, su conocimiento del negocio, la experiencia y las aportaciones del equipo, el Dueño de Producto desarrolla las historias de usuario que habrán de formar el Backlog Priorizado del producto inicial para el proyecto, éste representa la suma total de lo que debe completarse en el proyecto. El objetivo de este ejercicio crear historias de usuario elaboradas y refinadas que pudieran ser estimadas y comprometidas por el Equipo de Desarrollo. En ocasiones, el Dueño de Producto pudiera incluir a un analista empresarial para que ayude en la redacción de historias de usuario.
Aunque el Dueño de Producto tiene la principal responsabilidad de escribir las historias de usuario y generalmente lleva a cabo esta actividad por sí mismo, se puede también llevar a cabo un taller de redacción de historias de usuario si así se desea.
Historias de usuario
Las historias de usuario se apegan a una estructura específica predefinida y son una forma simple de documentar los requerimientos y funcionalidades que desea el usuario final.
Una historia de usuario incluye tres elementos sobre el requerimiento:
- ¿Quién?
- ¿Qué?
- ¿Por qué?
Los requerimientos expresados en las historias de usuario son oraciones breves, sencillas y fáciles de entender. El formato estándar predefinido da como resultado una comunicación mejorada entre los interesados, así como mejores estimaciones por parte del equipo.
Algunas historias de usuario tal vez sean demasiado extensas como para poderse manejar dentro un solo sprint. A estas amplias historias generalmente se les llama épicas.
Un ejemplo de la redacción de historias de usuario:
Formato de historia de usuario:
Como <rol/prototipo de cliente> yo debería <requerimiento> a fin de <beneficio>.
Ejemplo de historia de usuario:
Como administrador de una base de datos, yo debería contar con la capacidad de revertir una cantidad selecta de actualización de la base de datos a fin de que se restablezca a la versión deseada.
Para documentar el detalle de las historias de usuario, Mike Cohn menciona en User Stories Applied for Agile Software Development la estructura siguiente:
- Redacción de la historia de usuario – simple, siguiendo el formato mencionado anteriormente.
- Conversaciones sobre la historia de usuario – transcripción de las discusiones y aclaraciones que se hacen sobre la historia de usuario al revisarla con el Dueño de Producto y otros interesados.
- Pruebas – en donde se definen las validaciones que se aplicarán para verificar el cumplimiento de la historia de usuario y se establecen sus criterios de aceptación (definición de terminado).
Es importante señalar que esta documentación es dinámica. Las conversaciones se van actualizando, corrigiendo y agregando conforme se avanza en la elaboración de la historia de usuario a partir del aprendizaje logrado durante su construcción y en las interacciones con el Dueño de Producto y los interesados. De la misma manera, los criterios de aceptación y las validaciones correspondientes se actualizan y ajustan de acuerdo con lo que se modifica en la historia de usuario.
Criterios de aceptación de historias de usuario
Cada historia de usuario cuenta con sus respectivos criterios de aceptación. Las historias de usuario son subjetivas, de tal forma que los criterios de aceptación brindan la objetividad requerida para que las historias de usuario se consideren terminadas o no terminadas durante la revisión del sprint.
Los criterios de aceptación brindan claridad al equipo respecto a lo que se espera en una historia de usuario y eliminan la ambigüedad de los requerimientos, ayudando a la alineación de las expectativas.
El Dueño de Producto define y comunica los criterios de aceptación al Equipo de Desarrollo y en las reuniones de revisión del sprint, brindan el contexto para que el Dueño de Producto decida si la historia de usuario se ha completado satisfactoriamente.
Es responsabilidad del Scrum Master asegurar que el Dueño de Producto no cambie los criterios de aceptación de una historia de usuario asignada a mitad de un sprint. Sin embargo, los criterios de aceptación pueden modificarse a lo largo del proyecto, como consecuencia de las revisiones con los interesados y el uso del incremento liberado.