¿Qué nos cuentan las Historias de Usuario?

Definición de terminado:

• Push de commits sobre branch, haciendo referencia al número de issue trabajado.
• Aprobación del pull request de al menos 2 miembros del equipo de desarrollo.
• Agregar sobre el issue trabajado evidencias del éxito de pruebas de funcionalidad y de integración
• Documentar la funcionalidad liberada en el repositorio compartido al cliente .
• Actualizar apps y/o hacer deploy, notificar al cliente e indicar si es necesario realizar algún tipo de actualización.

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 Historias
I - 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

Yo desarrollo Robots, sobre Automation Anywhere y UiPath. Para nosotros hay 3 componentes que determinan que la historia está terminada:

• Emula y optimiza los procesos del humano
• Funciona sobre la plataforma asignada y cumple con los esquemas de seguridad.
• Tiene contemplados escenarios de no funcionamiento y genera alarmas.
  Todas son técnicas, sin embargo creo que es necesario ahora replantearlas para incluir documentación y más pruebas.

Yo pensaría que para que ya sea considerado terminado debe cumplir mínimo con estos:

1. Que haya sido testeado
2. Que el usuario haya validado la funcionalidad
3. Que esté documentado y almacenado

Les comparto mis notas:

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”.

¿Qué nos cuentan las historias de usuario?

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.

1. Cards. Son las tarjetas creadas con los componentes o información de cada historia.
2. Conversation. Es la conversación del equipo acerca de esta historia y que todos entienden el proceso que tendrá.
3. 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)

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

Definición de completado:

• Documento de pruebas por desarrollador y tester.
• Control de cambios con aprobación de funcional y lista de evidencias
• commit realizado en git
• validación de comité por calidad y normas de código
• A probación de publicación en producción

• I - Independiente
  • No dependen de otras historias
• N - Negociable
  • Si es muy grande se negocia y se divide en historias mas pequeñas
• V- Valiosa
  • Que genere valor para el cliente
• E - Estimable
  • Como y cuanto esfuerzo se va dar a la historia
• S -Small (pequeña)
  • Debe ser pequeña para cumplir una funcionalidad.
  • Si es muy grande puede ser un epic.
• T- Testable (Comprobable).

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).

¿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.

• Código subido en git.
• Pruebas creadas.
• Documentación.

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

En nuestro equipo, definición de Terminado en uno de los sprint se da cuando:

• Tenemos el backup de diseños
• Hemos completado el listado de requerimientos LQ del proyecto
• Probamos el acceso de los enlaces a documentos y el funcionamiento de landings.
• El usuario ha probado el PMV y nos ha permitido sacar conclusiones.

• Aplicar INVEST en las historias de usuario.
• Documentar la información generada durante el desarrollo de la historia de usuario.
• Realizar una prueba de cada avance del software funcional.
• Tener una validación por parte del scrum master y del product owner para continuar con el siguiente sprint.

Las HU no son requerimientos, son lo que nos cuenta el cliente sobre los que espera del producto. El equipo participa en su construcción. Se compone de titulo, descripción, puntos, criterios de aceptación. Una historia de usuario debe ser Independiente, negociable, valiosa, estimable pequeña y testable.

Historias de usuario
Son los elementos más específicos de una línea de producto contienen la visión del usuario sobre la funcionalidad del producto.
Componentes e una historia de usuario

• Título
• Descripción
• Puntos: esfuerzo que le va a tomar al equipo completar la historia.
• Criterio de aceptación: que debe tener para darla como completa.
  ¿Cómo saber si están terminado?
  Hay que establecer una definición de terminado con requisitos
• Funcionalidad (criterio de aceptación)
• Pruebas
• Documentación (ej. manuales)
• Puede haber otros requisitos
  Maximizar el tiempo con las tres C
• Cards (tarjetas)
• Conversación (con el product manager o con el cliente)
• Confirmación (de que todos entienden lo mismo)
  Hay que invertir en las historias
• I – independiente: no debe depender de otra historia.
• N – negociable: se podrá negociar si dividirla en historias más pequeñas.
• V – valiosa: debe entregar valor al producto.
• E – estimable: se debe saber cuanto esfuerzo se le va a otorgar
• S – small
• T – testable: se debe saber si se ha completado o no con los requisitos.

Las Historias de Usuario contienen la visión del usuario sobre la funcionalidad esperada del producto.

Componentes de la Historia del Usuario

• Titulo
• Descripción -> Rol, Acción, Beneficio
• Puntos
• Criterios de Aceptación

Invirtiendo en Historias

I -> Independiente
N -> Negociable
V -> Valiosa
E -> Estimable
S -> Small (Pequeña)
T -> Testable (Comprobable)

Historias de usuario

Son los elementos específicos de la lista del producto.

