1.

Un proyecto Scrum consiste en un esfuerzo de colaboración para crear un nuevo

producto, servicio u otro resultado tal como se define en la Declaración de la visión del
proyecto (Project Vision Statement). Los proyectos se ven afectados por limitaciones
de tiempo, costos, alcance, calidad, recursos, capacidades organizacionales y demás
limitaciones que dificultan su planificación, ejecución, administración y, por último, su
éxito. | Referencia: Guía SBOK, p. 2.

2. Los procesos de Scrum abordan las actividades específicas y el flujo de un proyecto

de Scrum. Hay en total 19 procesos agrupados en cinco fases.
Las fases se presentan en los capítulos del 8 al 12 de la Guía SBOK, tal como se
muestra en la Tabla 1-1. | Referencia: Guía SBOK, Tabla 1-1, p. 16.

3. Los proyectos de Scrum se hacen en forma iterativa entregando valor a lo largo del
ciclo de vida del proyecto. | Referencia: Guía SBOK, figura 2-9, p. 40.

4. El ciclo de Scrum empieza con una reunión de stakeholders, durante la cual se crea la
visión del proyecto. Después, el Product Owner desarrolla una Backlog Priorizado del
Producto que contiene una lista requerimientos del negocio y del proyecto por orden
de importancia en forma de una historia de usuario.

5. Al Equipo Scrum en ocasiones se le conoce como equipo de desarrollo, ya que este es

responsable del desarrollo del producto, servicio o de cualquier otro resultado.
Consiste en un grupo de personas que trabajan en las historias de usuario en el Sprint
Backlog para crear los entregables del proyecto. Referencia: Guía SBOK, Tabla 3-3,
pp. 54-55.

6. Los aspectos de Scrum deben ser abordados y administrados a lo largo de un

proyecto de Scrum. Los cinco aspectos son: Organización, Justificación del negocio,
Calidad, Riesgo y Cambio.

7. Los principios de Scrum son las pautas principales para la aplicación del framework de
Scrum y deben ser utilizadas obligatoriamente en todos los proyectos de Scrum. Los
seis principios son: 1) Control del proceso empírico; 2) Auto-organización; 3)
Colaboración; 4) Priorización basada en valor; 5) Time-boxing; 6) Desarrollo iterativo.

8. Scrum sostiene que los empleados cuentan con motivación propia y que buscan
aceptar mayores responsabilidades. Por tanto, ofrecen mucho más valor cuando se
organizan por cuenta propia.

9. La Reunión de retrospectiva del sprint tiene un time-box de cuatro horas en un sprint

de un mes, y se lleva a cabo como parte del proceso Retrospectiva del sprint. Durante
esta reunión, el Equipo Scrum se reúne para revisar y reflexionar sobre el sprint
anterior en relación a los procesos que se siguieron, las herramientas empleadas, la
colaboración y los mecanismos de comunicación, así como otros aspectos de interés
para el proyecto. El equipo discute lo que salió bien durante el sprint anterior y lo que
no salió bien, con el objetivo de aprender y mejorar sprints futuros. Algunas
oportunidades de mejora o las mejores prácticas de esta reunión también podrían
actualizarse como parte de los documentos del Scrum Guidance Body.
10. Mantener un ritmo sostenible es uno de los principios más importantes de Scrum. El
ritmo sostenible se traduce en una mayor satisfacción del empleado, en estabilidad y
una mayor precisión en la estimación; todo ello conlleva, en última instancia, a un
aumento en la satisfacción del cliente. Para desarrollar un producto verdaderamente
de alta calidad y conservar un sano ambiente laboral, es importante realizar
periódicamente actividades de integración, en vez de retrasar el trabajo de integración
hasta el final en tales circunstancias.

11. El framework de Scrum se basa en la creencia de que el conocimiento de los

trabajadores de hoy en día puede ofrecer mucho más que solo su experiencia técnica,
y en que tratar de asignar y planear en un ambiente de constante cambio no es
eficiente. Por lo tanto, Scrum alienta a la toma de decisiones iterativa basada en datos.
En Scrum, el enfoque principal es la entrega de productos que satisfagan los requisitos
del cliente en pequeños incrementos iterativos que sean entregables. Para entregar la
mayor cantidad de valor en el menor tiempo posible, Scrum promueve la priorización y
el Time-boxing en vez de la fijación del alcance, del costo y del cronograma de un
proyecto. Una característica importante de Scrum es la auto-organización, lo cual
permite a las personas que hacen el trabajo estimar y asumir la propiedad de las
tareas.

12. El framework de Scrum se guía por la finalidad de ofrecer el máximo valor empresarial
en un mínimo período de tiempo. Una de las herramientas más eficaces para entregar
el mayor valor en el menor tiempo posible es la priorización. La priorización se puede
definir como la determinación del orden y la separación de lo que debe hacerse ahora,
de lo que debe hacerse después. El concepto de priorización no es nuevo para la
gestión de proyectos. El modelo tradicional de gestión de proyectos llamado Cascada
o Waterfall propone el uso de múltiples herramientas de priorización. Desde el punto
de vista del Project Manager, la priorización es integral debido a que ciertas tareas
deben llevarse a cabo primero a fin de acelerar el proceso de desarrollo y el
cumplimiento de los objetivos del proyecto. Algunas de las técnicas tradicionales de la
priorización de tareas incluyen el establecimiento de plazos para las tareas delegadas
y el uso de matrices de priorización

