Jump to content

Criterios de aceptación: Difference between revisions

From Scrum Manager BoK
← Older editNewer edit →
Mberne (talk | contribs)
Bureaucrats, Interface administrators
1,928 edits
No edit summary
No edit summary
Line 1: Line 1:
Los '''criterios de aceptación''' definen qué requisitos mínimos debe cumplir una [[historia de usuario]] para determinar que ésta funciona adecuadamente. A diferencia de la [[definición de hecho]], los criterios de aceptación se centran en cada elemento de la [[pila del producto]] por separado.
{{Meta-bok|min=5}}
==Características==
*Suelen presentarse en '''formato de lista o flujo'''.
*'''Pueden escribirse en lenguaje natural''', tal y como el ''[[product owner]]'' o el miembro del equipo que sugiera cada criterio se exprese. Lo importante es que ayuden a recordar de forma breve y clara la intención detrás de cada criterio.
*Aunque el product owner puede haber ido preparando estos criterios con antelación, '''se concretan en equipo durante la reunión de [[planificación del sprint]]'''. Ya que ayudan a entender lo que el cliente espera conseguir con ese incremento y con cada historia que forma parte de él.
*Es '''responsabilidad del propietario del producto''' asegurarse de que los criterios de aceptación cubren todos los aspectos necesarios para que el equipo estime y desarrolle las historias adecuadamente.
*'''Cuando llegue la [[revisión del sprint]]''', el product owner comprobará si cada una de las historias de usuario se puede aceptar en función a los criterios que se definieron.
 
==Elementos==
[[File:CriteriosDeAceptacion.png|thumb|right]]  
[[File:CriteriosDeAceptacion.png|thumb|right]]  
*el '''número de escenario''';
Los '''criterios de aceptación''' definen los requisitos mínimos que debe cumplir una [[historia de usuario]] para considerarse completada y aceptable para el cliente. Son el acuerdo explícito entre el [[propietario del producto]] y el equipo sobre qué significa que una historia "funciona correctamente". A diferencia de la [[definición de hecho]], que aplica a todas las historias por igual, los criterios de aceptación son específicos de cada historia.
*el '''título''', donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”;
*el '''contexto''', o sea las condiciones que desencadenan el escenario, y que se expresan con «Dado que»;
*el '''evento''', es decir, la acción que el usuario ejecuta en el contexto definido para el escenario. Nos referimos a él usando «Cuando»;
*y el '''resultado o comportamiento esperado''', que es el comportamiento del sistema en esa situación. Y que se expresa con «Entonces».
 
==Cómo se redactan==
Pueden escribirse tal como el propietario del producto se expresa, y pueden tener distintos formatos. El formato que empleemos dependerá de factores como las preferencias del equipo y el product owner.
 
Una manera popular de redactarlos es mediante '''BDD''' (''Behavior Driven Development'') y '''gherkin'''.
*'''BDD (''Behavior Driven Development'')''' es un enfoque de desarrollo de software que se centra en la comprensión de los comportamientos esperados de un sistema a través de la escritura de escenarios de usuario. Se basa en la colaboración entre desarrolladores, técnicos y stakeholders para definir claramente los requisitos y asegurarse de que el software cumpla con ellos.
*'''Gherkin''' es un lenguaje creado para las descripciones de comportamiento de software. Se utiliza en BDD para describir escenarios en un formato fácilmente legible y comprensible tanto para los desarrolladores como para los no técnicos.
===Ejemplo===
'''Historia de usuario:''' ''Como cliente, quiero tener la capacidad de realizar una búsqueda avanzada de productos en la tienda en línea para encontrar fácilmente lo que estoy buscando''.


<blockquote><small>'''Escenario 1: Búsqueda por nombre de producto'''
== Características ==


'''Dado que''' un cliente ha accedido a la tienda en línea.
Se presentan habitualmente en '''formato de lista o escenarios'''.
Pueden escribirse en '''lenguaje natural''': lo importante es que reflejen de forma clara la intención detrás de cada criterio, no que sigan una sintaxis formal.
Aunque el propietario del producto puede haberlos preparado con antelación, '''se concretan en equipo durante el [[planificación del sprint|refinamiento]] o la planificación del sprint'''. La conversación que genera ese proceso es tan valiosa como el resultado escrito.
Es '''responsabilidad del propietario del producto''' asegurarse de que los criterios cubren todos los aspectos necesarios para que el equipo pueda estimar y desarrollar la historia adecuadamente.
En la '''[[revisión del sprint]]''', el propietario del producto comprueba si cada historia cumple los criterios definidos para aceptarla o devolverla.


'''Cuando''' el cliente quiere buscar un producto por su nombre.
== Cómo se redactan ==
=== Lenguaje natural ===
La forma más sencilla: una lista de condiciones que el sistema debe cumplir.
Ejemplo para la historia "Como cliente, quiero buscar productos por nombre":


'''Entonces''' el cliente debería ver un campo de búsqueda en la página principal claramente visible.
El campo de búsqueda es visible en la página principal.
Al escribir un nombre y pulsar "Buscar", se muestra una lista de productos coincidentes.
Cada resultado muestra al menos el título, el precio y una imagen.
Si no hay resultados, se muestra un mensaje claro al usuario.