• Que quiere el usuario de nuestro producto, no requerimientos, es la funcionalidad que desea realizar.

Componentes:
a. Titulo: de que trata la historia la tarea especifica.
b. Descripción: dice como se debe hacer la tarea.
c. Puntos: El esfuerzo que va a tomar al equipo de desarrollo completar la tarea.
d. Criterio de aceptación: Que necesita la historia tener para declararla como completa o lo que se espera.

Plantilla como sugerencia

COMO <rol>
Quien va a realizar la acción.

QUIERO <acción>
Que quiere el usuario del sistema

PARA <beneficio>
Para que quiera que se haga la acción.

Para definir una historia terminada, se ve mira los criterios de aceptación.

• QA corre correctamente.
• Estén las pruebas creadas.
• Todo este documentado.

Las tres C´S

1. Cards.
2. Conversación. Hablar con el cliente que desea y como lo ve.
3. Confirmación. Que todos estén alineados y entendieron lo mismo.

• Independiente, no depende de otras historias.
• Negociable. Para que sea más o menos extensas.
• Valiosa, entrega valor al cliente, cliente le vea valor.
• Estimable, como y cuanto esfuerzo se va.
• Pequeña, rápida entregables.
• Testable, comprobable cuando se complete.

DoD o Definición de Terminado en mis equipos se da cuando:

• Se tiene el desarrollo listo con pruebas unitarias.
• Pruebas de aceptación en un 70% o mas.
• El código se encuentra en la receta del pipeline.
• Se tiene la aprobación del dueño de producto.
• Se ejecuta en producción la solución

HISTORIAS DE USUARIO
Componente de la lista de producto
Son los elementos más específicos
No confundir historias de usuario con requerimientos
Que quiere el usuario de nuestro producto, que quiere hacer el usuario con nuestro producto
Detallan funcionalidades, el usuario puede ser otra parte del sistema

Componentes de una Historia de Usuario:
-Título
-Descripción
Como
Componentes tecnicos
Como completar la historia
-Puntos
Esfuerzo que va a tomar al equipo de desarrollo completar la historia
-Criterios de aceptación
Que necesita la historia tener, para decir que esa historia está completa
Para que el product owner o cliente puedan decir “esto es lo que se espera”

Plantilla:
Como <rol> quien es el usuario que cuenta la historia
Quiero <acción> que quiere el usuario del sistema, que funcionalidad está buscando
Para <beneficio> para que quiero realizar esa acción

Las HU son cada elemento de la lista de producto, nos dice qué quiere hacer el usuario con el producto.

Elementos de la HU

Título: de qué trata la HU.
Descripción: cómo se realiza la funcionalidad.
Puntos: representa el esfuerzo que toma completar la HU.
Criterios de aceptación: qué necesita tener la HU para poder decir que está completa la HU.

**La descripción debe tener: **

Como: el usuario que cuenta la HU (rol)
Quiero: qué quiere el usuario del sistema (la funcionalidad)
Para: para qué quiere realizar esa acción en el producto.

**La definición de “terminado” **es una lista de requisitos para saber que la HU está terminada. Ejm:

Funcionalidad (criterios de aceptación).
Código subido en git.
Pruebas creadas y pasadas.
Documentación.

Las tres C’s:

Cards (Tarjetas).
Conversación: que el equipo se siente para conversar de las HU y entender todo sobre la HU, para que no hayan dudas en el proceso.
Confirmación: que todas las personas que trabajan en la HU lleguen a un acuerdo y confirmen que todos entendieron lo mismo.

INVEST
I - Independiente: no debe depender de otra HU, si lo es marcarse.
N - Negociable: si es muy grande para trabajar en el sprint, se puede divir y trabajarse en varios sprints.
V - Valiosa: entregar valor al cliente.
E - Estimable: esfuerzo para poderla completar.
S - Small (Pequeña): lo suficientemente pequeña para cumplir una funcionalidad.
T - Testable (Comprobable): a través de los criterios de aceptación y la definición de terminado.

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. no son requerimientos, es lo que espera el usuario del producto. que quiere hacer el usuario con nuestro proyecto
Componentes de la historia de usuario:
● Título (de qué va)
● Descripción (elementos técnicos)
● Puntos (esfuerzo que le toma a desarrollo completar la historia)
● Criterio de aceptación (que debe tener para marcarlo como finalizado)

La definición de “Terminado” en nuestro caso debe cumplir lo siguiente:

• Que la historia tenga definidas las sub-tareas que se emplearon para completarla.
• Que en la historia tenga el Pull Requets en el repositorio de GIT.
• Que QA pase la aprobación de la historia.
• Que el pull request este aprobado e integrado en la rama **development **del repositorio