13. Un Proyecto es una empresa de colaboración para crear nuevos productos o servicios,
o para obtener resultados definidos en Declaración de la visión del proyecto. Los
proyectos son por lo general afectados por limitaciones de tiempo, costo, alcance,
calidad, la gente y la capacidad de la organización.

14. ¿Qué es la Auto-organización? Es el énfasis en el logro de resultados enfocándose

en las necesidades del Equipo Scrum. Scrum sostiene que los empleados cuentan con
motivación propia y que buscan aceptar mayores responsabilidades. Por tanto, ofrecen
mucho más valor cuando se organizan por cuenta propia.

15. ¿Qué es el Priorización basada en valor? Scrum utiliza la priorización basada en

valor (Value-based Prioritization) como uno de los principios básicos que impulsa la
estructura y funcionalidad de todo el framework de Scrum—ayuda a que los proyectos
se beneficien mediante la capacidad de adaptación y el desarrollo iterativo del
producto o servicio. Y lo que es más importante, Scrum tiene como finalidad entregar
un producto o servicio valioso para el cliente en forma oportuna y continua.
16. ¿Qué es el Time-boxing? Scrum trata al tiempo como uno de los limitantes más
importantes en la gestión de un proyecto. Para hacer frente a la restricción del tiempo,
Scrum introduce un concepto de Time-boxing (o asignación de un bloque de tiempo),
que propone la fijación de una cierta cantidad de tiempo para cada proceso y actividad
en un proyecto Scrum. Esto garantiza que los miembros del Equipo Scrum no ocupen
demasiado o muy poco tiempo para un trabajo determinado, y que no desperdicien su
tiempo y energía en un trabajo para el cual tienen poca claridad.

17. ¿Qué es el Desarrollo iterativo? Es el uso de uno o más ciclos de desarrollo de

productos para desarrollar los entregables mediante el aprendizaje de ciclos de
desarrollo anteriores.

18. ¿Cómo se define mejor el concepto de colaboración? Los miembros del Equipo
Principal de Scrum trabajan juntos e interactúan con los stakeholders para crear y
validar los entregables del proyecto para cumplir la meta establecida.

19. ¿Cuál de las siguientes opciones se enfatiza en el framework de Scrum? La

automotivación y la responsabilidad del equipo.

20. La reunión de retrospectiva del proyecto es una reunión para determinar las formas en
las que la colaboración y eficacia del equipo puede mejorarse en futuros proyectos.
También se analizan las oportunidades positivas, negativas y potenciales para
mejorar. Esta reunión no tiene un time-box asignado y se puede llevar a cabo en forma
presencial o en formato virtual.

21. ¿Cuál de las siguientes opciones no ayuda a garantizar la transparencia en un

proyecto de Scrum? Scrum asegura la transparencia mediante una planificación
detallada por adelantado donde participan todos los principales stakeholders.

La transparencia permite que todas las facetas de cualquier proceso de Scrum sean
observadas por cualquiera. Esto promueve un flujo de información fácil y transparente
en toda la organización y crea una cultura de trabajo abierta. En Scrum, la
transparencia se representa mediante lo siguiente: • Una declaración de la visión del
proyecto (Project Vision Statement) que pueden ver todos los stakeholders y el Equipo
Scrum. • Un Backlog Priorizado del Producto abierto con historias de usuario
priorizadas que todos pueden ver tanto dentro como fuera del Equipo Scrum. Un
cronograma de planificación del lanzamiento (Release Planning Schedule) que se
puede coordinar a través de múltiples equipos Scrum. • Una clara visibilidad sobre el
progreso del equipo a través del uso de Scrumboard, Burndown Chart y otros
radiadores de información. • Daily Standups que se llevan a cabo durante el proceso
de Realizar Daily Standup en las que todos los miembros del equipo informan sobre lo
que hicieron el día anterior, lo que van a hacer hoy y cualquier problema que les
impida completar sus tareas en el sprint actual. • Las reuniones de revisión del sprint
se llevan a cabo durante el proceso de Demostrar y validar el sprint, donde el Equipo
Scrum muestra los entregables del sprint que potencialmente se pueden enviar a los
Product Owners y a los stakeholders.
 22. Las cuatro etapas del modelo son las siguientes: 1. Formación (Forming)—Esto a
menudo se experimenta como un escenario ameno, ya que todo es nuevo y el equipo
aún no ha encontrado ninguna dificultad con el proyecto. 2. Enfrentamiento (Storming)
—Durante esta etapa, el equipo trata de cumplir con el trabajo; sin embargo, puede
encontrar conflictos de poder y, con frecuencia, existe un caos o confusión entre los
miembros del equipo. 3. Normalización (Norming)—Esto es cuando el equipo empieza
a madurar, resolver sus diferencias internas, y encontrar soluciones para así trabajar
juntos. Se considera un período de ajuste. 4. Desempeño (Performing)—Durante esta
etapa, el equipo está unido y opera en su nivel más alto en términos de rendimiento.
Los miembros se han convertido en un equipo eficiente de profesionales que son
consistentemente productivos.

