Estrategias Efectivas para Historias de Usuario en Proyectos Ágiles

Clase 4 de 11 • Curso de Historias de Usuario en Scrum

Karla Sequen

student•

Cuando todo urge nada realmente importa, porque si todo urge tiene la misma importancia y si tiene la misma importancia no importa el orden en que lo hago.

Vanessa Amaya

teacher•

Amen. :)

Felipe Bernardo González Barranco

student•

:clap: :clap: :clap: :clap:

Nicolás Kryvenki

student•

++Estrategias para poder habilitar HU de manera efectiva:++

Contexto → Las historias de usuario como centro:
- Entendimiento del problema: Saber que problema está resolviendo, o que solución se está implementando.
- Objetivos de negocio: Entender que el retrabajo, la falta de entendimiento y la falta de calidad afecta a nuestro negocio.
- Requerimientos técnicos: Debemos entender la funcionalidad como centro, pero alrededor debemos considerar requerimientos técnicos derivados (Backend).
- Requerimientos de Transición: Todas las tareas que se necesitan hacer dentro del equipo, proyecto y con el cliente para pasar de “ya terminé”, a “ya entregué”. Temas de administración, técnico(cambio de ambientes).
INVEST:
- Independent: La HU debe estar lo mas independizada posible. Muchas funcionalidades = HU épica.
- Negotiable: Poder descartar historias conforme vamos avanzando en los sprints una no es tan valiosa. Poder negociar → quitar y también priorizar cuales son las más importantes.
- Valuable: Cuando queda claro y entendido el para qué, nos permite saber que una historia es valiosa y saber cual es su beneficio.
- Estimable: Para que algo sea estimable, el equipo o la persona que hará realidad esa funcionalidad tiene que poder decir cuanto tiempo o esfuerzo considera que le demandará. Si por el contrario no es capaz de estimar cuanto tiempo/esfuerzo le pueda tomar, significa que esa historia no es estimable y le falta claridad y reforzar entendimiento de la HU y refinarla.
- Small: Se procura que sea pequeña porque es importante darle peso al entendimiento y la conversación, no a la especificación. Lo hacemos pequeño para provocar conversaciones que alimenten el contexto.
- Testable: Hacerla comprobable, cuando los criterios de aceptación existen y entonces se verifica si esa HU se está haciendo correcta o incorrectamente.

Felipe Bernardo González Barranco

student•

Gracias!

Beder Danilo Casa Condori

student•

buen resumen

Yeiner Morales

student•

Requerimientos de transicción : Los pasamos muchas veces por alto por ejemplo el tema de los ambientes de desarrollo. \n

Propiedad INVEST

I - Independent (Independiente : Muchas funcionalidades igual a HU Épica)

N - Negotiable (Negociable)

V - Valuable (Valiosa : Toda historia debe contar en un para que)

E - Estimable (Cuanto tiempo puede llevar desarrollar la HU. Si no es estimable es muy posible que le falte claridad a la Historia de Usuario)

S - Small (pequeña )

T - Testeable (Comprobable)

Si todo Urge nos falta dar prioridades a las HU.

Luis Arturo Valdivieso

student•

Solo aportaria como necesario un enfoque adicional , el tema de diseño (UX/UI) como complemento a la perspectiva técnica y de negocio ya que al no considerarlo podríamos perder de vista el objetivo final, que es la experiencia que el usuario final tendrá

Nestor Perez

student•

Estrategias

DIMENSIONAMIENTO

Poder del contexto
1. Entendimiento del problema: Entender el origen de lo que me están pidiendo.
2. Establecer objetivos del negocio: Todos debemos conocer de que manera impactan los objetivos.
3. Requerimientos técnicos: Lo que es necesario para entregar el producto.
4. Requerimientos de Transición: Considerar que entre ambientes pasan eventualidades que pueden provocar fallos inesperados.

PROPIEDADES IVEST

