Consejos para mejores criterios de aceptación

Los criterios de aceptación son una parte esencial del desarrollo de productos. Ayudan a traducir requisitos, comunicar necesidades y confirmar la alineación.

Sin embargo, no todos son iguales. Hay una enorme diferencia entre pensamientos anotados con pereza y criterios de aceptación bien definidos.

Este último comunica claramente lo que se necesita desarrollar. El primero a menudo solo genera confusión y dudas.

En este artículo, aprenderá algunos consejos sobre cómo asegurarse de que sus criterios de aceptación sean útiles.

¿Cuáles son los criterios de aceptación?

En resumen, los criterios de aceptación sirven como una lista de verificación para determinar si un determinado ticket o historia de usuario se ha entregado en su totalidad.

Se podría decir que es un documento de requisitos del producto a nivel de tarea. Aclara el contenido del ticket, ayuda al equipo de control de calidad a comprender qué probar y ofrece a las partes interesadas visibilidad del alcance del trabajo planificado.

Consejos para unos buenos criterios de aceptación

Permítanme compartir algunos de mis consejos favoritos para hacer que los criterios de aceptación sean una parte verdaderamente valiosa del ciclo de vida del desarrollo del producto:

Incluir requisitos no funcionales

Créeme, si no te importan los requisitos no funcionales, lo más probable es que a otros tampoco. Y los requisitos no funcionales pueden determinar el éxito o el fracaso de una función. Al fin y al cabo, no importa lo buena que sea una función si su rendimiento la hace inutilizable.

Considere áreas como:

• Actuación
• Accesibilidad
• Cumplimiento
• Optimización de motores de búsqueda

Créame, arreglar requisitos no funcionales después de haber entregado una característica es un viaje al infierno.

Colabora con tu equipo

¿Incluir requisitos no funcionales en los criterios de aceptación implica ser extremadamente técnico? En realidad, no.

Recuerda que el desarrollo de productos es un trabajo en equipo. Como gerente de producto, tu trabajo es asegurarte de que los criterios de aceptación estén definidos y de que todos estén de acuerdo con ellos, pero no deberías ser el único que los redacte.

Su equipo aporta diferentes habilidades y perspectivas, lo que le ayudará a considerar más ángulos e identificar brechas en los requisitos.

Colaborar con las partes interesadas

“Si no está en los criterios de aceptación, no existe”.

Si bien muchas personas responsables de productos se abstienen de obligar a otras partes interesadas a profundizar tanto en los detalles, esto tiene más beneficios que desventajas.

Es una forma muy tangible de comunicar cómo planea lograr los resultados deseados y ayuda a evitar malentendidos y decepciones.

También tiende a generar conciencia sobre la cantidad de trabajo que realmente se requiere (especialmente en relación con los requisitos no funcionales), lo que hace que sea más fácil responder a la siempre temida pregunta “¿por qué está tomando tanto tiempo?”.

Explica a las partes interesadas los criterios de aceptación en una llamada. Si simplemente se lo envías para que lo revisen, lo más probable es que no lo hagan o que lo revisen por encima, lo cual frustra todo el propósito.

Priorato

Esto puede resultar un poco controvertido, pero me gusta marcar algunos de los criterios de aceptación como opcionales.

Cumple dos objetivos principales:

En primer lugar, permite retrasar las decisiones hasta obtener . Supongamos que está trabajando en un endpoint de API y le gustaría obtener un tiempo de respuesta de 100 ms, pero sabe que el promedio hasta ahora ha sido de 200 ms.

En lugar de refinar demasiado de antemano si es posible o no, escribiría los siguientes criterios de aceptación:

• Debe— Tiempo de respuesta inferior a 200 ms
• Debería— Tiempo de respuesta inferior a 100 ms

De esta manera, el equipo puede decidir mientras trabaja en el ticket si todos los criterios de aceptación son factibles y vale la pena seguirlos o no si no son posibles bajo las restricciones dadas.

