Inicio › Business Analyst › User Stories

Preguntas de práctica Business Analyst: User Stories

User Stories vale 18% del examen Salesforce Certified Business Analyst. Cubre formato de historias, criterios de aceptación e INVEST. Resuelve estas 9 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

Al revisar las historias de usuario de una nueva implementación de Salesforce CPQ en una empresa de equipo para exteriores, un BA encuentra esta historia: 'Como representante de ventas, quiero un botón para generar una cotización para poder enviar precios a los clientes.' Los desarrolladores indican que es demasiado grande para terminarla en un solo sprint. ¿Qué criterio INVEST incumple la historia?

Negotiable: una vez redactada, el alcance de la historia ya no puede cambiar.
Independent: la historia depende de otros componentes del sistema para funcionar.
Valuable: la historia no deja claro el valor de negocio para el usuario.
Small: la historia contiene más trabajo del que puede completarse en una sola iteración de sprint.

Ver respuesta

Respuesta: D

A. Negotiable: una vez redactada, el alcance de la historia ya no puede cambiar.Incorrecta. Negotiable significa que los detalles y el alcance pueden discutirse y ajustarse antes del desarrollo. Ser demasiado grande no vuelve a una historia no negociable; las historias grandes pueden dividirse.

B. Independent: la historia depende de otros componentes del sistema para funcionar.Incorrecta. La independencia se refiere a si otra historia bloquea a esta. El problema aquí es el tamaño, no la dependencia.

C. Valuable: la historia no deja claro el valor de negocio para el usuario.Incorrecta. La historia sí expresa su valor ('para poder enviar precios a los clientes'). La preocupación del equipo es el tamaño, no el valor.

D. Small: la historia contiene más trabajo del que puede completarse en una sola iteración de sprint. ✓Correcta. La 'S' de INVEST indica que una historia debe ser lo bastante pequeña para terminarse en un sprint. Una historia señalada como demasiado grande incumple Small y debe dividirse en historias del tamaño de un sprint.

Por qué: INVEST significa Independent, Negotiable, Valuable, Estimable, Small, Testable. Una historia que no cabe en un sprint incumple el criterio Small, por lo que el BA la divide en historias más pequeñas que quepan en el sprint y sigan entregando valor incremental.

Para una implementación de Salesforce CPQ en un fabricante de empaques, el BA redactó: 'Como ejecutivo de cuenta, quiero recibir una notificación cuando una cotización que envié haya sido aprobada para poder dar seguimiento oportuno al cliente.' En el backlog grooming, el product owner pregunta si la historia es negociable. En esta situación, ¿qué significa el criterio Negotiable de INVEST?

Negotiable significa que el product owner puede decidir no construir la historia si baja de prioridad en el backlog.
Negotiable significa que el CÓMO se entrega la historia (canal de notificación como correo electrónico, notificación en la app o notificación push) es flexible y puede discutirse y acordarse entre el BA, el product owner y el equipo de desarrollo: la necesidad de negocio es fija, mientras que los detalles de implementación quedan abiertos.
Negotiable significa que el persona de ejecutivo de cuenta puede cambiarse por cualquier otro persona de usuario de Salesforce sin alterar el valor de la historia.
Negotiable significa que los criterios de aceptación pueden cambiarse en cualquier momento del sprint sin consultar a nadie.

Ver respuesta

Respuesta: B

A. Negotiable significa que el product owner puede decidir no construir la historia si baja de prioridad en el backlog.Incorrecta. Cualquier elemento del backlog puede perder prioridad; eso no es lo que significa Negotiable. El término se refiere a la flexibilidad de los detalles de la historia, no a su prioridad.

B. Negotiable significa que el CÓMO se entrega la historia (canal de notificación como correo electrónico, notificación en la app o notificación push) es flexible y puede discutirse y acordarse entre el BA, el product owner y el equipo de desarrollo: la necesidad de negocio es fija, mientras que los detalles de implementación quedan abiertos. ✓Correcta. La necesidad de negocio es fija, pero el mecanismo de entrega (correo, banner en la app, notificación push, publicación en Chatter) puede discutirse según la factibilidad y la experiencia de usuario, lo que además evita que las historias dicten soluciones técnicas.

C. Negotiable significa que el persona de ejecutivo de cuenta puede cambiarse por cualquier otro persona de usuario de Salesforce sin alterar el valor de la historia.Incorrecta. El persona define quién se beneficia; cambiarlo cambia la historia misma. Negotiable se refiere a los detalles de implementación, no al quién/qué/por qué central.