23. Las dimensiones básicas de trabajo en la colaboración son las siguientes:

Conocimiento, Articulación y Apropiación.

24. En Scrum, las decisiones se basan en la observación y la experimentación en vez de

la planificación inicial detallada. El control del proceso empírico se basa en las tres
ideas principales de la transparencia, inspección y adaptación

25.

Término Concepto

1. Adaptación Adaptación sucede cuando el Equipo Principal de scrum (Scrum Team Central) y
el/los stakeholder (s)aprende(n) a través de la transparencia e inspectiony luego
se adaptan a lo aprendido para mejorar el trabajo.

2. Auto-organización Scrum cree que los empleados son auto-motivados y desean una mayor
responsabilidad. Por lo tanto, los empleados ofrecen mucho más valor cuando
se organizan por cuenta propia.

3. Boxeo Tiempo Bloque de Tiempo se refiere al ajuste de periodos cortos de tiempo para el
trabajo por hacer.Si el trabajo realizado está incompleto al final del Bloque de
Tiempo, se mueve al Bloque de Tiempo posterior. Bloque de Tiempo
proporciona la estructura necesaria para los proyectos Scrum que tienen un
elemento de incertidumbre, que son dinámicos por naturaleza y son propensos
a cambios frecuentes.

4. Colaboración Colaboración en se refiere al trabajo e interconexión entre el scrum core team

de y los stakeholder para crear y validar los resultados del proyecto y cumplir
con los objetivos planteados en el Proyecto Visión . Colaboración se produce
cuando los equipos trabajan en conjunto para aprender de los demás y
aprovechar este conocimiendo para luego producir algo más grande.

5. Control del Proceso Elmodelo Control del Proceso Empírico ayuda a tomar decisiones basadas en la
Empírico observación y la experimentación, más que en la planificación inicial
detallada.Se basa en las tres ideas principales de transparencia, inspección y
adaptación.

6. Entrega Iterativa Entrega Iterativa es la entrega gradual de valor al cliente

7. Inspección Inspección se refiere a la vigilancia necesaria para seguir control de proceso
empírico, para asegurar que los producto s entregables del proyecto se ajusten
a los requisitos.

8. Prioritización Prioritización se puede definir como la determinación del orden de las cosas y
separar lo que se hará ahora, de lo que se puede hacer más tarde.

9. Transparencia La transparencia permite que todas las facetas de cualquier proceso de Scrum
puedan ser observadas por cualquier persona. Compartir toda la información
conduce a un entorno de alta confianza.

26. El Product Owner representa los intereses de la comunidad de stakeholders para el

Equipo Scrum. El Product Owner es responsable de asegurar una comunicación clara
sobre el producto y los requisitos de funcionalidad del servicio con el Equipo Scrum,
definir los criterios de aceptación y asegurar que se cumplan dichos criterios. En otras
palabras, el Product Owner es responsable de asegurar que el Equipo Scrum entregue
valor.

27. Hay tres roles centrales en Scrum que son responsables en última instancia de cumplir
con los objetivos del proyecto. Los roles centrales son el Product Owner, Scrum
Master y Equipo Scrum.

28. Los roles no centrales son aquellos roles que no son obligatoriamente necesarios
para el proyecto Scrum y pueden no participar en el proceso de Scrum. Sin embargo,
es importante tener conocimiento sobre estos roles no centrales, ya que podrían
desempeñar un rol importante en algunos proyectos de Scrum. Los roles no
centrales pueden incluir a stakeholders (clientes,patrocinadores y usuarios),
vendedores y el Scrum Guidance Body.

29. Stakeholder(s) es un término colectivo que incluye a clientes, usuarios y

patrocinadores, que generalmente interactúan con el Product Owner, el Scrum Master
y el Equipo Scrum para proporcionarles las entradas y facilitar la creación del producto
del proyecto, servicio, o cualquier otro resultado. Los stakeholders influyen en el
proyecto a lo largo del desarrollo del mismo. Los stakeholders también pueden
desempeñar un rol en los procesos importantes de Scrum tales como Desarrollar
épica(s), Crear Backlog Priorizado del Producto, Realizar la planificación del
lanzamiento y Retrospectiva del sprint.

30. El Product Owner es la persona responsable de maximizar el valor del negocio para el
proyecto. Este rol es responsable de articular los requisitos del cliente y de mantener
la justificación del negocio del proyecto. El Product Owner representa la voz del
cliente.
31. El patrocinador es la persona o la organización que provee recursos y apoyo para el
proyecto. El patrocinador es también el stakeholder a quien todos le deben rendir
cuentas al final.

