¿Cómo crear 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.

Dato de Test:

¿Quién puede agregar historias de usuario a los distintos backlogs?
“Cualquier miembro del equipo”

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:

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

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

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

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.

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.

¿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

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

¿Quién escribe historias de usuario?

**++Cualquiera puede escribir historias de usuario++**. Es responsabilidad del **Product Owner asegurarse de que exista una Product Backlog actualizado y priorizado** de historias de usuario ágiles, pero eso no significa que el Product Owner es quien los escribe.

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

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.

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

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

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.

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.

excelente curso

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.

En mi equipo de trabajo pudiera aplicar que un sea considerado terminado debe cumplir mínimo con estos:
Que haya sido probado
Que el usuario haya validado la funcionalidad

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.

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

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.

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.

Este es un proyecto personal y escogí este requrimiento para prácticar el cuál quise compartir con ustedes. Con este ejercicio práctico me llevo a determinar los siguiente:

Lo mas importante es el “para” ya que me llevara a determinar la funcionalidad el resto se podría decir que es un patrón para llevar al “para”. Abro debate en este comentario.

Una epicas es un conjutno de historias

Descripción o Narrativa

La descripción generalmente sigue un formato simple que ayuda a entender quién es el usuario, qué necesita y por qué lo necesita. Un formato común es:

Como [tipo de usuario],
quiero [una acción]
para que [beneficio/valor].

Artefactos escenciales de SCRUM:
· Product Backlog
· Sprint Backlog
· Incremento (resultado tangible y entregable)

1. ¿Tenemos un lugar a dónde el código debe quedar almacenado?
   Es importante para el equipo de Scrum crear un repositorio para realizar una copia de seguridad a todas las historias terminadas, de esta manera otro colaborador puede acceder y tomar la información para su disponibilidad.
   La forma general del comando es esta:
   $ git push <remote> <branch>
   remote: repositorio remoto / branch: rama
   B. ¿Se debe hacer push en una branch determinada?
   Así es, los parámetros se cargan por defecto. Ejemplo

• Por defecto, Git elige origin como remoto y tu rama actual como la rama a la que subir.
• Si tu rama actual es main, el comando git push suministrará los dos parámetros por defecto — ejecutándolo así git push origin main.

1. ¿Cuál es la documentación mínima necesaria en la compañía?

 Contar con la disponibilidad de la herramienta. Ejemplo (Jira)
 Contar con las Épicas
 Contar con las historias de Usuario
 Contar con el documento estándar para realizar la documentación
 Criterios de aceptación de la documentación.

B. ¿A dónde se debe guardar esta información?

Se guarda en un repositorio local y un repositorio en la nube por seguridad y para disponibilidad de los responsables del proyecto.
3. ¿A dónde se debe almacenar versiones finales de diseños y similares?
Los diseños deben encontrarse en herramientas como canva o como Lucid cuando han sido creados y colocar accesos para evitar la modificación o eliminación de los mismos.
4. ¿Hay casos de prueba obligatorios que se deban tener? ¿Se deben guardar esos resultados?
Para el caso de un proyecto de programación en efecto se requieren pruebas obligatorias y se debe realizar un Backup de resultados e ir trabajando sobre nuevas versiones.
5. ¿Quién debe validar que la funcionalidad haga lo que el usuario espera?
A nivel de proyecto Scrum Master el responsable es el Product Owner, porque este se encuentra de cara de frente al cliente. A nivel de pruebas y desarrollos los QA o los Gestores de calidad.

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)

Cómo definir que una Historia de Usuario está terminada
La definición de “completo” en una Historia de Usuario debe incluir la lista de elementos requeridos. Este es un ejemplo:
✅ Funcionalidad, es decir que los criterios de aceptación se cumplen.
✅ Sistema de gestión del código o de versiones, en el caso de git, debemos hacegurar que el programador hizo su respectivo commit con la última versión del código.
✅ Pruebas creadas, es decir, que los casos de pruebas están creados y documentados para que estas se puedan correr y estar seguros de que la historia de usuario funciona (de regresión, unitarias, funcionales, de rendimiento)
✅ Documentación. El código debe estar bien documentado, y debe incluir un manual de historia de usuario.

Qué nos cuentan las historias de Usuario
Las historias de usuario es la historia que el usuario nos está contando. Esto hace referencia a la funcionalidad deseada por el usuario, lo cual no es lo mismo que un requerimiento.
Que debe tener una historia de usuario
Una historia de usuario debe contener:
• 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. Es una definición más específica de como poder completar la historia debe ir en la descripción
• Puntos. Estos hacen referencia al esfuerzo que le tomará al equipo de desarrollo completar esta historia
• Criterio de Aceptación. Aquello que necesita la historia para que el product Owner o el usuario puedan concluir que dicha historia es lo que se espera.

Agregar sobre el issue trabajado evidencias del éxito de pruebas de funcionalidad y de integración

Cuando un elemento de trabajo se considera “Terminado” en Scrum, significa que ha pasado por todas las fases necesarias de desarrollo, prueba y revisión, y está listo para ser entregado y puesto en producción si es necesario. Con la etapa de “Terminado” estan:

• Cumplimiento de los Criterios de Aceptación
• Pruebas y Verificación
• Revisión
• Documentación
• Integración
• Despliegue (si es necesario), si el trabajo se está entregando a producción, debe estar listo para ser desplegado en el entorno de producción sin problemas.

-Todo el código fuente esta completo y actualizado en el repositorio de control de versiones del equipo
-Se han escrito y aprobado pruebas unitarias para cada una de las funciones o características implementadas, y estas pruebas se han ejecutado satisfactoriamente.
-Se ha comprobado que no existen errores de integración.
-Se han llevado a cabo pruebas de aceptación con el cliente o usuario final
-Product Owner esta conforme con el incremento.
-La documentación esta completa y actualizada, incluyendo la documentación de usuario, la documentación de desarrollo y cualquier documentación de ciberseguridad necesaria.
-Se han implementado medidas de seguridad, incluyendo pero no limitado a, autenticación, autorización, cifrado, validación de datos y prevención de ataques conocidos
-Se ha verificado que se cumplen los estándares de ciberseguridad de la organización.
-El producto o funcionalidad implementada esta en cumplimiento con las leyes y regulaciones aplicables en el país o provincia correspondiente.

Para mi equipo la definición:

• se despliega en el ambiente de pruebas
• se realiza las pruebas unitarias, funcionales y revisión de calidad técnica.
• código versionado en la rama git de desarrollo.
• se actualiza el documento de especificación técnica del requerimiento y se tiene listo el manual de instalación
• una vez completado se realiza el pase al ambiente de certificación donde se realizan
• pruebas funcionales , pruebas de rendimiento.
• una vez ok se procede a subir a producción

Las 3 C´s tambien podria ser

• Cards (Cartas)
• Conversación y
• Confirmación.

Para llegar al entendimiento común.

para considerar Terminado, se debe cumplir:
Funcionalidad: que se cumple la funcionalidad o criterios para aceptarla.
Código: su respectivo control de versiones
Pruebas: las necesarias y su documentación
Documentación: todo el material necesario para documentar.

Definición de HU terminado

• Pull request a la rama dev y que éste aprobado
• Cumplir con el diseño propuesto
• Realiza la funcionalidad descrita
• Cumple con los criterios de aceptación
• Las pruebas sobrepasan el 80% de satisfacción
• Los entregables se encuentran en el repositorio