D. Negotiable significa que los criterios de aceptación pueden cambiarse en cualquier momento del sprint sin consultar a nadie.Incorrecta. Cambiar los criterios de aceptación a mitad del sprint requiere consultar al product owner y a los stakeholders; no es un cambio unilateral. Negotiable se refiere a la flexibilidad de implementación antes del sprint.

Por qué: La 'N' de INVEST indica que una historia no es una especificación cerrada. La necesidad (que el ejecutivo sepa cuándo se aprueba una cotización) es firme, pero la forma de entregarla (correo, alerta en la app, Chatter) se acuerda entre el BA, el product owner y el equipo según la factibilidad y el diseño.

Un equipo de Service Cloud en una empresa de equipo para exteriores revisa esta historia: 'Como gestor de casos, quiero reasignar un caso a otro agente para que el cliente reciba ayuda oportuna del experto adecuado.' Los desarrolladores dicen que está lista para estimarse, pero el BA no está de acuerdo. ¿Qué carencia es más probable que vea el BA?

La historia no indica si deben usarse Cases o Tasks de Salesforce para registrar la reasignación.
La historia no tiene criterios de aceptación, por lo que no hay condiciones verificables que definan cuándo la funcionalidad de reasignación está implementada con éxito.
'Gestor de casos' no es un rol estándar de Salesforce y debe reemplazarse por 'System Administrator'.
La historia es demasiado breve y necesita un párrafo completo de contexto antes de que el equipo pueda estimarla.

Ver respuesta

Respuesta: B

A. La historia no indica si deben usarse Cases o Tasks de Salesforce para registrar la reasignación.Incorrecta. Qué objeto registra la reasignación es una decisión de implementación, no un criterio de preparación. Las historias deben ser agnósticas a la implementación.

B. La historia no tiene criterios de aceptación, por lo que no hay condiciones verificables que definan cuándo la funcionalidad de reasignación está implementada con éxito. ✓Correcta. El rol, la acción y el valor están presentes, pero nada define en términos verificables qué significa 'reasignar un caso': quién puede reasignar a quién, bajo qué condiciones y qué confirmación se envía. Estos deben ser criterios de aceptación antes de estimar y construir.

C. 'Gestor de casos' no es un rol estándar de Salesforce y debe reemplazarse por 'System Administrator'.Incorrecta. Gestor de casos es un rol de negocio válido. Los personas describen roles de negocio, no roles del sistema Salesforce.

D. La historia es demasiado breve y necesita un párrafo completo de contexto antes de que el equipo pueda estimarla.Incorrecta. La extensión no es una prueba de preparación; se prefieren historias breves y claras con buenos criterios de aceptación.

Por qué: Incluso una declaración de historia bien estructurada no está lista sin criterios de aceptación. Los criterios definen cuándo se permite la reasignación, cómo debe comportarse el sistema y qué resultado demuestra que funciona; sin ellos, los desarrolladores construyen su propia interpretación y UAT no tiene nada concreto que probar.

Un BA en un fabricante de empaques encuentra esto en el sprint backlog: 'Como gerente de servicio al cliente, quiero que el sistema escale automáticamente a un agente sénior los casos abiertos por más de 2 horas Y envíe una notificación por correo al gerente Y cree una tarea de seguimiento Y actualice la prioridad del caso a High.' Los desarrolladores estiman tres sprints. ¿Qué debe hacer el BA?

Aceptar la estimación de tres sprints, ya que la historia describe un proceso de negocio completo y no debería dividirse.
Pedir a los desarrolladores que aumenten su velocidad de sprint para que quepa la historia grande.
Dividir la historia en historias más pequeñas y entregables de forma independiente; por ejemplo, historias separadas para el enrutamiento de escalamiento, la notificación por correo al gerente, la creación de la tarea de seguimiento y la actualización de prioridad.
Convertir la historia en una épica y posponer los cuatro comportamientos a una fase posterior del proyecto.

Ver respuesta

Respuesta: C

A. Aceptar la estimación de tres sprints, ya que la historia describe un proceso de negocio completo y no debería dividirse.Incorrecta. Necesitar tres sprints incumple Small. Incluso un proceso completo debe dividirse en historias del tamaño de un sprint para mantener la entrega iterativa.

B. Pedir a los desarrolladores que aumenten su velocidad de sprint para que quepa la historia grande.Incorrecta. Exigir más velocidad no corrige una historia mal dimensionada; la descomposición sí.

C. Dividir la historia en historias más pequeñas y entregables de forma independiente; por ejemplo, historias separadas para el enrutamiento de escalamiento, la notificación por correo al gerente, la creación de la tarea de seguimiento y la actualización de prioridad. ✓Correcta. Los cuatro comportamientos distintos pueden desarrollarse, probarse y liberarse por separado, lo que hace que cada parte quepa en un sprint y entregue valor de forma incremental.