32. En los grandes proyectos con varios equipos Scrum puede ser necesario tener un
Chief Product Owner. Este rol es responsable de coordinar el trabajo de múltiples
Product Owners. Con la ayuda de los Product Owners, el Chief Product Owner prepara
y mantiene el Backlog Priorizado del Producto en general para el proyecto grande
utilizándolo para coordinar el trabajo a través de los Product Owners de los equipos
Scrum. Los Product Owners, a su vez, gestionar sus partes respectivas del Backlog
Priorizado del Producto.

33. Una reunión de Scrum de Scrums es un elemento importante en el escalamiento de

Scrum para grandes proyectos. En la reunión típicamente hay un representante de
cada Equipo Scrum, por lo general el Scrum Master, aunque también es común que
cualquiera en el Equipo Scrum asista a la reunión en caso de ser necesario. Esta
reunión generalmente la organiza el Chief Scrum Master y la intención es enfocarse en
áreas de coordinación e integración entre los distintos equipos Scrum. Esta reunión se
lleva a cabo en intervalos predeterminados o cuando lo requieran los equipos Scrum.

34. En el proceso Crear entregables, el Equipo Scrum trabaja en las tareas en el Sprint
Backlog para crear los entregables del sprint. Generalmente se utiliza un Scrumboard
para dar seguimiento a las actividades que se llevan a cabo. Las asuntos o problemas
que enfrenta el equipo Scrum pudieran actualizar se en un Impediment Log (o registro
de impedimentos).

35. ¿Cuál es una característica deseable en un Scrum Master? Capacidad para

facilitar la selección del Equipo Scrum, Capacidad para crear el Cronograma de
planificación del lanzamiento, Capacidad para facilitar la creación del Plan de
colaboración.

36. ¿Cuál es una característica deseable en un miembro del Equipo Scrum?

 Capacidad para entender épicas y prototipos (Personas)
 Capacidad para estimar historias de usuario
 Capacidad para identificar riesgos e implementar acciones para mitigar riesgos

37. ¿Cuál es una característica deseable en un Product Owner?

 Capacidad para desarrollar un plan de colaboración
 Capacidad para crear un plan de desarrollo del equipo
 Capacidad para crear el Cronograma de planificación del lanzamiento
 Todas las anteriores

38. Un portafolio es un grupo de programas relacionados con la finalidad de entregar

resultados de negocio como se define en la declaración de la visión del portafolio
(Portfolio Vision Statement). El Backlog Priorizado del Portafolio incorpora el Backlog
Priorizado del Producto de todos los programas en el portafolio.
39. En los grandes proyectos con varios equipos Scrum puede ser necesario tener un
Chief Product Owner. Este rol es responsable de coordinar el trabajo de múltiples
Product Owners. Con la ayuda de los Product Owners, el Chief Product Owner prepara
y mantiene el Backlog Priorizado del Producto en general para el proyecto grande
 utilizándolo para coordinar el trabajo a través de los Product Owners de los equipos
Scrum. Los Product Owners, a su vez, gestionar sus partes respectivas del Backlog
Priorizado del Producto. El Chief Scrum Master también interactúa con el Program
Scrum Master a fin de garantizar la alineación de un proyecto grande con las metas y
objetivos del programa.

40. A fin de ofrecer una entrega basada en valor, es importante disminuir la incertidumbre
y atender constantemente de los riesgos que potencialmente pudieran reducir el valor
en caso de materializarse. También es importante trabajar en estrecha colaboración
con los stakeholders del proyecto mostrándoles incrementos del producto al final de
cada sprint, lo cual permite una gestión efectiva de cambios.

41. Antes de iniciar un proyecto, primero se evalúa la justificación del negocio y se verifica
constantemente durante todo el ciclo de vida del mismo. Los siguientes pasos captan
la forma en la que se determina la justificación del negocio: Evaluar y presentar un
caso de negocio; Justificación continua de valor; Confirmar la realización de
beneficios.

42. Una vez que los tomadores de decisiones aprueban la declaración de la visión del
proyecto, esta se utiliza como base de referencia y forma la justificación del negocio.
La justificación del negocio se valida durante toda la ejecución del proyecto, por lo
general en intervalos predefinidos, como en reuniones del portafolio, del programa o
del Backlog Priorizado del Producto y cuando se identifican los principales problemas y
riesgos que amenazan la viabilidad del proyecto. Esto puede darse en varios procesos
de Scrum, incluyendo el proceso de Realizar Daily Standup y en el Refinar el Backlog
Priorizado del Producto. A lo largo del proyecto, el Product Owner debe mantener
actualizada la justificación del negocio en la declaración de la visión del proyecto con
información relevante del proyecto para que los que toman decisiones importantes
continúen tomando decisiones informadas.

43. A lo largo del proyecto, el Product Owner debe mantener actualizada la justificación
del negocio en la declaración de la visión del proyecto con información relevante del
proyecto para que los que toman decisiones importantes continúen tomando
decisiones informadas.

44. Existen numerosos factores que un Product Owner debe tomar en cuenta para
determinar la justificación del negocio de un proyecto. Los siguientes son algunos de
los factores más importantes: Razonamiento del proyecto; Necesidades del negocio;
Beneficios del proyecto; Costo de oportunidad; Riesgos mayores; Escalas de tiempo
del proyecto (Project Timescales); Costos del proyecto.

