Las Historias de Usuario son los elementos más específicos de la lista de producto y contienen la visión del usuario sobre la funcionalidad esperada del producto. No se deben confundir las Historias de Usuario con requerimientos, en ellas se referencia lo que el usuario quiere o espera del producto terminado.
Componentes de una Historia de Usuario
Estos son los componentes que debe tener una buena Historia de Usuario, para que sea fácil de entender por parte del equipo, genere valor y simplifique el proceso de desarrollo:
Título. Permite conocer rápidamente de qué se trata la historia y por ello debe ser concreta y clara.
Descripción. Contiene información sobre cómo se deben ejecutar las tareas, puede incluir componentes técnicos, especificar el tipo de diseño, el lugar donde se van a almacenar las tareas o el flujo de arquitectura que se debe seguir. En resumen, contempla una definición más específica para completar la historia.
Para la descripción es útil emplear una plantilla como la siguiente:
Como <rol> quiero <acción> para qué <beneficio>
Puntos. Los puntos de una Historia de Usuario representan el esfuerzo que le va a tomar al equipo de desarrollo completar las actividades de la historia.
Criterio de aceptación. A través de él se definen los requisitos que la historia debe cumplir para que esté completa.
👆🏻 Fuente: Samuel Miranda Martínez
Cómo definir que una Historia de Usuario está terminada
La definición de “completado” en una Historia de Usuario debe incluir la lista de elementos requeridos. Este es un ejemplo:
✅ Funcionalidad (que se cumplan los criterios de aceptación)
✅ Sistema de gestión del código o de versiones (código actualizado en git)
✅ Pruebas creadas (unitarias, funcionales, de rendimiento)
✅ Documentación (a través de manuales o tutoriales)
Antes de comenzar la planeación del sprint se debe de invertir tiempo en la planeación de las Historias de Usuario. Existe una técnica llamada las tres C (por sus nombres en inglés):
Cards. Son las tarjetas creadas con los componentes o información de cada historia.
Conversation. Es la conversación del equipo acerca de la historia, para asegurar que no haya dudas en el proceso de desarrollo.
Confirmation. Todas las personas que trabajan en la historia llegan a un acuerdo y confirman que entienden su contenido.
Cómo debe ser una buena Historia de Usuario
I - Independiente. No debe depender de otra Historia de Usuario. Si es así, debe marcarse con tiempo y no se debe empezar a trabajar hasta que se complete su dependencia.
N - Negociable. Si el equipo encuentra que la historia es muy grande para completarla durante el sprint, se puede negociar con el Product Owner para dividirla en historias más pequeñas.
V - Valiosa. Debe entregar valor al cliente, debe hacer algo por la funcionalidad o el producto.
E - Estimable. Se debe poder estimar el esfuerzo para completar la historia.
S - Small (pequeña). Debe ser lo suficientemente pequeña para cumplir una funcionalidad
T - Testeable (comprobable). Se debe verificar que la historia se completó a través de los criterios de aceptación y de la definición de completado.
Contribución creada con los aportes de: Cristian Palacios Beltran, Alex Camacho y Samuel Miranda Martínez
las historias de usuarios son los elementos más específicos de la lista de producto, no se tienen que confundir con los requerimientos si no que es la funcionalidad que el usuario quiere realizar.
Componente de una historia de usuario:
1-La historia tiene un ** titulo** ¿De que se trata la historia?
2-Debe tener una descripción, como se deben realizar las historias
3-Puntos, esfuerzo que le va a tomar al equipo de desarrollo terminar una tarea
4-Criterios de aceptación es como identificamos que la tarea fue completada
Descripción
++Como++, rol quien es el usuario que cuenta la historia
++Quiero,++ que funcionalidad está buscando el usuario
++Para,++ para que quiero realizar esa acción
Dentro la definición de historia de usuario vamos a entender como completo, cuando por ejemplo:
Funcionalidad, cumple con lo establecido en la historia
Código subido en git
Pruebas creadas, pruebas unitarias, pruebas funcionales
Documentación, que el código esté bien documentado
Invertir tiempo en nuestras historias, las 3C's
++Cards:++ escribimos la historia de usuario
++Conversación++: Entender todo sobre la historia
++Confirmación:++ confirmar que todos entendieron lo mismo
Invirtiendo en HistoriasI - independiente, no debe depender de otra historia de usuario
N - Negociable. si la historia es muy grande dividirla en tareas pequeñas
V- Valiosa, Debe entregar valor al cliente
E - Estimable, cuánto esfuerzo requiere
S - Small, debe ser pequeña
T - Testable, se debe validar su funcionalidad
es probable que la respuesta sea correcta, pero en la vida real si alguien quiere agregar una historia de usuario al backlog no podra porque no debe hacerlo, la pregunta esta mala. Debe cambiarse a ¿Quién puede "Proponer" historias de usuario a los distintos backlogs?
Las historias de usuario son los elementos más específicos de la lista de producto, contienen la visión del usuario sobre la funcionalidad esperada del producto.
Historia de usuario ≠ Requerimientos
El usuario no siempre es la persona que va a estar detrás de la pantalla interactuando con el producto, el usuario también puede ser otra parte del sistema.
Los componentes de la historia de usuario son:
Título. Define de manera rápida y sencilla de qué se trata la historia.
Descripción. Define de forma más específica lo que se va implementar en esta tarea.
Para la descripción es usual manejar una plantilla como la siguiente:
Como <rol> quiero <acción> para <beneficio>
Como estudiante quiero poder completar evaluaciones en la plataforma para poder ser evaluado y tener una calificación.
Puntos. Es el esfuerzo que le tomará al equipo de desarrollo completar la historia.
Criterio de aceptación. Son los requisitos que la historia de cumplir para poderla marcar como completa.
Se pueden usar sistemas digitales para manejar las historias de usuario como lo puede ser Jira.
¿Cómo podemos definir que una historia esta ya terminada? Para eso tenemos la definición de completo que son la lista de elementos requeridos para saber que una historia se completo. Ejemplo de una historia de desarrollo:
✅ Funcionalidad (criterios de aceptación)
✅ Código subido en git
✅ Pruebas creadas
✅ Documentación
Se debe de invertir tiempo en la planeación de las historias de usuario, tenemos una técnica llamada las tres C's por sus nombres en inglés.
Cards. Son las tarjetas creadas con los componentes o información de cada historia.
Conversation. Es la conversación del equipo acerca de esta historia y que todos entienden el proceso que tendrá.
Confirmation. Todas las personas confirman que entienden la historia.
Se dice que inviertes en historias porque estas deben de ser:
I - Independiente
N - Negociable
V - Valiosa
E - Estimable
S - Small (pequeña)
T - Testeable (Comprobable)
Muchas veces sucede que la comunicación no es clara cuando se quiere definir que es terminado. Por ejemplo, cuándo un usuario especifica que requiere un reporte con cuatro columnas y que la última columna tenga un total parece algo sencillo. Pero si para probar ese reporte se requiere preparar datos históricos consolidados de varios meses y años entregados por un proveedor externo, además cuadrar los resultados con otros reportes y además que dichos reportes sean validados con datos de mínimo 6 meses, la cosa se complica bastante y los conflictos suelen aparecer con frecuencia más aún cuando el único punto de referencia es un documento de análisis donde no aparece si esto se encuentra dentro o fuera del alcance y por lo tanto el único entregable es el "Reporte terminado".
Una buena historia de usuario es:
I - Independiente
N - Negociable
V - Valiosa
E - Estimable
S - Small
T - Testable
Se debe "invertir" en las historias de usuario
Yo soy QA y quien prueba las funcionalidades de mi equipo de desarrolladores.
Los componentes que tengo en cuanto para entregar la funcionalidad y colocarla en "Done" son:
Que el pull request de ese codigo que se subirá sea aprobado a mi entorno. (Si lo declinan quiere decir que ese codigo esta incorrecto o tiene oportunidad de mejora).
Que la funcionalidad se pueda subir de manera correcta a mi entorno de trabajo (El ambiente de QA donde hago pruebas).
3.Que esta misma funcione de manera correcta.
4.Que la funcionalidad no tenga Bugs en sus apartados correspondientes.
Al tener esos 4 puntos resueltos la historia de usuario/Funcionalidad esta resuelta.
Hola me pueden aclarar la respuesta a la pregunta siguiente: ¿Quién puede agregar historias de usuario a los distintos backlogs? Según entiendo y de acuerdo a las clases es el Product Owner pero la respuesta en el examen se califica como incorrecta
¿Qué nos cuentan las historias de usuario?
Son los elementos más específicos de la lista de producto, contienen la visión
del usuario sobre la funcionalidad esperada del producto.
Componentes de la Historia de Usuario
Título
Descripción: Describe el proceso, puede llevar cosas técnicas.
Puntos: Es el esfuerzo para completar la historia.
Criterio de aceptación: Lo que necesita la historia para completar lo que se
espera.
Elementos para la descripción:
Como "rol"
Quiero "acción"
Para "Beneficio"
La definición de completo son la lista de elementos requeridos para saber que
una historia esta completa.
Invirtiendo en Historias
Las 3 C’s
Cards
Conversation
Confirmation - Llegar a un acuerdo y confirmar que todos los que trabajaron en la historia de usuario entendieron los mismo.
I - Independiente: No debe depender de otra historia de usuario, y si depende debe marcarse con tiempo y no se puede empezar a trabajar hasta que se complete su dependencia.
N - Negociable: Si es muy grande se puede negociar con PO y dividir en historias más pequeñas
V - Valiosa - Debe hacer algo por el producto, que el cliente diga que le da valor ya que el producto ya está haciendo algo.
E - Estimable: Se debe poder medir el esfuerzo que requiere para ser completada
S - Small (pequeña): No debe de ser una EPICA
T - Testable (comprobable): A través de la definición de terminado
Historias de usuario:
No debemos confundir las historias de usuario con requerimientos.
La historia de usuario es la historia que el usuario nos esta contando ¿Qué quiere el usuario de nuestro producto? ¿Qué quiere hacer el usuario con nuestro producto?
Es la funcionalidad que el usuario espera de nuestro producto.
Componentes de una historia de usuario
Título: Explica de qué se trata la historia de usuario.
Descripción: Explica cómo se va a solucionar la historia, lleva componentes técnicos, diseño que se va a implementar, flujo de arquitectura que va a seguir, bases de datos, etc. (Debe ser específica).
Puntos: Esfuerzo que va a tomar al equipo desarrollo llevar a cabo las ecuaciones de esa historia.
Criterios de aceptación: Qué necesita la historia tener para decir que esa historia está completa. Para que el equipo pueda decir que "eso es lo que se espera de la historia".
Plantilla para historia de usuario:
Descripción:
Como <rol>: Quién va a realizar la acción. Quien es el usuario que cuenta la historia.
Quiero <acción>: Que funcionalidad está buscando.
Para <beneficio>: Para que quiero realizar esa acción o tener esa funcionalidad.
¿Cómo definimos que una historia esta terminada o completada?
Criterios de aceptación: Las funcionalidades que queremos lograr con la historia.
Git: Sistema de gestión del código y gestión de versiones como Git. Para asegurarnos que él esté lista completa tenemos que asegurarnos que el programador hizo PUSH y subió los cambios para asegurarnos que todos tenemos la misma información.
Pruebas creadas: Pruebas unitarias, pruebas de funcionales pruebas de regresión, etc. Estoy para asegurarnos que la historia funciona.
Documentación: Definimos la documentación del código, documentación de manuales y demás.
Invertir tiempo en historias de usuario
Invertimos tiempo antes de comenzar nuestros sprints para maximixar el tiempo de entendimiento del equipo de desarrollo de estas historias de usuario. Para esto vamos a usar:
La técnica de las 3C´s:
Cards (Tarjetas): Plantillla donde escribimos la historia de usuario.
Conversación: El equipo se sienta con el scrum master, cliente o product manager para conversar sobre esta historia de usuario para entender absolutamente todo sobre la historia de usuario.
Confirmación: Todos deben acordar que entendieron lo que debemos solucionar y como lo vamos a hacer.
Invertir en nuestras historias de usuario:
I - Independiente: No debe depender de otra historia de usuario y si la historia depende de otra, no puede compenzar hasta que se complete su dependencia.
N - Negociable: Si el equipo considera que es una historia muy grande se debe negociar con el Product Owner y dividirla en historias más pequeñas.
V - Valiosa: Debe ser valiosa para el usuario y brindarle mejoras de alto impacto.
E - Estimable: Debemos conocer el esfuerzo que se debe colocar en la historia para poderla completar.
S - Small: Debe ser pequeña.
T - Testeable (Comprobable): Comprobable a través de los criterios de aceptación y a través de la definición de completado (funcionalidad, código subido a git, pruebas y documentación).