En mi equipo Scrum, un Terminado debe cumplir lo siguiente:

1. Subir el código a la branch de desarrollo en el git
2. Realizar las pruebas del funcionamiento del codigo
3. Aprobadas las pruebas se sube el codigo a la branch de produccion en git
4. Se recibe la aprobación del producto por parte del Product Owner

Desarrollo de Procesos en una Suite de BPM definición de “Terminado” para mi equipo es el siguiente:

• Cumple con las buenas prácticas de programación
• Se documento que desarrollo se realizó y que nuevos componentes del desarrollo se crearon (Flujos de proceso, entidades, atributos, reglas, etc).
• Se entrega manual de usuario para entrega al cliente.
• El usuario de Testing da su VoBo para uso de las historias de usuario entregados.
• Se parametrizaron todas las nuevas entidades paramétricas.
• El Product Owner acepta la funcionalidad.

Definición de terminado:

• Que el producto sea correcto, es decir, haga lo que debe de hacer de acuerdo a la historia de usuario.
• La validación del punto anterior se realizaría con las pruebas, tanto unitarias como de estrés.
• Una vez validado lo anterior, los entregables como el código del producto y su documentación deberían estar disponibles para acoplarse al producto total.

Entendido

Revisar funcionalidad en ambiente de pruebas.
Revisar funcionalidad en ambiente de QA.
Visto bueno del cliente.
Envió de documentación al cliente.
Orden de cambio.
Estabilización de cambio.
Actualización de documentación interna y lecciones aprendidas.

El concepto de terminado viene acompañado por la revisión y prueba de la historia de usuario que contiene el proceso o tarea resuelta. Todos los miembros del equipo deben estar al tanto del avance a través de los sprints de trabajo necesarios para completar el requerimiento. En mi caso particular, una vez aprobado como completado un proceso realizo una copia del archivo fuente que estoy trabajando en figma, así como también una conversación corta con el SM para actualizar el estado de los componentes involucrados.

Definición de terminado para mi equipo scrum:
• Incremento de valor generado
• Certificación de pruebas aceptada por el cliente
• Documentación funcional y técnica entregada al cliente y resguardada en dropbox
• Backup del desarrollo en dropbox -Generación de branch en VS

Comparto el DoD de mi equipo:

• Validación y aprobación por parte del PO dentro del sprint.

• Validación y aprobación del QA en el ambiente de desarrollo.

• Despliegue de los cambios en el ambiente de desarrollo.

• PBIs con el estado actualizado en Jira a DONE.

• Generación y envío de hoja de pase a calidad.

• Envío de todas las modificaciones realizadas.

En base a mi caso y equipo de scrum, la definición de “Terminado” es la siguiente:

• Las historias estarán clasificadas o definidas en base al nivel jerárquico, es decir, (la tarea principal y sus subtareas)
• Realizar a las historias un Pull Request en nuestro repositorio GIT
• Realizar test de funcionalidades del código
• Que QA evalúe la aprobación de la historia
• Que se obtenga la aprobación del producto del Product Owner
• Documentar la funcionalidad liberada en el repositorio compartido al cliente
  🧙‍♂️🧙‍♂️🧙‍♂️

Definición de Terminado:

1. Se debe poder probar la funcionalidad en el ambiente staging, UAT.
2. El Pull Request debe ser aprobado por mínimo el 50% del equipo.
3. El coverage de código no debe ser menor al actual, mínimo debe mantenerse.
4. Todo el equipo debe tener contexto y entender la funcionalidad que se realizo.
5. El código debe tener su test de integración y test unitarios.
6. El pipeline de despliegue de la aplicación debe estar en verde.
7. El feature debe estar en producción, si por alguna razón no puede estar en producción por alguna dependencia externa, esta deberá estar apagada usando feature flags.

Muy interesante este artículo sobre la definición de terminado.

https://www.scrum.org/resources/blog/definicion-de-terminado-done

En resumen, debe haber un consenso de todas las partes para definir cuando un producto cumple con todo lo que cada stakeholder considera como aceptable.

Terminado
• Documentar las versiones
• Documentar las pruebas
• Validar/testear el diseño de la interfaz
• Validar/testear que se cumple con la funcionalidad solicitada
• Validar con el cliente

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).

El producto Terminado en el equipo:

1. Criterios de aceptación de la historia aprobado
2. Push al repositorio en la rama de la funcionalidad
3. Merge a la rama develop

Gracias

No confundir los requerimientos con la funcionalidad que el usuario quiere realizar.

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:

1. 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).

2. 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.

Para considerar la historia de usuario como terminada se debe:

1. Tener la evidencia y visto bueno de certificación de la funcionalidad.
2. Documentación: historia de usuario, casos de prueba, solicitud de cambio a producción.