Estas propiedades estan relacionadas con las historias de usuario.
Verificar que cada Historia de Usuario tenga estas propiedades.
- I : Independent. Cuidar que no sean Epicas.
- N: Negotiable. Poder de descartar historias no valiosas, negociar el orden y la priorización.
- V: Valuable. Toda historia de usuaria debe ser valiosa cuando queda claro el "para que".
- E: Estimable. El equipo de desarrollo, debe de calcular el tiempo y esfuerzo que le llevara cumplir con la HU.
- S: Small. Se da mas peso a la conversación que nos alimenten el contexto.
- T: Testeable. Valida que los criterios de aceptación, y especifica si la HU esta siendo "correcta" o "incorrecta".

Beder Danilo Casa Condori

student•

genial

Sandra Sierra

student•

Siguiendo las recomendaciones, aca van un par de HU refinadas:

Julian Bohorquez

student•

El objetivo es asegurar el entendimiento del problema y llegar a la solución correcta

Se debe entender el problema… esto es muy importante, tener el contexto claro sobre cual es la oportunidad de mejora que se quiere aprovechar, entender el origen, entender porque están pidiendo esto.

Establecer objetivos de negocio… los productos son para hacer negocio.

Requerimientos técnicos. Todo lo que hay que hacer técnicamente y muchas veces no se ve.

Requerimientos de transición, todo lo que hay que hacer para desplegar o asegurar la entrega del desarrollo,vistos buenos, procesos, cambio de ambiente, despliegue, pull request, pruebas, entre otros.

Estrategia INVEST

la historia de usuario debe ser

Independiente: debe ser una funcionalidad independiente, simple e independiente, lo mas posible.

Negociable: Poder negociar orden, priorización, funcionalidades que se hacen innecesarias.

Cuando todo urge, nada realmente importa = síntoma de que todo se esta priorizando

Valiosa: toda HU debe de ser valiosa, esto se logra dejando claro el para que de esa HU.

Estimable: debe poderse decir cuanto tiempo, esfuerzo va a tomar esa HU.

Small, pequeña: las hu deben ser como un post-it debe ser pequeña, no debe ser un documento muy largo. Debe darle prioridad a que se entienda y no a que sea especifico.

Testeable/comprobable: esto esta basado en los criterios de aceptación, se debe poder comprobar que se cumplió, basado en los criterios fe aceptación

Ángel Alberto Jarrín Rivas

student•

¿Es válido plantear que los criterios de aceptación deben ir términos de necesidad?

¿Si el equipo de desarrollo es lo bastante experto y hábil es necesario realizar especificaciones cómo por ejemplo la estructura de un correo (en la historia de usuario)?

¿En una historia de usuario donde se requiera hacer búsqueda de información debería ser necesario plantear cómo debería ser el comportamiento? o ¿es una tarea que queda a la creatividad y decisión del UX?

Muchas gracias.

Vanessa Amaya

teacher•

Hola Angel! Los criterios de aceptación van más en el términos de calidad, es decir, condiciones que necesitan existir para considerar que esa funcionalidad en especial se va a realizar correctamente. Dentro de esas condiciones podrían estar comportamientos esperados y ya el equipo de UX resolverá como alcanzar esos comportamientos. Recuerda que las Historias de Usuario son generadas por los Product Owners quienes se encargan del "QUE" y el equipo se encarga del "COMO".

Lo más importante de las Historias de Usuario no es su redacción sino su conversación, no son especificaciones que pasan de unas manos a otras, con conversaciones que nos ayudan a entender hacia donde vamos.

Ahora, no todo va en una historia de usuario, ejemplo, si una funcionalidad está relacionada a una fórmula matemática muy compleja, no se pone esa fórmula en la Historia pero se puede hacer referencia a ella y contar con un anexo que la explique o una hoja de cálculo que simule la fórmula para que quede claro cómo programarla y qué datos necesitamos.

Espero haya aclarado tu duda, si no, dime :)

Ángel Alberto Jarrín Rivas

student•

Excelenta Vanessa. Creo que me has respondido.