45. La responsabilidad de determinar cómo se crea valor recae en los stakeholders

(patrocinadores, clientes y/o usuarios), mientras que el Equipo Scrum se concentra en
lo que se habrá de desarrollar. Algunas de las herramientas comunes recomendadas
por un Scrum Guidance Body pudieran ser las siguientes: Mapa de flujo de valor
(Value Stream Mapping) y Priorización basada en el valor para el cliente (Customer
Value-based Prioritization).
46. ¿Cuál es una de las responsabilidades de un Scrum Master con relación a la
justificación del negocio de un proyecto?
1. Facilita la creación de los entregables del proyecto
 Se coordina con el Equipo Scrum para crear entregables
 Gestionar riesgos, cambios e impedimentos durante el proceso de Realizar el Daily
Standup
 Todas las anteriores
47. El diagrama de flujo acumulativo (DFA) es una herramienta útil para la elaboración de
informes y para el seguimiento de los resultados del proyecto. Proporciona una
representación sencilla y visual del avance del proyecto en un punto de tiempo
determinado. Se utiliza generalmente para brindar un estado de mayor nivel de la
totalidad del proyecto y no para actualizaciones individuales diarias de sprints
48. Durante todo un proyecto, es importante verificar si se están logrando los beneficios.
Ya sea si los productos de un proyecto Scrum son tangibles o intangibles, se requieren
técnicas adecuadas de verificación para confirmar que el equipo esté creando los
entregables que lograrán los beneficios y el valor definido al inicio del proyecto.
49. El valor que habrán de brindar los proyectos empresariales puede calcularse utilizando
diversos métodos, tales como el retorno sobre la inversión (RSI), valor presente neto
(VPN) y la tasa interna de retorno (TIR).
50. El retorno sobre la inversión (RSI), al utilizarse para la justificación de un proyecto,
evalúa los ingresos netos esperados que se buscan obtener a partir de un proyecto.
Se calcula deduciendo los costos esperados o la inversión en un proyecto de su
ingreso previsto; después se divide (la utilidad neta) por los costos previstos a fin de
obtener la tasa de retorno.

51. El mapeo de historias (Story Mapping), es una técnica para proporcionar un esquema
visual del producto y sus componentes clave. El mapeo de historias, formulado por
primera vez por Jeff Patton (2005), se utiliza comúnmente para ilustrar la ruta del
producto. Los mapas de historia representan la secuencia de las iteraciones de
desarrollo del producto y trazan las características que serán incluidas en el primer,
segundo, tercero y subsecuentes lanzamientos.

52. El Backlog Priorizado del Producto es un solo documento de requisitos que define el
alcance del proyecto, proporcionando una lista de prioridades de las características del
producto o servicio a ser entregado por el proyecto. Las características necesarias se
describen en forma de historias de usuario. Dichas historias son requisitos específicos
señalados por varios stakeholders que se relacionan con el producto o servicio
propuesto. Cada historia de usuario contará con sus criterios de aceptación de historia
de usuario (también conocidos como “criterios de aceptación”), que son los
componentes objetivos mediante los cuales se juzga la funcionalidad de una historia
de usuario.

53. Los criterios de aceptación deben delinear explícitamente las condiciones que deben
satisfacer las historias de usuario. Los criterios de aceptación claramente definidos son
de suma importancia para la entrega eficaz y oportuna de la funcionalidad definida en
las historias de usuario, lo cual, en última instancia, determinan el éxito del proyecto.
Al final de cada sprint, el Product Owner utiliza estos criterios para verificar los
entregables completados y puede aceptar o rechazar entregables individuales, así
como sus respectivas historias de usuario. Si los entregables son aceptados por el
Product Owner, la historia de usuario se considera entontes como terminada.
54. Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un
enfoque de mejora continua donde el equipo aprende de sus experiencias y de la
participación de los stakeholders para mantener constantemente actualizado el
Backlog Priorizado del Producto con cualquier cambio en los requerimientos. Dicha
lista nunca está completa hasta el cierre o conclusión del proyecto. Cualquier cambio
en los requisitos refleja los cambios en el entorno empresarial interno y externo y
permite que el equipo funcione continuamente y se adapte para alcanzar esos
requisitos. Scrum requiere que el trabajo se realice en incrementos durante los sprints,
lo cual significa que los errores o defectos se detectan durante las pruebas de calidad
repetitivas y no cuando el producto final o servicio está casi terminado.

55. ¿Qué es una historia de usuario? Las historias de usuario son requerimientos
específicos establecidos por varios stakeholders y están relacionadas al servicio o
producto propuesto.

56. Es importante que el Product Owner tome nota que las historias de usuario que
cumplan con la mayoría, aunque no con todos los criterios de aceptación, no pueden
aceptarse como terminadas. Los proyectos Scrum operan en sprints con un time-box
asignado, con Sprint Backlog asignado para cada sprint. Generalmente, la última parte
del trabajo pudiera ser la parte más complicada de la historia de usuario y pudiera
tardar más de lo esperado. Si se les dio crédito a historias de usuario incompletas
como si estuvieran terminadas —y si se llevaron al siguiente sprint—, el progreso de
posteriores sprints pudiera verse interrumpido. Por lo tanto, el estado de “terminado”
es a blanco y negro. Una historia de usuario puede ser, ya sea “terminada” o “no
terminada”.