Definición de terminado.
Cumple con el quien, que y para que.
El desarrollo es independiente, aceptado, valioso, pequeño
El desarrollo se encuentra congelado en el area de certificación
EL desarrollo fue certificado cumpliendo con lo requerido
El desarrollo cuenta con la documentación técnica
El desarrollo fue aprobado por el Product Owner
Si aplica, el desarrollo esta en la ventana de tiempo para su liberación. y se libera

Definición de terminado en mi caso es cuando el equipo completo (product owner, scrum master y equipo de desarrollo) aprueban cada una de las tareas detalladas que se han especificado en la historia, esto incluye obviamente toda clase de pruebas y documentación. Creo que lo importante es definir desde un principio claramente todos los puntos que se van a evaluar al final de cada sprint y al final hacer una revisión de los mismos para que no quede nada por fuera

En el marco del denominado “Terminado” para el desarrollo de una landing page de nuestro equipo es :

• Que se realice el Commit con la descripción previa, que es lo que se esta realizando de una tarea especifica, en este caso seria una Historia de Usuario única.
• Verificación/Validación que dicha Historia este realmente desarrollada como lo indicaba y la descripción de los hechos del commit.
• Pruebas unitarias de esa funcionalidad o de la Historia de Usuario. Tanto del diseño como la funcionalidad.
• Documentar la funcionalidad.
• Información para la aceptación por parte del Cliente para subirlo a producción.

• Trabajando siempre en dos servidores tanto como desarrollo y producción.

El concepto terminado básicamente comprende:

1. La funcionalidad debe estar presente en la interacción de usuario, permitiendo cumplir con el objetivo del Sprint.
2. Debe estar documentada.
3. Debe de haber pasado a un testing satisfactorio.
4. Debe ser comunicada.

Agregar sobre el issue trabajado evidencias del éxito de pruebas de funcionalidad y de integración
Documentar la funcionalidad liberada en el repositorio compartido al cliente .
Actualizar apps y/o hacer deploy, notificar al cliente e indicar si es necesario realizar algún tipo de actualización.

Un equipo de Scrum debe entender que es el " terminado" para el proyecto, debe evaluar mediante una lista cuando se ha terminado el trabajo. Por ejemplo:
1- Proyect Owner y Certificación o calidad verifican el correcto funcionamiento
2- Revisar que el código este en la ubicación que se estableció
3- Verificar que se hallan actualizado todos los cambios en el repositorio final
4-Los cambios se deben llevar en versionamientos
5- Se realizaran pruebas de regresión
6- Las pruebas se deben anexar a la documentación

Proceso de terminado:

1. Diagramación completa del Power BI.
2. Testeo de PBI de filtros y relaciones que cumplan con las necesidades del usuario realizadas por el equipo de desarrollo.
3. Pruebas de funcionalidad, acceso y veracidad de la información realizadas por el SCRUM Master.
4. Entrega al Product Owner y retroalimentación.
5. Ajustes finales
6. Acta de diagramación de PowerBI de la cuenta
7. Entrega al usuario externo.

Considero que para identificarse como terminado se debe tener una aprobación sí o sí del usuario, que atienda a los objetivos inicialmente planteados y que genere experiencia de satisfacción, ya que muchas veces en el medio se cumplen con las “tareas” pero no con los “objetivos”, ej. puedes generar el desarrollo que tenga lo que se especificó en la historía de usuario pero tiene un slow performance, entonces no estás resolviendo las necesidades del usuario final.

La descripción: si es descrita por el usuario, entonces
cómo podría tener componentes técnicos, como: la base de datos, diseño, flujo de arquitectura, …

explicación por favor

Terminado:

1. Cuando se cuenta con la documentación tanto técnica y de usuario del producto.
2. Cuando se a testeado completamente (Técnico y Funcional).
3. Cuando se comprueba que la funcionalidad de lo entregado cumple con cada uno de los criterios de aceptación.
4. En las pruebas con usuario final este de su visto bueno de lo entregado.

Definición de terminado:

• Pull del proyecto para tenerlo actualizado
• Push sobre el branch principal
• Indicar al cliente que puede realizar el control de calidad o QA de la funacionalidad desarrollada
• Recibir feedback, si es correcto, anotarlo como Terminado, si no, corregir, modificar y repetir el bucle

saludos, Dios los bendiga estimados