D. Convertir la historia en una épica y posponer los cuatro comportamientos a una fase posterior del proyecto.Incorrecta. Las épicas sirven para funcionalidades muy grandes, pero estos comportamientos concretos pueden ajustarse a sprints dividiéndolos. Posponerlo todo es innecesario.

Por qué: Una historia que no cabe en un sprint incumple el criterio Small de INVEST, así que el BA la descompone. Cada historia resultante debe tener valor por sí misma; el escalamiento, la notificación por correo, la creación de la tarea y la actualización de prioridad pueden construirse, probarse y entregarse de forma independiente.

En una sprint review en una marca de tenis, el equipo presenta una funcionalidad terminada del dashboard de oportunidades de ventas. Representantes de ventas que nunca participaron en las sesiones de requisitos originales ven la demo y plantean cinco nuevos requisitos que consideran críticos. El product owner pregunta al BA cómo manejarlos. ¿Qué debe recomendar el BA?

Agregar los cinco requisitos al sprint actual como historias adicionales, ya que la revisión expuso un vacío en el descubrimiento original.
Reconocer los nuevos requisitos, registrarlos como historias de usuario en el product backlog y priorizarlos con el product owner para un sprint futuro.
Rechazar los cinco porque no se identificaron en las sesiones de descubrimiento originales y están fuera del alcance.
Pedir a los representantes de ventas que documenten ellos mismos los requisitos y los envíen al gerente de proyecto para agregarlos al plan del proyecto.

Ver respuesta

Respuesta: B

A. Agregar los cinco requisitos al sprint actual como historias adicionales, ya que la revisión expuso un vacío en el descubrimiento original.Incorrecta. Agregar alcance a un sprint en curso rompe los compromisos y desestabiliza la entrega. La respuesta correcta es la gestión del backlog.

B. Reconocer los nuevos requisitos, registrarlos como historias de usuario en el product backlog y priorizarlos con el product owner para un sprint futuro. ✓Correcta. El BA registra los requisitos como historias de usuario en el backlog y el product owner los ordena frente a los elementos existentes para un sprint futuro, manteniendo la integridad del sprint sin perder nada.

C. Rechazar los cinco porque no se identificaron en las sesiones de descubrimiento originales y están fuera del alcance.Incorrecta. Rechazar necesidades de negocio reales por surgir tarde es un error; Agile acoge requisitos que evolucionan. La tarea del BA es documentarlos, no bloquearlos.

D. Pedir a los representantes de ventas que documenten ellos mismos los requisitos y los envíen al gerente de proyecto para agregarlos al plan del proyecto.Incorrecta. Que los usuarios se documenten solos y eviten al BA omite el rol de gestión de requisitos del BA. El BA debe elicitar y redactar las historias junto con los representantes.

Por qué: Descubrir nuevos requisitos en una sprint review es normal en Agile; ver software funcionando genera aprendizaje. El BA los registra como historias de usuario en el backlog y los prioriza con el product owner para sprints posteriores, lo que protege el sprint actual y mantiene registrados los nuevos hallazgos.

En una sprint review de Service Cloud en un fabricante de empaques, el equipo muestra una historia terminada. Un stakeholder dice: 'Esto funciona bien, pero también necesito que los casos abiertos por más de 4 horas se escalen automáticamente.' Al revisar la historia y los criterios de aceptación originales, el BA confirma que el escalamiento nunca se documentó. ¿Qué debe hacer el BA A CONTINUACIÓN?

Agregar el escalamiento a los criterios de aceptación de la historia existente y pedir al desarrollador que lo construya de inmediato.
Reconocer el comentario, redactar una nueva historia de usuario para el requisito de escalamiento y colocarla en el product backlog para priorizarla en un sprint futuro.
Descartar el comentario porque la historia original se terminó y se cumplieron sus criterios de aceptación.
Agregar la regla de escalamiento a la definition of done de la historia actual y marcar la historia como incompleta.

Ver respuesta

Respuesta: B

A. Agregar el escalamiento a los criterios de aceptación de la historia existente y pedir al desarrollador que lo construya de inmediato.Incorrecta. Reabrir una historia terminada y exigir trabajo inmediato se salta la sprint planning, agrega trabajo no planificado y desestabiliza el backlog. Es alcance nuevo, no una corrección.

