NEW
Font size
WorksheetsGESTIÓN DEL PRODUCT BACKLOG
Total questions: 7
Worksheet time: 4mins
A la hora de crear el Product Backlog, ¿cuándo podemos dar por finalizada su definición?
Cuando todas las épicas han sido refinada en historias.
Cuando refleja todos los requerimientos.
Nunca: un producto backlog es un elemento vivo en constante definición.
Ninguna de las anteriores.
¿En qué evento de Scrum ha de realizarse el refinamiento de producto?
En las Daily.
En la Retrospectiva.
Sólo en la Review y excepcionalmente en el planning.
No existe evento específico para esta actividad.
Seguin el modelo Kano
Todas las funcionalidades son igual de importantes para el usuario
Las funcionalidades esperadas por el usuario son prioritarias.
Las funcionalidades no esperadas, pero que pueden sorprender positivamente al usuario son prioritarias.
Las funcionalidades no esperadas, no deben realizarse.
A la hora de priorizar valor, un enfoque adecuado para reducir el time to market sería …
Ley 80/20 > Hay que entregar el 80% del producto en el 20% del tiempo estimado.
Ley 20/80 > Hay que enfocarse en el 20% del producto que cubre las necesitades del 80% de los usuarios.
Ley del 100%> Agile nos ayuda a entregar antes todo el producto gracias al uso de Sprint.
Ley de Bristol-Mayer: El usuario siempre tiene la razón.
¿Por qué deberíamos tener una Definición de hecho (DoD) en nuestros Sprints?
Porque lo exigen las auditorías.
Porque permite tener una visión común de qué significa que algo que esté realmente terminado.
Porque es la forma de obtener una certificación de Scrum a nivel organizativo.
Porque el Product Owner puede coordinar mejor los recursos.
¿Cuáles de los siguientes aspectos pueden incluirse en la definición de hecho?
Pruebas de rendimiento, Pruebas de escalabilidad, Pruebas de seguridad y Calidad de código.
Refactoring y Pruebas de aceptación del usuario.
Documentación requerida por la organización y Pruebas de regresión.
Todas las anteriores.
Cuando un mismo producto ha de ser realizado por varios equipos de desarrollo…
Hay un solo PO, con un solo Product Backlog a partir del cual cada equipo crea sus Sprint Backlogs.
Hay un PO para cada equipo.
Cada equipo tiene su Product Bakclog.
Se establece una estructura matricial basada en el modelo Spotify.