No obstante, te cuento que aveces no logro entender esa "delgada línea" entre la conversación y especificar a profundidad ciertos criterios (como un comportamiento específico). Es una confusión que últimamente está presente, esto porque pasé de una empresa del sector financiero donde apenas estaban aprendiendo de HU, y normalmente se acostumbraba y me acostumbraba a la documentación extensiva. Ahora hago para de un Agile Team en una fábrica de Software y trabajamos con HU, pero siempre queda esa sensación de que la HU queda incompleta así esté completa ¿me hago entender?

¿Habría alguna sugerencia que podrías brindarnos a quienes hayamos trabajado con documentación extensiva y estemos ahora trabajando de lleno con HU?

Mil gracias por tu respuesta.

Camilo Cubides

student•

![](

¿Qué tal esta hu?

Vanessa Amaya

teacher•

Hola!

Lo único que veo fuera de lo común al hacer historias de usuario es la pregunta de ¿cómo opera el sistema actualmente? y la pregunta de ¿Qué problema ayudará a resolver? va incluída en el PARA, es decir, en la estructura de la HU la parte del PARA cubre el beneficio de tener esa funcionalidad o esa característica.

En los Criterios de aceptación, evaluar si es posible agregar algo cuantitativo a cada criterio o una aclaración concreta y necesaria, por ejemplo: Se generará un identificador único para cada solicitud de crédito con el formato AA100. Se podrá ver el listado de solicitudes de crédito y su estatus, los estatus pueden ser X, Y Z. Se podrá editar una solicitud de crédito siempre y cuando XXXXXXX.

Aparte de hablar de lo que se puede, evaluar si es importante aclarar alguna restricción, es decir, algo que no se debe de permitir hacer.

Las especificaciones no se hacen solo con Historias de Usuario, si es necesario, la HU puede hacer referencia en los criterios de aceptación a otros documentos o anexos.

Gustavo Scipioni

student•

Estrategias para poder habilitar HUs de manera efectiva

Las historias de usuario como centro, la funcionalidad como centro

4 partes a consideras:

Entendimiento del problema: Entender el origen del problema que el cliente está pidiendo
Objetivos de negocios.
Requerimientos técnicos
Requerimientos de transición: todo lo que se necesita para pasar de “ya termine” a “ya entregué”.

Propiedad INVEST

I - Independent (independiente) N - Negotiable (negociable) V - Valuable (valiosa) E - Estimable (estimable) S - Small (pequeña) T - Testable (comprobable)

LEONARD CUENCA

student•

Clase 4: Estrategias para poder habilitar HUs de manera efectiva

4 Partes importantes:

1er -> Entendimiento del problema ó entender el origen -> Porque nos piden el sistema
2do -> Objetivos del Negocio -> Nuestro trabajo de cada día afecta el negocio.
3er -> Requerimientos Técnicos -> Se desea saber lo necesario para poder desarrollar nuestro producto.
4to -> Requerimientos de transición -> elementos que necesitamos saber para poder consolidar el desarrollo final de nuestro producto, es evitar que todo funciona en mi máquina.

Propiesdades INVEST

Independent: La HU debe estar lo mas independizada posible. Muchas funcionalidades = HU épica.
Negotiable: Poder descartar historias conforme vamos avanzando en los sprints una no es tan valiosa. Poder negociar → quitar y también priorizar cuales son las más importantes.
Valuable: Cuando queda claro y entendido el para qué, nos permite saber que una historia es valiosa y saber cual es su beneficio.
Estimable: Para que algo sea estimable, el equipo o la persona que hará realidad esa funcionalidad tiene que poder decir cuanto tiempo o esfuerzo considera que le demandará. Si por el contrario no es capaz de estimar cuanto tiempo/esfuerzo le pueda tomar, significa que esa historia no es estimable y le falta claridad y reforzar entendimiento de la HU y refinarla.
Small: Se procura que sea pequeña porque es importante darle peso al entendimiento y la conversación, no a la especificación. Lo hacemos pequeño para provocar conversaciones que alimenten el contexto.
Testable: Hacerla comprobable, cuando los criterios de aceptación existen y entonces se verifica si esa HU se está haciendo correcta o incorrectamente.

Nota

Cuidado con todo URGE es un sistema que nada es importante
Toda HU debe tener una historia valiosa
Esto es para internos colaborativos, debemos darle voz y voto a todos los colaboradores
Deben ser historias pequeñas, para poder ser entendible y fácil de dirigir
El Scrum te dice el qué pero NO el como!!!

Alexandra Cáceres

student•

Gracias por este apunte

Ogden Gómez

student•

Aconsejo que solo se de contexto y velar por la mejora de los desarrolladores porque si se les pone carga de negocio afecta su seguridad psicológica. Y esta última es crucial para un equipo de alto rendimiento.

Diaz Mauricio

student•

Gracias

Felipe Bernardo González Barranco

student•

Debemos tener el contexto total de lo que hacemos y saber que las historias viven en un conjunto donde confluyen con otras decisiones

Diaz Mauricio

student•

Gracias

Kelly Natalia Gonzalez Artunduaga

student•

Profe una pregunta es recomendable manejar el sprint por horas o por objetivos ?

Miguel Ángel Santana Guzmán

student•

En la parte del benefico de una HU, ¿Se podía responder a un "porque" en lugar de "para qué"?

Dani Landa

student•

Sí y no. Responder ¿para qué? Habla de ventajas, beneficios de hacer algo. Responder ¿por qué? Llena motivaciones, razones.

¡Saludos!

DIEGO FERNANDOCASTAÑEDALOAIZA

student•

Hola, Vanessa. Me gustaría recibir tu recomendación en cuanto a la redacción de los diferentes criterios de aceptación ¿es recomendable inciar cada criterio de aceptación con un verbo en infinitivo? Ejemplo:

permitir solo caracteres numéricos en el campo documento
permitir solo 10 caracteres en el campo documento.

Muchas gracias por tu ayuda y conocimiento.

Vanessa Amaya

teacher•

¡Hola Diego! Más que el verbo, te recomiendo lo siguiente: Aclarar lo que se debe permitir y lo que no siendo lo más concreto posibles. Aclarar cómo nos vamos a dar cuenta de que estamos desarrollando la funcionalidad correcta, es decir ¿qué condiciones se van a revisar por el Product Owner, por quien haga las pruebas y por el usuario final? para asegurar la calidad. Si algún criterio de aceptación es demasiado amplio, podemos apuntar a un anexo fuera de la Historia de Usuario, ejemplo: Apegarse al Layout A56. Y en el Layout A56 especificar todos los campos.

Espero esto te ayude, dime si quedó claro con confianza.

Saludos!

DIEGO FERNANDOCASTAÑEDALOAIZA

student•

Mil gracias, Vanessa. Fuiste completamente clara en tu explicación y resolviste mi inquietud. Lo pondré en práctica.

Saludos!

Elkin Toro

student•

Elkin Toro

student•

Jhon Alexander Acevedo Nuñez

student•

Alguien sabe cual es esa herramienta que usa la profesora para explicarnos el contenido?

Vanessa Amaya

teacher•

Hola Jhon! Para el curso usé dos herramientas: MURAL y TRELLO. De hecho en Platzi hay un curso para que aprendas las funcionalidades de Trello a más profundidad.

Jhon Alexander Acevedo Nuñez

student•

Muchas gracias profe 👩‍🏫

Raúl Mamani Cusi

student•

recomiendas algún software para la gestión de historias de usuario en un equipo de desarrollo?

Vanessa Amaya

teacher•

Hola Raúl! Para Historias de usuario y elementos de trabajo, recomiendo el Tablero tipo Kanban, el software que más me ha gustado para eso se llama Click up, en segundo lugar usé muchos años Trello (en Platzi hay un curso para aprender a usarlo) y el que más se usa en corporativos grandes se llama Jira.