Estrategias para poder habilitar HUs de manera efectiva

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.

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.

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.

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á

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

Estrategias

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

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

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!!!

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.

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

Estrategias para poder habilitar HUs de manera efectiva

Las historias de usuario como centro, la funcionalidad como centro

4 partes a consideras:

1. Entendimiento del problema: Entender el origen del problema que el cliente está pidiendo
2. Objetivos de negocios.
3. Requerimientos técnicos
4. 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)

que super nivel de pedagogia de este caredratico mis respetos si todo urge es porque no estamos priorizando

El diseño tiene que tener un objeto de ser, para requerimiento técnico.

las historias de usuario deben tener propiedad INVEST, independiente, negociable, valiosa, estimable, Small, testeable

Les comparto mis apuntes sobre Propiedad INVEST:

Independiente: La historia de usuario debe estar lo más simple e independiente de otras en lo posible del caso. Saber diferenciarla y no convertirla en una épica.
Negociable: Se debe tomar en cuenta que no todo lo que se nos ocurre se puede llevar a cabo. Hay historias que se pueden quitar o cambiar de orden y también saber priorizar durante el transcurso de los Spring.
Valiosa: Cuando queda claro y entendido el “para qué”. Hay que justificar lo valiosa que puede ser una historia.
Estimable: El equipo/persona que va a llevar a cabo la tarea debe poder decir cuánto tiempo y esfuerzo le puede llevar, de lo contrario la historia no es estimable y que no está claro o que no está siendo entendida la actividad, se debe dar voz y voto al equipo/persona que va a llevar a cabo la actividad y evitar que una sola persona tome el rol de “juicio experto” y estime los tiempos y esfuerzos sin ser la que directamente la ejecute.
Pequeña: El tamaño de la historia debe ser pequeña, es más importante el entendiendo y conversación antes que la especificación.
Testeable/Comprobable: Cuando los criterios de aceptación existen, para validar si la historia se está haciendo correcta o incorrectamente.

Para que algo sea estimable, el equipo la persona que va a hacer realidad esa funcionalidad, tiene que atreverse a decir, cuanto tiempo y cuanto esfuerzo considera que le va a llevar. Cuando una persona no tiene idea ni de que tan complejo puede ser ni de cuanto tiempo le puede llevar, es que no es estimable esa historia y lo que nos está diciendo es que le falta claridad, le falta reforzar entendimiento y tenemos que rebotar estas ideas con la persona que lo va a ejecutar.

Toda historia debe ser valiosa, toda historia debe contar con un para que.

Para que algo sea estimable, el equipo o la persona que va a hacer realidad esa funcionalidad, tiene que atreverse a decir cuánto tiempo y cuánto esfuerzo considera que va a gastar.

las historias de usuario deben ser el centro del contexto conformado por el entendimiento del problema a partir del origen de esa solucion solicitada por el cliente, cual es la oportunidad de mejora o innovacion en el mercado que se quiere aprovechar. Despues de entender y comprender el problema se estabecen los objetivos del negocio hay que conocerlos para asi trabajar en conjunto por su logro, independiente de nuestro rol dentro del equipo scrum y no ser un retroceso por su desconocimiento o falta de calidad en su realizacion. Los requerimientos técnicos es nuestro aporte con el conocimientos de los diferentes lengjuajes y frameworks. Por ultimo el tiempo de transicion entre el teimpo en el que el producto esta creado al producto esta entregado, segun el analisis de negocio se requieren unoc conocimientos de transicion. (actividades administrativas y tecnicas (cambios de ambientes o SO) ).

La meta es llegar a construir Historias de Usuario Independientes, Negociables, Con valor, estimables es decir que halla conocimiento tecnico y cientifico de los tiempos de ejecucion y pasos de realizacion, pequeñas y testiables o comprobables.

Independiente: que no dependa una HU de otra, que no sea en cascada (terminar 1 para empezar 2)
Negociable: en la conversación definir qué tendrá y qué no
Valiosa: que una HU no dependa de otra para generar valor
Estimable: identificar dificualtades y esfuerzos para definir bien el Sprint
Small: Debe ser pequeña, es decir que el esfuerzo no sea demasiado, lo ideal es que sea lo más pequeña posible.
Testeable: que se pueda decir cuando la UH está lista y verificarlo; que se puedan hacer pruebas y entregas de prototipos para dar lugar a modificaciones y mejora continua.

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.

Propiedades INVEST para una HU