57. Cada historia de usuario contará con sus criterios de aceptación de historia de usuario
(también conocidos como “criterios de aceptación”), que son los componentes
objetivos mediante los cuales se juzga la funcionalidad de una historia de usuario. Los
criterios de aceptación los desarrolla el Product Owner según su experiencia en los
requerimientos del cliente. El Product Owner después comunica las historias de
usuario que están en el Backlog Priorizado del Producto a los miembros del Equipo
Scrum, buscando un común acuerdo. Los criterios de aceptación deben delinear
explícitamente las condiciones que deben satisfacer las historias de usuario. Los
criterios de aceptación claramente definidos son de suma importancia para la entrega
eficaz y oportuna de la funcionalidad definida en las historias de usuario, lo cual, en
última instancia, determinan el éxito del proyecto.

58. ¿Qué son los criterios de aceptación? Los criterios de aceptación son
desarrollados por el Product Owner según su experiencia para entender los
requerimientos del cliente.

59. ¿Cuál es la diferencia entre los criterios de aceptación y los criterios de

terminado? Los criterios de aceptación son únicos en historias de usuario
individuales, mientras que los criterios de terminado son un conjunto de reglas que
aplican a todas las historias de usuario en un determinado sprint. Hay una diferencia
clave entre "criterios de terminado" y "criterios de aceptación". Mientras que los
criterios de aceptación son únicos para historias de usuario individuales, los criterios
 de terminado son una serie de reglas que aplican a todas las historias de usuario en
un determinado sprint.

60. ¿Qué define mejor los criterios de terminado? La conclusión de las pruebas de
garantía de calidad y la conclusión de toda la documentación relacionada a las
historias de usuario. Las pruebas unitarias completadas de la historia de usuario y la
demostración satisfactoria a los stakeholders y representantes del negocio. Al igual
que con los criterios de aceptación, se deben cumplir todas las condiciones de los
criterios de terminado para que la historia de usuario se considere terminada. El
Equipo Scrum debe utilizar una checklist (o lista de verificación) de los criterios de
terminado generales para garantizar que una tarea está terminada y de que el
resultado cumpla con la con la definición de terminado (DoD, por sus siglas en inglés).
Es importante contar con una clara definición de terminado, ya que ayuda a eliminar la
ambigüedad y permite al equipo apegarse a las normas de calidad requeridas. La
definición de terminado típicamente la determina y la documenta el Scrum Guidance
Body.

61. En Scrum, la gestión de calidad se facilita mediante tres actividades interrelacionadas:

1. Planificación de calidad 2. Control de calidad 3. Garantía de calidad

62. ¿Bajo cuál de las siguientes circunstancias se considera terminada una historia
de usuario? Si los entregables son aceptados por los Product Owners. Se deben
cumplir todas las condiciones de los criterios de terminado para que la historia de
usuario se considere terminada.

63. Un beneficio clave de la planificación de calidad es la reducción de la deuda técnica.

La deuda técnica, conocida también como deuda de diseño o deuda de código, es el
trabajo al que los equipos dan menor prioridad; el trabajo que omiten o que no
terminan a medida que trabajan en la creación de los principales entregables
asociados al producto del proyecto. La deuda técnica se acumula y se debe saldar a
futuro.

64. El Backlog Priorizado del Producto es un solo documento de requisitos que define el
alcance del proyecto, proporcionando una lista de prioridades de las características del
producto o servicio a ser entregado por el proyecto. Las características necesarias se
describen en forma de historias de usuario. Al final de cada sprint, el Product Owner
utiliza estos criterios para verificar los entregables completados y puede aceptar o
rechazar entregables individuales, así como sus respectivas historias de usuario. Las
historias de usuario que corresponden a los entregables rechazados se agregan de
nuevo al Backlog Priorizado del Producto durante el proceso de dar mantenimiento a
dicha lista para que puedan ser completados en futuros sprints.

65. ¿Qué rol define la gama de herramientas que puede utilizar el Equipo Scrum
para desarrollar y verificar el producto? Scrum Guidance Body
Revise importantes Términos y conceptos de este área de conocimiento

Concepto

1. Alcance El Alcance de un proyecto ecto es la suma total de todos los

incrementos de los productos y el trabajo necesario para desarrollar
el producto final.

2. Calidad Calidad se define como la capacidad del producto terminado o

Entregables para cumplir los Criterios de Aceptación y alcanzar el
valor de negocio que espera el cliente.

3. Ciclo Planificar-Hacer-Verificar-Actuar Ciclo —tambiénconocido como el

PDCA/PDSA Deming o Shewhart Cycle—fue desarrollado por el Dr. W. Edwards
Deming, considerado el padre de Control de Calidad moderno,y el Dr.
Walter A. Shewhart. Deming luego modificó Planificar-Hacer-Verificar-
Actuar a Planificar-Hacer-Estudiar-Actuar (PDSA)porque sentía que el
término "estudio", enfatiza el análisis en, lugar de enfatizarla idea
desInspection, como lo implica el término " Verificar ". Tanto y el Ciclo
Deming/Shewhart/PDCA son métodos iterativos que se centran en
imrpovement continua.