Y el cliente debería poder ingresar el nombre del producto que busca en el campo de búsqueda.
=== Formato BDD / Gherkin ===
El '''BDD''' (''Behavior Driven Development'') es un enfoque que centra el desarrollo en la comprensión del comportamiento esperado del sistema. '''Gherkin''' es el lenguaje que usa para describir escenarios de forma legible tanto para el equipo técnico como para los stakeholders.
La estructura es: '''Dado que''' (contexto) / '''Cuando''' (acción) / '''Entonces''' (resultado esperado).
'''Historia:''' ''Como cliente, quiero realizar una búsqueda avanzada de productos para encontrar fácilmente lo que busco.''


Y al presionar "Buscar", el cliente debería ver una lista de productos que coincidan con el nombre proporcionado.
<blockquote><small>'''Escenario 1: Búsqueda por nombre'''


Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.</small></blockquote>
'''Dado que''' un cliente ha accedido a la tienda.


<blockquote><small>'''Escenario 2: Búsqueda por categoría de producto'''
'''Cuando''' escribe el nombre de un producto en el campo de búsqueda y pulsa "Buscar".


'''Dado que''' un cliente ha accedido a la tienda en línea.
'''Entonces''' ve una lista de productos que coinciden con el nombre introducido, con título, precio e imagen.</small></blockquote>


'''Cuando''' el cliente quiere filtrar los productos por categoría.
<blockquote><small>'''Escenario 2: Búsqueda por categoría'''


'''Entonces''' el cliente debería poder seleccionar una categoría de una lista desplegable de categorías disponibles.
'''Dado que''' un cliente ha accedido a la tienda.


Y al seleccionar una categoría y hacer clic en "Buscar", el cliente debería ver una lista de productos que pertenecen a la categoría seleccionada.
'''Cuando''' selecciona una categoría del desplegable y pulsa "Buscar".


Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.</small></blockquote>
'''Entonces''' ve una lista de productos de esa categoría, con título, precio e imagen.</small></blockquote>
== Criterios de aceptación para historias con IA ==
Cuando una historia implica output generado por IA —texto, imágenes, recomendaciones, clasificaciones— los criterios de aceptación tradicionales no son suficientes. El equipo necesita definir explícitamente:


==Véase también==
'''Criterios de calidad del output:''' ¿cuándo es el resultado "suficientemente bueno"? Por ejemplo: "El resumen generado no supera las 150 palabras y cubre los puntos clave del documento original".
*[[Historia de usuario]].
'''Criterios de supervisión humana:''' "Toda respuesta generada por IA ha sido revisada por un agente humano antes de mostrarse al usuario".
*[[Definición de hecho]].
'''Criterios de comportamiento ante casos límite:''' "Si el modelo no puede generar una respuesta con suficiente confianza, muestra un mensaje de derivación en lugar de una respuesta incorrecta".
*[[Pila del producto]].
'''Criterios de privacidad:''' "Ningún dato personal del usuario se envía al modelo externo sin consentimiento explícito".
*[[Product owner]].
*[https://www.scrummanager.com/blog/2023/03/criterios-de-aceptacion-definicion-y-ejemplos/ Scrum Manager Blog: «Criterios de aceptación: ejemplos para elaborarlos»].
*[https://open.spotify.com/episode/0GjNQprSs7wbQ8s6G0lGXu?si=f6b4006adcd24e1f Scrum Manager Podcast | Episodio 6: Definition of Done].  
*[https://www.scrummanager.com/blog/2023/03/definition-of-done-o-definicion-de-hecho/ Scrum Manager Blog: Transcripción Scrum Manager Podcast | Episodio 6: Definition of Done].


<div class="bok-aviso">
Sin criterios de aceptación específicos para el comportamiento de la IA, el equipo no tiene forma de saber cuándo una historia con componente de IA está realmente terminada. "El modelo responde bien" no es un criterio de aceptación: es una impresión subjetiva.
</div>
== Error frecuente ==
<div class="bok-aviso">
'''Confundir criterios de aceptación con criterios de prueba.''' Los criterios de aceptación los define el propietario del producto para comunicar qué espera del sistema. Los casos de prueba los define el equipo técnico para verificar que el sistema se comporta correctamente. Son complementarios pero no idénticos: un criterio de aceptación puede dar lugar a múltiples casos de prueba, y no todos los casos de prueba corresponden a un criterio de aceptación explícito.
</div>
== Recursos ==
<div class="bok-recurso">
📄 [https://www.scrummanager.com/blog/2023/03/criterios-de-aceptacion-definicion-y-ejemplos/ Blog: Criterios de aceptación: ejemplos para elaborarlos]<span class="detalle">Scrum Manager Blog · mar 2023</span>
</div>
<div class="bok-recurso">
🎙️ [https://open.spotify.com/episode/0GjNQprSs7wbQ8s6G0lGXu Podcast Ep. 6: Definition of Done]<span class="detalle">Scrum Manager Podcast · Spotify</span>
</div>
== Véase también ==
<div class="bok-tags">
[[Historia de usuario]] [[Definición de hecho]] [[A punto]] [[Planificación del sprint]] [[Pila del producto]] [[Propietario del producto]] [[INVEST]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Glosario de términos]]
[[Category:Scrum]]
[[Category:Scrum]]
[[Category:Standard scrum]]
[[Category:Standard scrum]]

Revision as of 14:21, 12 May 2026

⏱ 5 min de lectura  ·  📅 Actualizado en 2026

Los criterios de aceptación definen los requisitos mínimos que debe cumplir una historia de usuario para considerarse completada y aceptable para el cliente. Son el acuerdo explícito entre el propietario del producto y el equipo sobre qué significa que una historia "funciona correctamente". A diferencia de la definición de hecho, que aplica a todas las historias por igual, los criterios de aceptación son específicos de cada historia.

Características

Se presentan habitualmente en formato de lista o escenarios. Pueden escribirse en lenguaje natural: lo importante es que reflejen de forma clara la intención detrás de cada criterio, no que sigan una sintaxis formal. Aunque el propietario del producto puede haberlos preparado con antelación, se concretan en equipo durante el refinamiento o la planificación del sprint. La conversación que genera ese proceso es tan valiosa como el resultado escrito. Es responsabilidad del propietario del producto asegurarse de que los criterios cubren todos los aspectos necesarios para que el equipo pueda estimar y desarrollar la historia adecuadamente. En la revisión del sprint, el propietario del producto comprueba si cada historia cumple los criterios definidos para aceptarla o devolverla.

Cómo se redactan

Lenguaje natural

La forma más sencilla: una lista de condiciones que el sistema debe cumplir. Ejemplo para la historia "Como cliente, quiero buscar productos por nombre":

El campo de búsqueda es visible en la página principal. Al escribir un nombre y pulsar "Buscar", se muestra una lista de productos coincidentes. Cada resultado muestra al menos el título, el precio y una imagen. Si no hay resultados, se muestra un mensaje claro al usuario.

Formato BDD / Gherkin

El BDD (Behavior Driven Development) es un enfoque que centra el desarrollo en la comprensión del comportamiento esperado del sistema. Gherkin es el lenguaje que usa para describir escenarios de forma legible tanto para el equipo técnico como para los stakeholders. La estructura es: Dado que (contexto) / Cuando (acción) / Entonces (resultado esperado). Historia: Como cliente, quiero realizar una búsqueda avanzada de productos para encontrar fácilmente lo que busco.

Escenario 1: Búsqueda por nombre

Dado que un cliente ha accedido a la tienda.

Cuando escribe el nombre de un producto en el campo de búsqueda y pulsa "Buscar".

Entonces ve una lista de productos que coinciden con el nombre introducido, con título, precio e imagen.

Escenario 2: Búsqueda por categoría

Dado que un cliente ha accedido a la tienda.

Cuando selecciona una categoría del desplegable y pulsa "Buscar".

Entonces ve una lista de productos de esa categoría, con título, precio e imagen.

Criterios de aceptación para historias con IA

Cuando una historia implica output generado por IA —texto, imágenes, recomendaciones, clasificaciones— los criterios de aceptación tradicionales no son suficientes. El equipo necesita definir explícitamente:

Criterios de calidad del output: ¿cuándo es el resultado "suficientemente bueno"? Por ejemplo: "El resumen generado no supera las 150 palabras y cubre los puntos clave del documento original". Criterios de supervisión humana: "Toda respuesta generada por IA ha sido revisada por un agente humano antes de mostrarse al usuario". Criterios de comportamiento ante casos límite: "Si el modelo no puede generar una respuesta con suficiente confianza, muestra un mensaje de derivación en lugar de una respuesta incorrecta". Criterios de privacidad: "Ningún dato personal del usuario se envía al modelo externo sin consentimiento explícito".

Sin criterios de aceptación específicos para el comportamiento de la IA, el equipo no tiene forma de saber cuándo una historia con componente de IA está realmente terminada. "El modelo responde bien" no es un criterio de aceptación: es una impresión subjetiva.

Error frecuente

Confundir criterios de aceptación con criterios de prueba. Los criterios de aceptación los define el propietario del producto para comunicar qué espera del sistema. Los casos de prueba los define el equipo técnico para verificar que el sistema se comporta correctamente. Son complementarios pero no idénticos: un criterio de aceptación puede dar lugar a múltiples casos de prueba, y no todos los casos de prueba corresponden a un criterio de aceptación explícito.

Recursos

📄 Blog: Criterios de aceptación: ejemplos para elaborarlosScrum Manager Blog · mar 2023

🎙️ Podcast Ep. 6: Definition of DoneScrum Manager Podcast · Spotify

Véase también

Historia de usuario Definición de hecho A punto Planificación del sprint Pila del producto Propietario del producto INVEST

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.

Buscar convocatorias
Club Agile
Retrieved from "https://www.scrummanager.com/bok/index.php?title=Criterios_de_aceptación&oldid=3552"