La Respuesta Corta
Una buena historia de usuario en Salesforce describe quién es el usuario, qué intenta lograr y qué debe ser correcto después de la acción – y no qué campo aparecerá en qué pantalla. La prueba simple es: si los criterios de aceptación se pueden escribir sin saber si la implementación será un Flow, una Validation Rule o Apex, la historia está correctamente formulada.
El error común es una historia que ya contiene la solución. Una vez que se escribe "Agregar un campo Picklist a la pantalla de la oportunidad", la discusión sobre el proceso se cierra antes de empezar.
Estructura Efectiva
| Componente | Función | Prueba de Calidad |
|---|---|---|
| Contexto | Quién es el usuario y cuándo actúa | Rol real, no "usuario" |
| Intención | Qué intenta lograr | Formulado en lenguaje empresarial |
| Criterios de Aceptación | Qué se verifica | Ejecutable como escenario con datos de prueba |
| Casos Extremos | Qué falla intencionadamente | Al menos uno negativo |
| Fuera de Alcance | Qué no se incluye explícitamente | Evita disputas en la aceptación |
La última línea ahorra la mayoría de los conflictos. Una declaración explícita de lo que no está incluido vale más que tres párrafos de descripción.
Desglose: Vertical Slice en lugar de Capas
La tentación en un proyecto CRM es desglosar por componentes técnicos: primero el modelo de datos, luego las automatizaciones, finalmente los informes. El resultado es que no hay nada que mostrar hasta el final, y nadie sabe si el proceso funciona.
El desglose correcto es vertical: un escenario completo, de principio a fin, para un perfil de usuario. Una oportunidad que se abre, avanza, se cierra y aparece en un informe vale más que diez objetos definidos sin proceso. Posteriormente, se añaden perfiles y escenarios alrededor de esa estructura.
Priorización cuando todo es Urgente
Tres criterios son suficientes, en este orden:
- ¿Bloquea la salida a producción? – Sin él, el proceso está incompleto. No hay lugar para la negociación.
- ¿Cuántos usuarios al día? – La frecuencia prevalece sobre la intensidad de la queja. Un elemento que afecta a 80 agentes diariamente tiene prioridad sobre la solicitud de un solo gerente.
- ¿Cuál es el costo del aplazamiento? – ¿Aumenta el costo de la implementación si lo hacemos después del lanzamiento? Un cambio en el modelo de datos sí, un cambio en un informe no.
Lo que no pasa estos tres criterios se traslada al Parking Lot. Esta separación evita que el Backlog se convierta en un archivo de deseos. Más detalles sobre la gestión del alcance se encuentran en Scope Creep y Control de Cambios.
Deuda de Requisitos: El Fallo Silencioso
La deuda de requisitos se crea cuando una historia se cierra sin haber decidido qué sucede en el caso extremo – se deja para "resolverlo más tarde". Después del lanzamiento, estos casos extremos son la mayoría de las llamadas al soporte.
La disciplina simple: un elemento no se cierra sin una decisión documentada para cada pregunta abierta registrada, incluso si la decisión es "intencionadamente no se aborda". Documentar la omisión vale más que no tener documentación.
Relación con las Pruebas
Los criterios de aceptación correctamente escritos son, de hecho, los scripts de UAT. Cuando se escriben después del desarrollo, el UAT se convierte en una demostración de lo construido en lugar de una prueba de lo requerido. La secuencia se detalla en la Guía de UAT.
Resumen
Un Backlog de calidad no es largo, sino claro: cada elemento indica para quién es, qué se medirá como éxito y qué no está incluido explícitamente. Estas tres preguntas, formuladas antes de la construcción y no después, determinan casi toda la calidad de la aceptación al final del proyecto.