Una historia de usuario está terminada cuando cumple con los siguientes aspectos:
Titulo: La finalidad específica que espera obtener como resultado de la funcionalidad.
Descripción: El detalle de la tarea a desarrollarse especificando los parámetros que se sugieren utilizar para el proceso funcional de la actividad. Cabe destacar que esta descripción debe contener todos los aspectos necesarios para trabajar, entre ellos campos de formulario, bases de datos, acceso a servidores, validaciones etc.
Puntos: Nivel de esfuerzo a emplear tanto por el equipo de desarrollo por el SCRUM Master en la funcionalidad a desarrollar.
Criterios de aceptación: Aspectos con los que debe cumplir la funcionalidad para ser entregado tanto al Product Owner y al cliente final de la aplicación.
Gestor de versiones: La aplicación final debe encontrarse en un repositorio remoto para poder almacenar los diferentes archivos de la aplicación para llevar el control de versiones que la misma ha tenido en el tiempo, así mismo poder regresar actualizar la versión del sistema en caso de ser necesario para corrección de errores o actualizar elementos.
Pruebas: La aplicación será sometida a un conjunto de pruebas para verificar la funcionalidad y usabilidad de la misma. En este orden de ideas, se podrá detectar y corregir errores antes de entregar producto final al cliente.

Mi definición de terminado

• Que se cumplan con los criterios de aceptación.

• Que se guarde soporte de las pruebas exitosas realizadas.

• Que se presente al product owner la funcionalidad probada.

• En caso que aplique que se entregue el manual de usuario.

La definición de Terminado en mi equipo de Scrum:

• Cuando se cumple en su totalidad el incremento diario de puntaje de cada Historia, reportadas en la ceremonía de Daily Scrum.
• Luego, los miembros encardo de desarrollar cada Historia, sube al repositorio los cambios efectuados.
• A continuación, la revisión de la Historia o el desarrollo en la aplicación Test.
• Al final, si la Historia cumplio con los criterios expuesto y el cliente se siente sastifecho con el producto entregado se dice que esa Historia está terminada.

Definición “Terminado”: Cuando el sistema cumple la funcionalidad propuesta en el sprint y esta fue desarrollada, probada y documentada por el equipo.
Si la funcionalidad no funciona o no esta completa entonces no se ha terminado y puede vivir almacenado en git sin haber hecho push.

La definición de terminado se puede definir como aquella funcionalidad que cumple con los criterios de aceptación definido por el Product Owner en las historias de usuario.

excelente curso

Historias de usuario: Define una pequeña funcionalidad del producto, no es un requerimiento si no la funcionalidad que desea el usuario

Partes de una historia de usuario:
Titulo:
Descripción: quien, que quiero, para que
Puntos: Esfuerzo
Criterio de aceptación

Caracteristicas de una historia:
Independiente
Negociable
Valiosa
Estimable
Small
Testable

Epicas: Agrupa historias de usuario

Quien escribe las Historias de usuario?
Sabemos que en la cultura Agil, hablamos de trabajo en equipo en donde todos los miembros colaboran entre si para desarrollar un producto con la mayor calidad posible y que brinde Valor al negocio, es por ello la importancia de que todos esten involucrados en la creacion de las HU.
Ademas no olvidemos que existe una reunion dentro del Sprint dónde se recomienda que estén todos los miembros del equipo, que comúnmente se llama refinamiento del backlog de producto (Backlog Refiement). Aqui es donde todo el equipo de acuerdo a su conocimiento y experiencia aplican diversas tecnicas y herramientas con la finalidad de ayudar al equipo a entender claramente de que trata la historia de usuario, que es lo que realmente se quiere alcanzar y que realmente necesita el usuario y de esta forma tomar la mejor ruta para poder abordarla y desarrollarla llegando a cumplir con el DoD.

La funcionalidad debe ser prioridad

Les dejo mis mapas 😄

Historias de Usuario

Las historias de usuario son la definición de las funcionalidades que el usuario espera del producto, siendo los elementos más específicos del product backlog. No se debe confundir las historias de usuario con los requerimientos, ya que la información brindada en cada caso es diferente en contenido y forma, las historias de usuario suelen ser más cercanas al punto de vista del usuario.

Hay que tener en cuenta que no siempre por usuario se hace referencia a la persona que usa directamente el producto, sino que puede aludir a otro sistema con el que se debe permitir la interacción (por ejemplo, al desarrollar una API o una librería).

Para que las historias de usuario sean fáciles de entender por el equipo y faciliten el proceso, éstas deben tener los siguientes componentes:

• Título: Explica en pocas palabras y de forma clara de qué se trata la historia de usuario.

• Descripción: Explica cómo se va a solucionar la historia, los pasos que el usuario debe seguir. Puede incluir componentes técnicos como diseño de la interfaz a implementar, flujo de la arquitectura que va a seguir, forma de almacenamiento de datos, etc.

  Para ayudar a la formulación de la descripción, se puede tomar lo siguiente como plantilla:

  • 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 quiere realizar esa acción o disponer de esa funcionalidad.

  Por ejemplo:

  Como administrador, quiero disponer de doble factor de autenticación para incrementar la seguridad en caso de que se usen contraseñas débiles.