También facilitan una mayor definición del alcance… Por ejemplo, si necesitas acelerar el desarrollo, puedes eliminar todos los criterios de aceptación deseables sin tener que reescribir todos los tickets.

Piense en escenarios negativos y casos extremos.

El error más común a la hora de redactar los criterios de aceptación es centrarse únicamente en el escenario feliz, es decir, lo que debería suceder cuando todo salga según lo previsto.

Pero no siempre sale según lo planeado. También hay que pensar en

• Escenarios negativos
• Condiciones de falla
• Casos extremos

Escenarios negativos

¿Qué debería ocurrir si el usuario no completa la tarea correctamente? El ejemplo clásico es intentar crear una cuenta nueva sin cumplir los criterios de seguridad de la contraseña. Necesita un mensaje de error, que debería incluirse en sus criterios de aceptación.

Condiciones de falla

Las condiciones de fallo son escenarios negativos que ocurren en el producto. Supongamos que desea crear una cuenta en un sitio web, pero la API de registro no responde. Le recomendamos tener un escenario alternativo o una comunicación de errores si esto ocurre.

No es necesario cubrir todos los escenarios de falla, pero asegúrese de decidir conscientemente qué ignorar.

Casos extremos

Los casos extremos son condiciones que, aunque son poco frecuentes, todavía ocurren.

Por ejemplo, podrías tener una plataforma de control de calidad donde la gran mayoría de las preguntas tienen entre 0 y 2 respuestas. Sin embargo, podría haber un 0,10 % de preguntas con más de 10 respuestas; este es un caso excepcional.

A veces, el caso extremo no requiere trabajo adicional, y otras veces, puede requerir ajustes. Por ejemplo, añadir paginación o cambiar la configuración de los anuncios.

De manera similar a las condiciones de falla, no es necesario ocuparse de cada caso extremo que exista, solo asegurarse de pensar en ellos y tomar decisiones conscientes sobre si ignorarlos o abordarlos.

Utilice una terminología coherente

Hay muchas formas de redactar los criterios de aceptación.

Podrías escribir una lista de verificación genérica, escribir toneladas de historias de usuarios o escenarios, o utilizar la sintaxis Gherkin de manera técnica.

Todas esas soluciones son válidas, solo asegúrate de mantener la constancia a lo largo del tiempo. A veces es muy tentador romper el formato por pura pereza o por falta de tiempo, pero créeme, suele ser contraproducente.

Cuanto más consistentes sean sus criterios de aceptación, menos lugar habrá para malentendidos.

Utilice elementos visuales

Sin embargo, hay una excepción a la coherencia. Aunque mis criterios de aceptación suelen presentarse por escrito, a veces recurro a simplificaciones como “tal como se ve en la foto”.

Imagínese convertir el siguiente diagrama de flujo en una lista escrita de criterios:

¿Es posible? Sí. ¿Será más preciso? No, la verdad. ¿Es más desmoralizante? Sin duda.

Algunos conceptos se explican mejor con imágenes.

Reflexiones finales

“¡Vaya, eso parece mucho esfuerzo!” es una reacción común que recibo cuando describo mi proceso.

Entiendo de dónde viene: es mucho trabajo.

En primer lugar, recuerde que es un trabajo en equipo. Involucre a diseñadores, desarrolladores y demás partes interesadas en el proceso. La función del gerente de proyecto es garantizar que se establezcan los criterios de aceptación y que todos estén de acuerdo con ellos.

En segundo lugar, es un esfuerzo bien invertido. Invertir una hora más en la redacción de los criterios de aceptación sigue siendo una mejor opción que perder horas cambiando de estrategia debido a malentendidos o solucionando problemas después del lanzamiento, simplemente porque se olvidaron casos extremos críticos.

Además, cuanto más practiques la redacción de los criterios de aceptación, más fácil te resultará con el tiempo.

Fuente de la imagen destacada: IconScout

Si quieres conocer otros artículos parecidos a Consejos para mejores criterios de aceptación puedes visitar la categoría Consejos.