User Stories - Certificación extra

El dueño de Producto esta comprometido con el equipo, está dispuesto a aclarar cualquier duda durante el sprint y su discurso es consistente toto el tiempo, es decir, que no hay variabilidad en lo que require. Entonces

• Las historias de usuario se implementan sin importar su tamaño

• Es posible usar solo el títutlo de la historia de usaurio para representarla.

• Las historias de usuario no requieren de pruebas de aceptación ni funcionales.

• No hay refinameinto de las historias de usuario.

Las historia de usuario se pueden usar en escenarios fuera del desarrollo de software

• Si

• No

• Es imposible usarlo en otra rama cientifica.

Cuando se trata de historias de usuarios siempre es necesario usar un formato "como... quiero ... para" y además los criterios de aceptación en prosa y un boceto o bosquejo para representarlas.

• Verdadero.

• Falso.

Una historia de usuario HU #1 es más grande que una historia HU#2. Entonces.

• H2 tiene más valor para el negocio que H1

• Ambas tienen el mismo valor para el negocio.

• H1 tiene más valor para el negocio que H2

• Con solo la información del tamaño, no es posible determinar el valor de cada historia para el negocio.

Que una historia de usuario se puede probar o asegurar su calidad, quiere decir que:

• La calidad de la historia siempre será óptima.

• El equipo en pleno tiene la confianza de que existe un método viable para asegurar que la historia tendrá un comportamiento adecuado para los usuarios

• No es necesario probar la historia.

• Toda las pruebas de la historia se ddeben establecer desde el comienzo de su construccion.

Para implementar una historia de usuario hay que revisar si no tiene independencia con otras historias de usuario. Una forma de encontrar dependencia entre historias es:

• Elaborando un diagrama de relacion de HU

• Documentando todas las HUs al principio del proyecto

• Preguntándole al usuario o Dueño de Producto si existe dependencia entre historias de usaurio

• Buscando superposición de funciones entre dos o más historias. Es decir, características o funcionalidades que se repiten en las historias.

Durante la Conversación alrededor de una historia de usuario se pueden responder preguntas como:

1.- ¿Qué información necesita el usuario proporcionar al sistema para ingresar?

2.- Es obligatoría toda la información o puede ser parcial, es es, hay datos opcionales?

3.- ¿Qué ocurre cuando la información está incorrecta o incompleta?

• Solo 1 y 2 son ciertas.

• Solo 2 y 3 son ciertas.

• Solo 2 es cierta

• Solo 3 es cierta

• Todas son ciertas

Es muy recomendable estimar historias de usuario en horas de esfuerzo

• Verdadero

• Falso, es preferible usar un sistema de puntaje

Si la mayoria de tus historia de usuario llegan a "Terminado" apenas unas pocas horas antes de la Revision, todavía pueden ser más pequeñas

• Verdadero

• Falso

Un equipo que usa solo el título de la historia de usuario para representarla y tiene éxito con ello es un indicativo de:

• Alta madurez en agilidad y SCRUM

• Que todos son Seniors

• El equipo tiene años de conocerce y trabajar juntos

• Niguna, no es posible redactar una historia de usuario como titulo.