Historias de usuario: escríbelas, estímalas y entrégalas
Escribe historias de usuario con criterios de aceptación, estímalas en puntos, planifícalas en sprints y sigue cada una hasta que esté en producción.
2 min de lectura
Qué es una historia de usuario
Una historia de usuario describe una necesidad desde el punto de vista de quien la tiene: “Como [rol], quiero [capacidad] para [beneficio]”. Es la promesa de una conversación, no una especificación completa — los detalles llegan con los criterios de aceptación.
La lista INVEST
- Independiente: se puede construir y liberar por sí sola.
- Negociable: los detalles se acuerdan con el equipo.
- Valiosa: alguien se beneficia cuando está hecha.
- Estimable: el equipo la entiende lo suficiente para dimensionarla.
- Pequeña: cabe en un sprint.
- Testeable: sus criterios de aceptación dicen cuándo está terminada.
Criterios de aceptación
Los criterios de aceptación convierten una historia en algo que se puede probar. Escríbelos como condiciones concretas — “dado, cuando, entonces” funciona bien — y acuérdenlos antes de que empiece el sprint, para que las pruebas comprueben lo prometido.
Historias de usuario en DevGob
- Tipos historia de usuario y elemento de backlog bajo features y épicas.
- Criterios de aceptación, puntos de historia y valor de negocio en cada historia.
- Orden del backlog y planificación de sprints con capacidad.
- Tareas con horas bajo cada historia.
- El despliegue que lleva la historia a producción, vinculado a ella.
Cómo ayuda DevGob
En DevGob una historia de usuario mantiene sus criterios de aceptación, su estimación, sus tareas y el despliegue que la entrega en un solo registro conectado.
Leerlo en la documentaciónPreguntas frecuentes
¿Cuál es la diferencia entre una historia de usuario y un elemento de backlog?
Una historia de usuario se escribe desde el punto de vista del usuario; un elemento del product backlog puede ser cualquier trabajo. DevGob soporta ambos tipos.
¿Cómo se estiman las historias de usuario?
Normalmente en puntos de historia, unas respecto de otras. DevGob registra los puntos por historia y la velocidad por equipo.
¿Quién escribe las historias de usuario?
El product owner es dueño del backlog, pero las historias se escriben mejor junto con el equipo y las personas que usarán la funcionalidad.
Sigue leyendo
DevOps con gobierno, en un solo registro
DevGob planifica el trabajo y gobierna cada cambio en su camino a producción: backlog, sprints, autorizaciones de comité, evidencia de instalación y auditoría.