4. Control de Control de Calidad se refiere a la ejecución de las actividades de

Calidad calidad previstas por el Scrum Team en el proceso de creación de
Entregables que potencialmente se pueden mandar.También incluye
el aprendizaje de cada conjunto de actividades realizado con el fin de
lograr un mejora continua.

5. Control de Control de Calidad se refiere a la ejecución de las actividades de

Calidad calidad previstas por el Scrum Team en el proceso de creación de
Entregables que potencialmente se pueden mandar.También incluye
el aprendizaje de cada conjunto de actividades realizado con el fin de
lograr un mejora continua.

6. Criterio de Criterio de Terminado es un conjunto de reglas que se aplican a todos

Terminado los Historias de los usuarios.Una definición clara deDonees crítica, ya
que elimina la ambigüedad de los requisitos y ayuda a que el equipo
se adhiera a las normas de calidad obligatorias.Esta clara definición
se utiliza para crear losDone criteria,que son un resultado
delprocesode Crear Priorizada Product Backlogo.Un Historia de
usuario se considera hecho cuando es aprobadado por el Product
Owner oquien lo juzga basado en el Criterio de Terminado y los
Historia de usuario Criterios de aceptación

7. Deuda Técnica Deuda Técnica (también conocido como deuda de diseño o deuda de
código) se refiere al trabajo que los equipos dan prioridad más baja,
omiten o no se completan a medida que trabajan en la creación de los
entregables principales asociados con el producto del proyecto.
Técnica Deuda acumula y debe ser pagado en el futuro.

8. Garantía de Garantía de Calidad se refiere a la evaluación de los procesos y

Calidad normas que rigen gestión de la calidad en un proyecto para
asegurarse de que siguen siendo relevantes. Las actividades de
Garantía de Calidad llevan a cabo como parte del trabajo.

9. Gestión de "Gestión de Calidad en Scrum le permite a los cliente stomar

Calidad conciencia de los problemas en el proyecto desde el principio y les
ayuda a reconocer si un proyecto va a funcionar para ellos o no.
Gestión de Calidad en Scrum se facilita a través de tres actividades
interrelacionadas: 1. Planificación de Calidad 2. Control de Calidad 3.
Garantía de Calidad "

10. Los Criterios Los Criterios Mínimos de Aceptación son declarados por la unidad de
Mínimos de negocio. Luego se convierten en parte de los Criterios de aceptación
Aceptación para cualquier Historia de usuario para esa unidad de
negocio.Cualquier funcionalidad definida por la unidad de negocio
debe satisfacer estos Criterios mínimos de aceptación,si ha de ser
aceptada por el respectivo Product Owner.

11. Planificación de Planificación de Calidad se refiere a la identificación y definición del

Calidad producto que se requiere de un Sprinty del proyecto al igual que los
Criterios de Aceptación, cualquier método de desarrollo que se deba
seguir y las responsabilidades principales de los miembros del Scrum
Team en lo que respecta a la calidad.

12. Priorizada Priorización de la Lista del Producto un documento de requisitos

Backlog Producto individuales que define el alcance del proyecto, proporcionando una
lista de prioridades de las características del producto o servicio a ser
entregado por el proyecto.

13. Producto El término "producto" (proyecto) en la Guía SBOK™puede referirse a

un producto, servicio, o cualquier otra prestación que le proporciona
valor al cliente.

14. Ritmo Ritmo Sostenible es el ritmo en el que el equipo puede trabajar

Sostenible cómodamente.Esto se traduce en una mayor satisfacción de los
empleados, la estabilidad y aumento de la precisión de la estimación,
todo lo cual en última instancia conduce a una mayorsatisfacción del
cliente.

Término Concepto

1. Solicitud de Las solicitudes de cambio se presentan por lo general como Solicitud de

Cambio Cambio. Solicitud de Cambio se consideran que no están aprobados,
hasta que estén formalmente aprobados.
2. Solicitud de Las solicitudes de cambio se presentan por lo general como Solicitud de
Cambio no Cambio. Los Solicitud de Cambio permanecen sin ser aprobados hasta
Aprobada que pueden obtener la aprobación formal.

3. Solicitudes de "Solicitudes de Cambio Aprobados son los cambios que han sido
Cambio aprobados para su inclusión en el Priorizada Product Backlog.A veces,
Aprobados Solicitudes de Cambio Aprobados pueden originar de los gerentes del
programa cartera y seríanentradas que se añadirán a la lista de cambios
de proyecto aprobados para su ejecución en futuros sprint"

66. Las solicitudes de cambio para el proyecto se discuten y aprueban durante los
siguientes procesos: Desarrollar épica(s), Crear el Backlog Priorizado del Producto y
Refinar el Backlog Priorizado del Producto. Posteriormente, las solicitudes de cambio
aprobadas se priorizan junto con otros requisitos del producto y sus respectivas
historias de usuario y se incorporan después en el Backlog Priorizado del Producto.