• Puntos: Esfuerzo que le va a tomar al equipo desarrollo implementar la historia de usuario. Permite estimar tiempo y complejidad.

• Criterios de aceptación: Qué necesita la historia tener la solución implementada para que pueda tomarse como completada. Permite al equipo determinar si eso es lo que se esperaba de la historia.

Si bien los criterios de aceptación sirven para definir cuando se completó una historia, esto es desde el punto de vista del usuario, pero para considerarla realmente completada lo usual es definir una serie de elementos requeridos para considerarla como completa. Dichos requisitos pueden variar según el proyecto, pero los más comunes son:

• Criterios de aceptación: Que lo desarrollado satisfaga lo definido en la historia de usuario.

• Sistema de control de versiones (git): Asegurarse de que los desarrolladores hayan hecho push para subir los cambios, todos deben tener la misma información.

• Tests: Crear y ejecutar tests unitarios, funcionales, de regresión, etc, y su documentación. Permite probar de forma automática lo desarrollado y asegurar que no se dañaron otras funcionalidades.

• Documentación: Documentación del código adecuada y respetando criterios definidos, actualización de manuales de usuario o de procedimientos, etc.

Es una buena práctica antes de planificar el sprint, invertir tiempo en la planeación de las historias de usuario para maximizar el tiempo de entendimiento del equipo de desarrollo de estas historias, para lo cual se puede emplear la técnica de las tres C’s:

• Cards (Tarjetas): Plantilla donde se escribe la historia de usuario.
• Conversación: El equipo se reúne con el Scrum master, product owner o incluso con el cliente para conversar sobre esta historia de usuario y entender absolutamente todo sobre ella.
• Confirmación: Todos deben estar de acuerdo en que entendieron lo que se busca solucionar y cómo hacerlo.

Otra forma de lograr invertir de forma correcta en las historias de usuario es cumplir con lo siguiente:

• I (Independiente): No debe depender de otra historia de usuario, y si lo hace, no puede comenzar a trabajarse hasta que se complete su dependencia.

• N (Negociable): El equipo debe poder negociar con el product owner si considera que la historia de usuario debería dividirse en historias más chicas.

• V (Valiosa): Debe entregar valor al cliente, que sienta que cada vez es más completo y útil.

• E (Estimable): Debe poderse estimar el esfuerzo que será necesario por parte del equipo de desarrollo para completar la historia de usuario.

• S (Small, pequeña): Suficientemente pequeña para cumplir una funcionalidad. Si abarca varias funcionalidades posiblemente se trate de una épica, no de una historia de usuario.

• T (Testeable, comprobable): Se debe poder comprobar que se completó la historia a travez de los criterios de aceptación y la definición de completado.

¿Qué son las Historias de Usuario?
Elementos más específicos del Product Backlog, contiene la visión sobre la funcionalidad esperada del producto.
Componentes

• Título
• Descripción
  - Como <rol>
  • Quiero <acción>
  • Para <beneficio>
• Puntos
• Criterio de aceptación

Definición de una historia completada:

• Criterios de aceptación cumplidos.
• Código subido a git.
• Pruebas creadas.
• Documentación.

Inviertiendo tiempo en historias
Tres c

• Cards (Tarjetas)
• Conversation.
• Confirm.

I - Independiente
N - Negociable
V - Valiosa
E - Estimable
S - Small (Pequeña)
T - Testeable (Comprobable)

Definición de terminado:

• Funcionalidad.
• Incidencias resueltas.
• Pruebas de testing culminadas.
• Código subido al GIT.
• Documentación.
• Envío de request para salir a producción.

En mi caso, yo realizo entregas de proyectos enfocados a hardware, por lo que el “terminado” de la documentación sería:

• Aprobación del árbol de ensamble respecto a la Guía de Verificación de Diseño
• Aprobación de cada plano respecto a la Guía de Verificación de Diseño
• Aprobación de cada lista de partes respecto a la Guía de Verificación de Diseño
• Aprobación del código firmware respecto a la Guía de Verificación de Diseño
• Aprobación de la portada de carpeta respecto a la Guía de Verificación de Diseño
• Subir a la nube los planos
• Cuando los planos están completos, se aprueba la carpeta de proyecto

Las historias de usuario son los elementos más específicos de la Lista de Producto. Qué quiere el usuario.

Historias de usuario =! requetimientos

Componentes de la HU

• Título
• Descripción (indicar cómo)
• Puntos (esfuerzo que va a tomar para completar)
• Criterio de aceptación (qué necesita la historia para decir que está completa)

Está completo un proyecto cuando:

• Es funcional
• Código en repositorio
• Pruebas creadas
• Documentación