B. Reconocer el comentario, redactar una nueva historia de usuario para el requisito de escalamiento y colocarla en el product backlog para priorizarla en un sprint futuro. ✓Correcta. La nueva funcionalidad detectada en una revisión o en UAT se convierte en una nueva historia del backlog, de modo que se registra y prioriza sin interrumpir el sprint actual.

C. Descartar el comentario porque la historia original se terminó y se cumplieron sus criterios de aceptación.Incorrecta. Descartar comentarios válidos erosiona la confianza y deja sin atender una necesidad real. El BA gestiona el alcance mediante el proceso adecuado.

D. Agregar la regla de escalamiento a la definition of done de la historia actual y marcar la historia como incompleta.Incorrecta. La Definition of Done es un estándar de calidad del equipo (código revisado, probado, desplegado en sandbox), no un lugar para nuevos requisitos funcionales. Lo correcto es una nueva historia.

Por qué: Los requisitos totalmente nuevos que surgen en una sprint review son un cambio de alcance: se reconocen, se redacta una nueva historia de usuario y se agrega al backlog para priorizarla. Esto protege el sprint y mantiene registrada la necesidad. Hay que distinguir: los criterios de aceptación son específicos de cada historia, mientras que la Definition of Done es una compuerta de calidad de todo el equipo.

Un BA en un fabricante de empaques revisa los criterios de aceptación de una historia de oportunidades de Salesforce Sales Cloud, que dicen: 'El sistema debe permitir que los representantes de ventas creen oportunidades.' Un tester informa que no puede determinar si esto se aprueba o falla. ¿Qué cambio debe hacer el BA?

Eliminar el criterio porque crear oportunidades es una funcionalidad estándar de Salesforce que no necesita documentarse.
Reescribirlo en formato Given/When/Then con precondiciones específicas, acciones del usuario y resultados esperados observables que el tester pueda juzgar sin ambigüedad como aprobado o fallido.
Agregar una nota al criterio que diga que 'debe ser probado a fondo por el equipo de desarrollo antes de UAT'.
Convertir el criterio en una historia de usuario: 'Como representante de ventas, quiero crear oportunidades para poder dar seguimiento a mi pipeline de ventas.'

Ver respuesta

Respuesta: B

A. Eliminar el criterio porque crear oportunidades es una funcionalidad estándar de Salesforce que no necesita documentarse.Incorrecta. Las funcionalidades estándar también necesitan criterios de aceptación cuando forman parte de la historia; de lo contrario, el tester no puede confirmar que funcionan en este contexto de negocio.

B. Reescribirlo en formato Given/When/Then con precondiciones específicas, acciones del usuario y resultados esperados observables que el tester pueda juzgar sin ambigüedad como aprobado o fallido. ✓Correcta. Por ejemplo: 'Given un representante de ventas con permiso de creación de Opportunity, When hace clic en New Opportunity, llena los campos obligatorios y guarda, Then se crea un nuevo registro de oportunidad con los datos ingresados y el representante como propietario.' Esto da un resultado claro de aprobado/fallido.

C. Agregar una nota al criterio que diga que 'debe ser probado a fondo por el equipo de desarrollo antes de UAT'.Incorrecta. Las pruebas del desarrollador forman parte de la Definition of Done y no corrigen un criterio vago.

D. Convertir el criterio en una historia de usuario: 'Como representante de ventas, quiero crear oportunidades para poder dar seguimiento a mi pipeline de ventas.'Incorrecta. Una historia expresa la necesidad y los criterios de aceptación sus condiciones verificables; ambos son necesarios y uno no puede convertirse en el otro.

Por qué: Los criterios de aceptación deben permitir que un tester decida si se aprueba o falla sin interpretación. La redacción actual no indica condición, acción ni resultado observable. Given/When/Then aporta una precondición (Given), una acción desencadenante (When) y un estado esperado del sistema (Then), lo que hace que UAT sea objetivo y consistente.

Un minorista de calzado está cerrando una implementación de Sales Cloud y el BA debe evaluar si se cumplieron los objetivos de negocio originales. Los objetivos eran 'Reducir 30% el tiempo de captura de datos de los representantes de ventas' y 'Dar a los gerentes regionales mayor visibilidad del pipeline.' ¿Cómo debe evaluarlos el BA?

Preguntar al patrocinador del proyecto si, en su opinión, se alcanzaron los objetivos.
Medir después de la implementación, con el mismo método, las métricas que se tomaron como línea base durante el descubrimiento (tiempo de captura de datos y calificaciones de visibilidad del pipeline antes del go-live) y comparar ambas.
Revisar la lista de requisitos aprobados y confirmar que cada historia de usuario se entregó como 'done.'
Encuestar a los desarrolladores sobre si creen que las funcionalidades entregadas reducirán la captura de datos y mejorarán la visibilidad.