67. Las solicitudes para hacer cambios se presentan por lo general como solicitudes de
cambio o Change Requests. Las solicitudes de cambio permanecen como no
aprobadas hasta que se obtiene una aprobación formal. El Scrum Guidance Body por
lo general define el proceso de decisión y gestión de cambios en la organización. En
ausencia de un proceso formal, se recomienda que los pequeños cambios que no
tienen un impacto significativo en el proyecto se aprueben directamente por el Product
Owner. La tolerancia de estos pequeños cambios podría definirse a nivel
organizacional o por el patrocinador de un proyecto en particular. En la mayoría de los
proyectos, el 90 % de las solicitudes de cambio podrían clasificarse como pequeños
cambios que deben aprobarse por el Product Owner. Por lo tanto, el Product Owner
juega un papel muy importante en la gestión de los cambios en un proyecto Scrum.
Los cambios que están más allá del nivel de tolerancia del Product Owner pueden
necesitar de la aprobación de los stakeholders que trabajan con él. Las solicitudes de
cambio para el proyecto se discuten y aprueban durante los siguientes procesos:
Desarrollar épica(s), Crear el Backlog Priorizado del Producto y Refinar el Backlog
Priorizado del Producto.

68. Si los requisitos del proyecto son generalmente estables, normalmente hay pequeños
cambios realizados en el Backlog Priorizado del Producto en todo el desarrollo, y los
equipos Scrum pueden trabajar secuencialmente en completar los requisitos que le
proporcionan el valor máximo al cliente como se priorizó en el Backlog Priorizado del
Producto. Antes de comenzar un sprint —durante los procesos de Crear el Backlog
Priorizado del Producto o Refinamiento del Backlog Priorizado del Producto—, los
requisitos de mayor prioridad en el Backlog Priorizado del Producto se seleccionan
normalmente para completarse en ese sprint. Dado a que los cambios se han tenido
en cuenta en el Backlog Priorizado del Producto, el equipo sólo tiene que determinar el
número de tareas que se pueden realizar en el sprint, basado en el tiempo y los
recursos proporcionados. La gestión del cambio se lleva a cabo en los procesos de
priorización actuales, y se le agregan tareas al Backlog Priorizado del Producto.
69. Las solicitudes para hacer cambios se presentan por lo general como solicitudes de
cambio o Change Requests. Las solicitudes de cambio permanecen como no
aprobadas hasta que se obtiene una aprobación formal. El Scrum Guidance Body por
lo general define el proceso de decisión y gestión de cambios en la organización.

70. Las solicitudes podrían deberse a cambios en las condiciones del mercado, la
dirección de la organización, asuntos legales o reglamentarios, o a varias otras
razones. Por otra parte, los stakeholders pueden presentar dichas solicitudes a medida
que van revisando los entregables durante los procesos de Demostrar y validar el
sprint, Retrospectiva del sprint o Retrospectiva del proyecto.

71. Scrum sigue un enfoque iterativo e incremental de desarrollo de productos y servicios,

por lo que es posible la incorporación de cambios en cualquier paso en el proceso de
desarrollo. En la mayoría de los proyectos Scrum, las recomendaciones de cambios
por parte del equipo principal de Scrum suceden durante el proceso de Crear
entregables, o cuando participa en las Daily Standups o las reuniones de retrospectiva
del sprint.

72. El Scrum Guidance Body por lo general define el proceso de decisión y gestión de
cambios en la organización. En ausencia de un proceso formal, se recomienda que los
pequeños cambios que no tienen un impacto significativo en el proyecto se aprueben
directamente por el Product Owner.

73. ¿Quién de los siguientes evalúa las solicitudes de cambio en un proyecto de

Scrum? Product Owner

74. ¿Cuál rol es responsable de aprobar el impacto de los cambios en los requisitos
del portafolio? Portfolio Product Owner

75. Si hay una solicitud de cambio que puede tener un impacto considerable sobre un
sprint en curso, el Product Owner, después de consultar con stakeholders relevantes,
decide si el cambio puede esperar hasta el próximo sprint o si representa una situación
urgente que pueda requerir finalizar el sprint actual y comenzar uno nuevo.

76. Cualquier historia de usuario nueva o modificada que resulte de cambios en los
requerimientos de negocio, pedidos de los clientes, condiciones externas del mercado
y/o lecciones aprendidas en sprints anteriores, también se incorpora.

77. En Scrum, todos los requisitos relacionados con el sprint en curso se suspenden
durante el sprint. Ningún cambio se introduce hasta que se termina el sprint, a menos
que un cambio se considere lo suficientemente importante como para detener el sprint.
En el caso de un cambio urgente, el sprint se termina y el equipo se reúne para
planificar uno nuevo. Es así como Scrum acepta los cambios sin crear problemas de
cambio en las fechas de lanzamiento o inestabilidad.

78. Los cambios que están más allá del nivel de tolerancia del Product Owner pueden
necesitar de la aprobación de los stakeholders que trabajan con él/ella.