Yo trabajo implementando una herramienta de web analytics en los sitios web. Para hacerlo, nosotros definimos una estructura de tagging, la cual servirá de guía para crear un Data Layer. Ese Data Layer se inyecta en la herramienta de web analytics, usando una otra herramienta de tag management. Una vez la herramienta de web analytics pueda leer el Data Layer, los datos se podrán ver y analizar desde la herramienta de web analytics.

Así que, mi definicion de terminado sería:

• Que haya un SDR (Solution Design Reference) aprobado por el cliente, que va a servir como un blue print de la implementación que tenga el sitio web.
• El sitio cumple con todos las reglas del Cookie Consent.
• El data layer creado por el dev team esté aprobado por nuestro equipo, ya que el mismo cumple con el diseño que hemos propuesto.
• Estamos pasando todos los data elements en cada acción que vamos a trackear.
• El data layer está pasando datos a la herramienta de web analytics.
• Se le entregó un dashboard al cliente, monstrando el perfomance de su sitio web.

Definición de “terminado” en gestión de vulnerabilidades:

• Confirmación de cierre de la vulnerabilidad con un nuevo scan ejecutado sobre el componente.
• Documentación de acción de remediación de vulnerabilidad en un estandar documental en Azure DevOps.
• Reunión de aprobación del cliente sobre el paquete de vulnerabilidades cerradas.

Mi definición de Terminado :

Entrarian a jugar los componentes de historia del usuario:

1. Funcionalidad, debe quedar en estado ok y funcional.
2. Codigo subido en git para dejar soportar evidencia de finiquitado.
3. Purebas creadas. Dejar la lista de pruebas creadad para dar la ejemplificación si presenta una falla, como se puede solucionar.
4. Documentación, importante para dar seguridad al produto finalizado.

Cuando se considera que una historia esta terminada:

• Cumple con los estándares de calidad del proyecto/empresa.

• Es funcional para el cliente.

• Se realizaron pruebas que prueban su resiliencia a fallos.

Definición de terminado. En mi caso de uso nuestra área combina desarrolladores y equipo de soporte al cliente. Estamos haciendo algo como Scrumban.

• Push de commits sobre branch, haciendo referencia al número de issue trabajado./presentación de tarea haciendo referencia al número de issue.
• Aprobación del pull request o tarea de al menos 2 miembros del equipo de desarrollo o dos miembros del equipo de soporte.
• Documentar en la herramienta usada por la compañía
• Deployment o implementación
• Aprobación y satisfacción del cliente externo o interno.

La Definición de terminado para mi equipo se da cuando:

• Se finalizan las pruebas de QA con su respectiva documentación.

• Aprobado por el P.O. sobre los criterios de aceptación.

Definición de Terminado
La definición de terminado en nuestro equipo para una historia debe incluir:
Una lista de funcionalidad sobre el sprint comprobada y terminada
Un lugar donde la información haya quedo almacena.
Un diseño terminado y subido a la plataforma.
Documentación de acompañamiento sobre el trabajo desarrollado.

Definición de terminado:
Casos de Pruebas Propios
Documentado
Push del branch en desarrollo
Aprobado por el team

Cuando hablamos de definición de terminado hacemos referencia a cuando ya se tiene un producto entregable. En el caso de mi línea de negocio se hace referencia a tener un entregable de un desarrollo de acuerdo a la necesidad del cliente, creado dentro de un determinado tiempo y listo para ser certificado por nuestro equipo de calidad.

Hay varias preguntas del examen que están erróneas.

Definición de terminado:

• Cumplir los criterios de aceptación de la funcionalidad

• Subir las evidencias de las pruebas unitarias al repositorio

• Contar con el vobo de QA

• Promover los cambios a la rama estable relacionando el identificador de la historia de usuario trabajada

• Subir documentación interna al repositorio

• Subir documentación para usuario final al FTP en la ruta X

• Preparar el delivery al cliente

Definiciòn de terminado:

• Aprueba los criterios de aceptaciòn.
• Tiene documentación con el modelo C4
• Esta en un repositorio
• Se aprobaron pruebas unitarias

INVEST

Excelente explicación de como crear la HU.

Actualmente usamos estas pero posiblemente evaluamos más opciones este año

• Criterios de aceptación
• QA
• Revisión por parte del cliente

Los componentes de la historia de usuario pueden ser un poco confuzos, por eso me gusta leerlos como:

• Quien?
• Que?
• Para que?

creo que asi es un poco mas claro

Que interesante porque ademas son metodologias totalmente diferentes para el manejo de los proyectos!

Definición de terminado:
• Entrega de la funcionalidad subida al git.
• Documentación del código de la funcionalidad.
• Documentación para el usuario.
• Casos de prueba de la funcionalidad.
• Pruebas de calidad de la funcionalidad y evidencia.
• Validación del scrum master.
• Validación del product owner.
• Validación del cliente.