Ver respuesta

Respuesta: B

A. Preguntar al patrocinador del proyecto si, en su opinión, se alcanzaron los objetivos.Incorrecta. La opinión del patrocinador es subjetiva. Los objetivos cuantificados requieren evidencia medible.

B. Medir después de la implementación, con el mismo método, las métricas que se tomaron como línea base durante el descubrimiento (tiempo de captura de datos y calificaciones de visibilidad del pipeline antes del go-live) y comparar ambas. ✓Correcta. Comparar las mediciones posteriores con la línea base del descubrimiento muestra directamente si se logró la reducción del 30%. Por eso capturar métricas de línea base en el descubrimiento es una tarea clave del BA.

C. Revisar la lista de requisitos aprobados y confirmar que cada historia de usuario se entregó como 'done.'Incorrecta. Que todas las historias estén 'done' demuestra que las funcionalidades se construyeron según lo especificado, no que produjeran el resultado de negocio. Un proyecto puede entregar todas las historias y aun así no cumplir sus objetivos.

D. Encuestar a los desarrolladores sobre si creen que las funcionalidades entregadas reducirán la captura de datos y mejorarán la visibilidad.Incorrecta. Las expectativas de los desarrolladores no son una medición. Los resultados deben contrastarse con datos reales de desempeño.

Por qué: El logro de los objetivos se demuestra comparando los resultados posteriores al go-live con la línea base tomada durante el descubrimiento, como los minutos diarios promedio de captura por representante o los puntajes de encuestas de visibilidad de los gerentes. Medir las mismas métricas de la misma forma después muestra si los objetivos cuantificados se cumplieron realmente, no solo si se entregaron funcionalidades.

Una empresa de artículos para acampar agrega una regla: 'Toda cotización con un total mayor a $50,000 requiere aprobación tanto del director regional de ventas COMO del VP de Finanzas.' El BA redacta criterios de aceptación Given/When/Then para la historia. ¿Qué criterio expresa MEJOR esta regla?

Dada cualquier cotización en el sistema, cuando se envía, entonces se notifica tanto al director regional como al VP de Finanzas.
Dada una cotización con un valor total de $50,000 o más, cuando un representante de ventas la envía a aprobación, entonces la cotización pasa por una aprobación de dos pasos que requiere la firma del director regional de ventas y del VP de Finanzas antes de poder enviarse al cliente.
Dada una cotización enviada con descuento, cuando el total supera los límites de la empresa, entonces se inicia un flujo de aprobación.
Dado que el VP de Finanzas y el director regional están disponibles, cuando se envía una cotización grande, entonces reciben un correo para aprobarla.

Ver respuesta

Respuesta: B

A. Dada cualquier cotización en el sistema, cuando se envía, entonces se notifica tanto al director regional como al VP de Finanzas.Incorrecta. Omite la condición de $50,000, así que toda cotización dispararía la doble notificación, lo cual es más amplio que el requisito.

B. Dada una cotización con un valor total de $50,000 o más, cuando un representante de ventas la envía a aprobación, entonces la cotización pasa por una aprobación de dos pasos que requiere la firma del director regional de ventas y del VP de Finanzas antes de poder enviarse al cliente. ✓Correcta. Cubre la precondición (total de $50,000 o más), el disparador (el representante envía a aprobación) y el comportamiento esperado (aprobación secuencial del director regional y del VP de Finanzas). Es específico, verificable y neutral respecto a la implementación.

C. Dada una cotización enviada con descuento, cuando el total supera los límites de la empresa, entonces se inicia un flujo de aprobación.Incorrecta. La regla se refiere al total de la cotización, no a descuentos, y 'límites de la empresa' no está definido ni puede probarse.

D. Dado que el VP de Finanzas y el director regional están disponibles, cuando se envía una cotización grande, entonces reciben un correo para aprobarla.Incorrecta. La disponibilidad de los aprobadores no es una precondición válida, y 'cotización grande' no es un umbral definido, por lo que el criterio no se puede probar.

Por qué: Los buenos criterios Given/When/Then indican el umbral exacto, se disparan por una acción del usuario (el When) y describen un resultado observable (el Then) sin dictar la construcción técnica. La opción correcta capta con precisión el umbral, el disparador y el resultado de doble aprobación.

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Business Analyst: 20 preguntas, sin cuenta. Después desbloquea las 180 preguntas, los exámenes de práctica completos y la guía de estudio.

Hacer el diagnóstico gratis Ver planes

Preguntas de práctica Business Analyst: User Stories

Descubre si estás listo para aprobar

Otras secciones de este examen