Para los PO es importante tener el DOR que es como mostrar una historia lista para ser refinada. Por otro lado el DOD es para el scrum dado que somos un equipo PO y SM es bueno decidir estas caracteristicas con el equipo 😄

el audio o mejor dicho la voz del profesor se entrecorta cada vez que deja de hablar y vuelve a sonar abruptamente cuando inicia a hablar, sera mi parlante?

Definición de Terminado:

• Se cumplen los criterios de aceptación de la funcionalidad.
• Se realizaron las pruebas unitarias y funcionales. La tarea ha sido verificada y validada.
• Se ha completado la documentación correspondiente.
• El cambio ha sido puesto en producción

Terminado:

• Que la aplicacion este operando en produccion,
• Que la documentacion este en manos del cliente
• Que se tenga una copia de la version de la aplicacion que esta en produccion en nuestro servidor o Nube

¿Qué nos cuentan las Historias de Usuario?
¿ Que son las historias de usuario ?
Las historias del 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
• Titulo  Permite saber de que se trata la historia.
• Descripción  Nos dice como se debe realizar la historia.
• Puntos  El esfuerzo que tomara al equipo de desarrollo completar la historia
• Criterio de Aceptación  Que necesita tener la historia para decir que la historia esta completa.
Plantilla de Scrum
Descripción:
Como <rol>
Quiero <acción>
Para <beneficio>
Ejemplo:
Como estudiante
Quiero poder completar evaluaciones en la plataforma
Para poder ser evaluado y tener una calificación
La definición de completo son la lista de elementos requeridos para saber que una historia esta completa. Ejemplo:
• Funcionalidad ( Criterios de Aceptación )
• Código subido en git.
• Pruebas creadas.
• Documentación.
Invirtiendo en Historias
Las tres C’s:
• Cards ( tarjetas ).
• Conversación.
• Confirmación.
• I – Independiente: No debe depender de otra historia de usuario, y si lo hace, debe marcarse con tiempo.
• N – Negociable: Si la historia es muy grande se negocia para dividir la historia.
• V – Valiosa: Debe entregar valor al cliente.
• E – Estimable: Tener un estimado de como y cuanto esfuerzo se le debe dar a la historia para completar.
• S – Small ( Pequeña ): Pequeña para cumplir una funcionalidad.
• T – Testeable ( Comprobable ): Debe comprobarse que la historia se ha terminado.

el concepto de terminado debe tener presente un valor agregado para las operaciones y para el desarrollador, la medición real del beneficio se aplicara sobre el tiempo que se ahorra en la ejecución de procesos manuales, que permiten aprovechar estos tiempos en proyectos que incrementen el valor profesional del equipo

Raza, me confundí un poco con el concepto de Historias de Usuario, pero les dejo este link que deja el concepto y su uso más claro: https://scrum.mx/informate/historias-de-usuario

Lávense las manos, porfa ❤️

Trabajo con muchas tareas, por eso cuando sabemos y se a comprobado que la tarea esta terminada, la damos por terminada.

1. Quien realiza las épicas y la lista de historia? el product owner o el scrum master?
2. en la etapa de análisis (tanto de datos como de entendimiento de reglas de negocio y si los datos existen o serán nuevos. Modelos existentes nuevos etc…) esta parte de hace un sprint o dos sprint donde incluya a todo el equipo? O el análisis lo hace el scrum master y le pasa la info al equipo mas digerida?? (aunque sigo viendo importante que los desarrolladores tengan este conocimiento de análisis propio cuando se empapan del proyecto, sin tener esto masticado es fácil como desarrollador equivocarse)

1. tenemos el código almacenado en un repositorio y debidamente comentado.
2. Tener los requerimientos debidamente desarrollados al final del sprint o el desarrollo.
3. Haber realizado pruebas de funcionalidad del producto en ambientes controlados.
4. Documentar detalladamente las funcionalidades para que así el cliente pueda observar el valor agregado que pueda existir en cada una de ellas.
5. Tener claro el versiona miento que ha sufrido la aplicación y también el nivel de adaptabilidad que tendrá a futuras características o funcionalidades.

Para nuestro equipo la definición de terminado, aplica lo siguiente:
• Identificar las tablas y bases de datos a las cuales se les realizará el cambio.
• Identificar claramente los procesos y los sistemas afectados para la implementación de la solución.
• Identificar el alcance de la solución.
• Realizar pruebas de concepto, unitarias, usuario, integración, etc…
• Identificar todos los protocolos y configuración de los sistemas a los cuales se verán impactados.

“Terminado”
saber cuántos elementos de la Lista de
Producto puede seleccionar durante la Planificación del Sprint.