how-it-works · agentic-qa · shift-left-testing
El Arte del Shift-Left Testing
Prevenir el defecto en los requisitos, no detectarlo tras la implementación. Cómo QA refina los Acceptance Criteria antes del sprint — y por qué todo proyecto lo necesita.
Seleccionar → Refinar → EntregarStage 0 · QA entra en el backlog, no al final
Encuadre: shift-left mueve la QA hacia la izquierda del ciclo — a la fase de requisitos. Refina ACs de Stories en backlog, destapa ambigüedades y huecos, y los entrega a PO/Dev ANTES del sprint. Dos pilares del deck: el CÓMO hacerlo bien y el POR QUÉ hacerlo en cada proyecto.
la economía del defecto
1 → 10 → 100
Cuesta 1× arreglar un defecto en los requisitos, ~10× en desarrollo, y ~100× en producción. Shift-left empuja la calidad hacia donde el defecto es más barato de matar: antes de escribir una sola línea.
La curva de costo del defecto (Boehm / IBM System Science Institute): el costo de corregir crece ~10x por fase. La tesis del shift-left es mover la detección a la izquierda. Volvemos al número en la slide de la curva.
qué cubriremos
El Porqué y el Cómo
01El porqué — prevención vs detección y la curva de costo del defectopor qué
02El pipeline — Stage 0: Selección → Refinamiento → Handoff, y sus límitesdónde
03Selección — qué Story refinar: veto, risk score, profundidadqué
04Refinamiento — el corazón: ambigüedades, huecos, el banco de preguntascómo bien
05Artefactos + Handoff — el ATP DRAFT, la máquina de estados, el short-circuitentregar
3 quizzes interactivos a lo largo del recorrido — haz clic en las respuestas.
El porqué (Parte 0) y el cómo hacerlo bien (Partes 2-4) son los dos pilares que pidió el usuario. Mapea al pipeline real: Selección → Refinamiento → Handoff.
por qué · la tesis
Prevenir, no Detectar
La QA tradicional detecta defectos después de construir. Shift-left los previene en el lugar donde nacen: los requisitos. Un AC ambiguo es un defecto esperando a ocurrir.
❌ QA al final (detectar)
- AC ambiguo → dev construye lo equivocado
- Bug se descubre en QA o en producción
- Retrabajo: re-diseño + re-código + re-test
- El defecto ya costó 10× o 100×
←
✓ QA al inicio (prevenir)
- QA refina el AC antes del sprint
- Ambigüedad resuelta como pregunta a PO
- Dev construye lo correcto a la primera
- El defecto nunca existió — costo 1×
El nombre lo dice: shift LEFT = mover QA hacia la izquierda del timeline (requisitos), no a la derecha (post-build). La frase canónica del skill: "defects prevented in the requirements, not detected after implementation".
por qué · la economía
La Curva de Costo del Defecto
Requisitos1×
Diseño~3×
Desarrollo~10×
QA / Testing~15×
Producción~100×
~10× por fase (Boehm · IBM SSI)
El costo de corregir un defecto crece de forma exponencial con cada fase que cruza sin detectarse. Shift-left invierte la apuesta: gasta horas de refinamiento en la fase 1× para no gastar semanas en la fase 100×.
Investigación clásica (Boehm, IBM System Science Institute, NIST): el costo relativo de corregir crece ~10x por fase. El refinamiento pre-sprint es la inversión más barata en calidad que existe.
por qué · en cada proyecto
Qué Previene Shift-Left — en Todo Proyecto
Ambigüedad → retrabajo
Un AC que admite dos lecturas → dev elige la equivocada → re-diseño. Resuelto como pregunta a PO antes de estimar.
Hueco → defecto en prod
Un camino negativo sin AC → nadie lo construye ni lo prueba → falla en producción. Surgido como gap antes del sprint.
AC no testeable → falso positivo
"Muestra error" sin texto exacto → QA escribe un assert que pasa con el error equivocado. Vuelto medible antes de codear.
Y un beneficio extra: destapar el trabajo mal etiquetado
Al filtrar candidatos, shift-left revela que lo que parecía una Story es en realidad un Bug o Tech-debt mal clasificado. Surfacing es el valor — incluso una Story limpia sale con lista de preguntas vacía, y eso también es un resultado válido.
Tres clases de defecto que shift-left previene en cualquier proyecto: ambigüedad (retrabajo), hueco (defecto prod), AC no testeable (falso positivo QA). Por eso aplica a TODO proyecto, no solo a los grandes.
PARTE 01
El Pipeline
Stage 0 — Antes del Sprint
Tres fases, siempre en orden: Selección → Refinamiento → Handoff. Batch por diseño: una sesión refina N Stories para un solo pase de grooming con el equipo.
Shift-left es Stage 0 del pipeline QA. Entra en el backlog, sale en estimation. Batch de 1-12 Stories.
tres fases en orden
Selección → Refinamiento → Handoff
1
Selección
Filtra candidatos del backlog (solo Stories), aplica veto + risk score, presenta tabla rankeada. WAIT por OK del usuario.
2
Refinamiento (el corazón)
Por Story: ambigüedades + huecos + edge cases no escritos + testabilidad. Refina ACs (Given/When/Then) y bosqueja outlines. Sin ejecutar.
3
Handoff
Escribe a Jira: ACs refinados, ATP DRAFT, preguntas a PO/Dev, labels, transición backlog → estimation. Batch report.
Batch por diseño
No hay modo single-ticket: una sesión refina N Stories (sweet spot 1-12) para que PO + Dev lead corran un solo pase de grooming con el equipo. >12 → divide en sesiones.
Selección → Refinamiento → Handoff, siempre en ese orden. Cada fase tiene un gate de usuario. Batch porque shift-left se hace en grooming de equipo.
por qué una disciplina aparte
Shift-Left vs Sprint-Testing
| Eje | /shift-left-testing | /sprint-testing |
|---|
| Cadencia | Pre-sprint, batch de N Stories | In-sprint, ticket por ticket |
| Entry status | Backlog / Shift-Left QA / Estimation | Ready For QA |
| Exit status | Estimation (refinado, sin estimar) | QA Approved (ejecutado) |
| Audiencia | PO / BA + tester | Dev + tester |
| Output | ACs refinados + risk map + ATP DRAFT | ATP + ATR + bugs + evidencia |
| Ejecución | Ninguna — la feature no existe aún | Smoke + UI/API/DB |
Reutilización deliberada
~70% de la lógica de refinamiento ya vive en acceptance-test-planning.md. Shift-left la cita, no la duplica — y el trabajo hecho aquí se reutiliza in-sprint (no se repite).
Misma metodología base, distinto momento y profundidad. Shift-left no ejecuta (la feature no existe). El output alimenta la estimación de PO.
qué NO hace
Los Límites del Scope
- Solo Stories — Bugs, Spikes, Sub-tasks, Tech-debt: rechazados. Un bug es reactivo, no tiene ACs upstream que refinar.
- Refina, no ejecuta — sin smoke, sin DB queries, sin API calls. La feasibility se establece leyendo código + APIs + schema.
- Para en Estimation — nunca avanza más allá. PO + Dev lead son dueños de estimate → ready_for_dev.
- Sin código, sin commit — Jira es canónico. El shift-left-refinement.md es working artifact gitignored.
- Sin test data, sin parametrización — outline names only. Eso se difiere a in-sprint.
- Sin TCs — los Test Cases se formalizan en Stage 4 (/test-documentation), no aquí.
La línea con sprint-testing
Todo lo que requiere correr el sistema (generación de datos, parametrización, fixtures) pertenece a /sprint-testing Stage 1. Shift-left es doc-only.
Límites claros: Stories only, no ejecución, para en estimation, no código. La feature aún no existe — por eso nada de datos/fixtures/TCs.
PARTE 02
Selección
Qué Story Refinar
No toda Story merece refinamiento. El veto descarta lo trivial; el risk score gradúa la profundidad. El objetivo: gastar el presupuesto de atención donde hay riesgo real.
Phase 1. Veto beats risk score. La selección decide qué entra al loop y a qué profundidad.
qué califica
Candidatos del Backlog
JQL · candidatos
project = {{PROJECT_KEY}} AND issueType = Story
AND status in (Backlog, "Shift-Left QA", Estimation, "Ready For Dev")
ORDER BY priority DESC, created DESC
# filtros opcionales:
AND sprint in openSprints() # candidatos del próximo sprint
AND labels != "shift-left-reviewed" # (pero PREFIERE surfacearlos)
Filtro de tipo (duro)
Solo Story. Bug/Spike/Sub-task/Tech-debt → rechazo, con razón de una línea. Nunca drop silencioso.
Freshness de label
shift-left-reviewed <30 días → ya refinada (surfacear: ¿refrescar?). >30 días → re-refinar (pudo derivar).
Entry: 4 estados (backlog/shift-left-qa/estimation/ready-for-dev). Solo Stories. Las ya revisadas se surfacean, no se auto-saltan.
el veto vence al score
Veto — Saltar vs Forzar
SKIP (descartar)
- Backend-only sin UI ni cambio de contrato
- CSS / estilo puro
- Copy estático / documentación
- Tech-debt sin cambio de comportamiento
- DB-only sin lógica de negocio
vs
FORCE FULL (forzar)
- Dinero / billing / refund / conversión
- Integridad de datos en entidades core
- Auth / authorization / sesión / RBAC
- Integraciones externas (Stripe, Auth0…)
- Máquinas de estado · cálculos / fórmulas
El veto vence al risk score
Una Story de dinero o auth se refina completa sin importar su puntaje. El riesgo de un cálculo mal o un bypass de auth no se negocia con un número.
Veto beats score. Lo trivial se descarta; lo crítico (dinero/datos/auth/integraciones/estados/cálculos) se fuerza a full refinement.
si no hay veto: gradúa la profundidad
Risk Score → Profundidad
Factores (suman)
- +3 feature nueva · +3 data dinámica (API/DB)
- +2 ACs explícitos · +2 user-facing · +2 alto esfuerzo
- +2 AC-light (<2 ACs o de 1 línea) → más refinamiento
- +1 prioridad alta · multi-componente · dep externa
- +1 >5 comentarios → desacuerdo sin resolver
Veredicto
0-3 LOW
SKIP — PO/Dev escriben ACs sin QA
4-7 MEDIUM
Refinamiento estándar
8+ HIGH
Extendido + scan de edge cases + data feasibility
El score gradúa profundidad. AC-light (+2) es señal de que justo esa Story necesita MÁS refinamiento. HIGH añade scan de feasibility de datos.
quiz · selección
¿Refinar o Saltar?
Q1Una Story de cálculo de impuestos tiene risk score 2 (LOW). ¿Qué se hace?
AFORCE FULL — el veto de "cálculos/fórmulas" vence al score bajo
BSKIP — score LOW, PO escribe los ACs
CRefinamiento estándar — score intermedio
FORCE FULL. El veto vence al risk score: dinero, datos, auth, integraciones, máquinas de estado y cálculos/fórmulas se refinan completos sin importar el puntaje. La precisión de un impuesto no se negocia.
Q2El usuario pega 5 IDs para refinar; uno es un Bug de "el botón no responde". ¿Qué pasa con el Bug?
ASe refina igual — es trabajo de QA
BSe rechaza con razón de una línea — shift-left es solo Stories
CSe convierte en Story automáticamente
Se rechaza (visible). Filtro de tipo duro: solo Stories. Un bug es reactivo — no tiene ACs upstream que refinar. Se surfacea con razón, nunca drop silencioso. Surfacear el mal etiquetado ES parte del valor.
Veto vence score (impuestos→full). Solo Stories (bug→rechazo visible). Dos reglas núcleo de la selección.
PARTE 03
Refinamiento
El Corazón del Shift-Left
Aquí está el valor: destapar las ambigüedades, los huecos y los edge cases que la Story calla. Los ACs son el piso — el refinamiento empuja más allá del happy path.
Phase 2, el corazón. Se aplica MÁS profundo que in-sprint porque PO aún puede actuar. ACs = piso, no techo.
cómo refinar bien
Las Cinco Sub-Análisis del Corazón
1 · Ambigüedades
Texto que admite varias lecturas → ubicación + pregunta a PO + impacto en testing + clarificación sugerida.
2 · Gaps (info faltante)
Tipo (AC / detalle técnico / regla de negocio) + por qué crítico + qué añadir + riesgo si se omite.
3 · Edge cases no escritos
Escenario + comportamiento esperado (mejor estimación) + criticidad + acción. Marcado NEEDS PO/DEV CONFIRMATION.
4 · Testabilidad
Yes / Partial / No + lista de issues (AC vago, sin texto de error, sin datos de ejemplo, sin criterio de perf, no aislable).
5 · Contradicciones
Secciones de la Story que se contradicen. Surfacear explícito: "La descripción dice X pero el AC3 dice Y".
Las 5 sub-análisis SON la taxonomía de gaps que shift-left destapa. La #3 (edge cases) y la #5 (contradicciones) son donde QA aporta lo que PO no vio.
qué hace bueno a un AC
Testabilidad — los Modos de Falla
AC NO testeable
- Vago — "funciona rápido" (sin métrica)
- Sin texto de error — "muestra error"
- Sin datos de ejemplo
- Sin criterio de performance
- No aislable — depende de otra feature
AC testeable
- Medible — "responde en < 2 segundos"
- Error exacto — texto + status code
- Con datos concretos
- Con budget de perf (p95)
- Aislable — verificable solo
El costo de un AC vago
"Muestra error" sin texto exacto → QA escribe un assert de "muestra algún error" que pasa con el error equivocado. Falso positivo en QA + defecto en producción. Por eso la testabilidad se valida ANTES de codear.
Los 5 modos de falla de testabilidad (verbatim del skill). El ejemplo "muestra error" → falso positivo es el caso canónico de por qué importa.
los ACs son el piso, no el techo
Explota 1:N — Empuja Más Allá del Happy Path
Un AC no-trivial implica varios escenarios. El refinamiento deriva por la forma del AC, y etiqueta cada hueco a su técnica.
| Si el AC tiene… | Técnica | Deriva |
|---|
| un rango / límite | Boundary Value Analysis | min-1·min·min+1 … max-1·max·max+1 |
| un campo de estado | State-Transition | 1 por transición válida + 1 por inválida |
| 2+ condiciones que interactúan | Decision Table | 1 por regla sobreviviente |
| 3+ factores combinables | Pairwise | set all-pairs (log de la reducción) |
Colapsar a 1 escenario exige justificación
"Trivialmente atómico" (un booleano, sin rangos/estados/interacciones) — y se dice por escrito. Un AC de 1 línea que esconde un rango o un estado NO es un AC de 1 escenario.
Conecta con las técnicas del deck de test-case-craft. El refinamiento etiqueta cada gap a su técnica. 1:N es el default; colapsar requiere justificar.
la herramienta del refinador
El Banco de Preguntas — Rúbrica, no Guion
1
Identifica el arquetipo
Auth · Money · Search · State Machine · Integration · CRUD · Notification · RBAC · Performance · a11y/i18n. Cada Story toca 2-3.
2
Recorre la lista del arquetipo
Cada pregunta sin respuesta explícita en la Story = candidato a gap.
3
Clasifica el gap
Critical → bloquea sprint planning (pregunta a PO) · Important → bloquea implementación (a Dev) · Edge → testeable, no bloquea.
Un gap no es solo una pregunta — es también un outline faltante
Y cada arquetipo mapea a su técnica: State Machine → State-Transition; Money/ranges → BVA; RBAC → Decision Table; configs multi-factor → Pairwise.
El banco es una rúbrica (no guion): si la Story ya responde, no se re-pregunta. Clasificar bien (Critical/Important/Edge) es señal de juicio. Cada gap = pregunta + outline.
las que casi siempre faltan
Preguntas Universales — el Núcleo
| # | Pregunta | Si no se responde… |
|---|
| U1 | ¿Texto EXACTO del error + status code por cada camino de fallo? | QA escribe assert que pasa con el error equivocado |
| U3 | ¿Qué pasa en éxito — redirect, toast, reload? | El test pasa por "sin error" pero la UI nunca actualizó |
| U5 | ¿La operación es idempotente? ¿Y si se dispara dos veces? | Cargos / registros duplicados |
| U7 | ¿Rollback en fallo parcial (3 de 5 registros fallan)? | Mutaciones a medias dejan el sistema inconsistente |
| U10 | ¿Hay estado "primera vez" / vacío distinto del estado normal? | El onboarding muestra una tabla vacía aterradora |
Pero solo si la Story no las responde ya
Las universales NO se incluyen por defecto — se recorren cuando la Story las deja sin responder. El archivo de refinamiento es de alta señal, no exhaustivo.
Muestra de las 10 universales (verbatim). La columna "si no se responde" es el catálogo de consecuencias por gap. No auto-incluir: solo lo no respondido.
las preguntas asesinas por dominio
Por Arquetipo — Donde Viven los Defectos
Auth / Sesión
- A1 · ¿Rol/permiso por cada AC?
- A8 · ¿No-autenticado → 401, 403 o 404? (403 vs 404 revela existencia)
- A10 · ¿Rate-limit + lockout por intentos?
Money / Billing
- M1 · ¿Moneda, precisión, redondeo?
- M3 · ¿El provider de pago hace timeout — retry, error, cola?
- M9 · ¿Proración al cambiar/cancelar plan?
State Machine
- SM1 · ¿TODOS los estados + transiciones válidas?
- SM3 · ¿Transición inválida (cancelar un delivered)?
- SM10 · ¿Transiciones concurrentes — lock/cola?
El catálogo cubre 10 arquetipos
Auth · Money · Search/List · State Machine · Integration · CRUD · Notification · RBAC · Performance · a11y/i18n — cada uno con ~10 preguntas asesinas y su modo de falla.
Las preguntas más filosas por dominio (verbatim). A8 (403 vs 404 = information disclosure), M1 (precisión de moneda), SM3 (transición inválida) son ejemplos de oro.
de gap a AC accionable
ACs Refinados — Given / When / Then
Cada escenario refinado lleva Tipo (Positive/Negative/Boundary/Edge) + Priority + Given/When/Then con valores exactos: UI + API (status+body) + DB + estado del sistema.
outlines derivados — "Should <behavior> <condition>"
Should redirect to dashboard after successful OTP entry with valid code
Should display "Code expired" error after OTP entry with code older than 5 min
Should reject negative refund amount on POST /refunds
# inferido, no literal en la Story:
Should show "Session expired" when OTP submitted after session expiry NEEDS PO/DEV CONFIRMATION
El marcador que sobrevive a Jira
Todo escenario que el refinamiento infirió (no estaba literal en la Story) lleva NEEDS PO/DEV CONFIRMATION — verbatim, en inglés. El marcador viaja al comentario de Jira para que PO lo vea en sprint planning.
El AC refinado (Given/When/Then) es la aserción de negocio; el outline (Should…) es su exploración. Lo inferido SIEMPRE lleva el marcador literal NEEDS PO/DEV CONFIRMATION (tooling lo grepea).
calidad > cantidad
El Arte de NO Preguntar
El recurso más escaso en un grooming es la atención del equipo. Una pregunta redundante entrena al equipo a ignorar el output futuro de QA.
- Story clara → dilo. "Calidad de la Story: buena, sin gaps significativos" supera a inventar preguntas. Lista vacía es un resultado válido.
- Rúbrica, no guion. Si la Story ya es explícita en un tema, no lo re-preguntes.
- Cita el contexto en vez de preguntar. Si business-data-map.md ya define la moneda o la máquina de estados, cítalo. PO tiene paciencia finita.
- Clasifica con juicio. Meter una pregunta de texto-de-éxito junto a una de bypass de auth señala falta de criterio.
Anti-patrón L1 (el más importante)
NUNCA fuerces preguntas para llenar un checklist. Shift-left aporta valor destapando riesgo real, no inflando conteos de preguntas.
El usuario valora esto: la regla #4 de CLAUDE.md. No forzar preguntas. Calidad sobre cantidad. Una Story limpia sale con lista vacía y está bien.
quiz · refinamiento
El Corazón del Refinamiento
Q1El refinamiento infiere un edge case que no está en la Story original. ¿Cómo se marca?
ASe añade al AC directamente como hecho
BSe marca NEEDS PO/DEV CONFIRMATION — verbatim, viaja a Jira
CSe descarta si no está en la Story
NEEDS PO/DEV CONFIRMATION. Todo lo inferido (no literal en la Story) lleva ese marcador exacto. Viaja al comentario de Jira para que PO lo confirme en sprint planning. El tooling después lo grepea — por eso es verbatim.
Q2Tras analizarla, la Story está genuinamente clara y completa. ¿Qué entregas?
AInventas algunas preguntas para que el refinamiento "se vea completo"
B"Calidad de la Story: buena, sin gaps" — lista de preguntas vacía
CLa rechazas porque no hay nada que refinar
Lista vacía. Una Story limpia sale con cero preguntas y eso es válido (anti-patrón L1: nunca fuerces preguntas). Calidad > cantidad: preguntas redundantes entrenan al equipo a ignorar a QA.
El marcador NEEDS PO/DEV CONFIRMATION para lo inferido; y la regla de no forzar preguntas (Story limpia → lista vacía válida).
PARTE 04
Artefactos + Handoff
Entregar a PO y Dev
El ATP DRAFT hace estimable la Story. El handoff la mueve a Estimation con labels que dejan que el sprint reutilice el trabajo — no lo repita.
Phase 3. El output llega a Jira: ACs refinados, ATP DRAFT, preguntas, labels, transición. Y el batch report.
el artefacto central
El ATP DRAFT — shift-left-refinement.md
Secciones
- Phase 1 — Análisis Crítico (contexto + complejidad)
- Phase 2 — Calidad (ambigüedades, gaps, edge, testabilidad)
- Phase 3 — ACs Refinados (Given/When/Then)
- Phase 4 — Outlines (NOMBRES) + estimación de cobertura
- Critical Questions PO · Tech Questions Dev
- Suggested Improvements · Data feasibility
DRAFT, no ATP completo
- NO tablas de parametrización
- NO test-data JSON por outline
- NO pasos numerados ni Faker
- NO creación de TCs
- SÍ estimación de cobertura (para PO)
- SÍ outline names + precondición de 1 línea
Status: "Refined — Awaiting PO Estimation"
El DRAFT es lo que hace la Story estimable. Lo diferido (datos, parametrización, pasos) lo añade /sprint-testing Stage 1 como un superset de este archivo.
El ATP DRAFT = shift-left-refinement.md. La frontera con el ATP completo: outline NAMES only, sin test data/parametrización/TCs. La estimación de cobertura SÍ va (alimenta a PO).
el dato que estima PO
Estimación de Cobertura
| Tipo | Count | Notas |
|---|
| Positive | 4 | variantes del happy path |
| Negative | 5 | inputs inválidos, no autorizado, campos faltantes |
| Boundary | 2 | min/max/empty/null/unicode |
| Integration | 1 | por punto de integración |
| Total | 12 | (maneja la estimación de PO) |
Muestra el 0, no lo escondas
La tabla debe mostrar 0 en los tipos vacíos. Los ceros ocultos sesgan la estimación de PO. El conteo por tipo es lo que convierte el refinamiento en story points defendibles.
La estimación de cobertura es el puente con la estimación de PO. Siempre incluir la tabla, incluso con tipos en 0 — los ceros ocultos sesgan los puntos.
la máquina de estados
El Handoff — Backlog → Estimation
Backlog
— analyze →
Shift-Left QA
— estimate →
Estimation ✓
⊘
Ready For Dev
Escribe a Jira
ACs refinados al campo · ATP DRAFT al custom field · sección "QA Refinements" en la descripción (append, nunca overwrite).
Notifica
1 comentario de handoff con @PO / @Dev (solo si el handle está en project.yaml).
Transiciona
analyze → estimate. Si ya pasó estimation: log warning + SKIP (el refinamiento igual aterriza).
Guardrail: NUNCA más allá de Estimation
PO + Dev lead son dueños de estimate → ready_for_dev. Shift-left para en estimation — la Story queda lista para que el equipo le ponga puntos.
Máquina de estados: backlog→(analyze)→shift_left_qa→(estimate)→estimation. Guardrail duro: nunca past estimation. Descripción se hace append, nunca overwrite.
trabajo hecho una vez, reutilizado
Los Labels y el Short-Circuit
shift-left-reviewed
El marcador suave. /sprint-testing Stage 1 lo lee para saber que el refinamiento pre-sprint ya ocurrió.
shift-left-{YYYY-MM-DD}
El marcador de frescura. Si <30 días, el refinamiento se considera vigente y se puede short-circuitar.
→
Cuando la Story llega a Ready For QA…
/sprint-testing detecta el label, salta las Phases 1-3 (ya hechas), valida que los ACs sigan vigentes, y añade lo diferido (datos, parametrización, pasos) como un superset.
Esta es la economía del shift-left
El refinamiento se hace una vez, pre-sprint, y se reutiliza in-sprint — no se repite. El costo de calidad se paga en la fase 1×, no en la 10×.
Dos labels: reviewed (soft marker) + dated (freshness). Juntos permiten a sprint-testing saltar Phases 1-3. Esa reutilización ES el payoff económico del shift-left.
qué sale de la sesión
Entregables — por Story y por Batch
Por Story
- shift-left-refinement.md (working file)
- ACs refinados al campo de Jira
- ATP DRAFT al custom field
- Preguntas a PO (bloquean) + a Dev
- 2 labels + transición a estimation
Por Batch (sesión)
- batch-report.md
- Preguntas críticas a PO dedupeadas (rankeadas por cuántas Stories bloquean)
- Distribución de riesgo (LOW/MED/HIGH)
- Blockers de feasibility de datos
- Orden recomendado de sprint planning
El batch report va al épico padre
Si todas las Stories comparten un épico, el reporte se postea como comentario ahí. Nunca en cada Story — eso es ruido.
Por Story: refinement.md + Jira updates + labels + transición. Por sesión: batch report con preguntas dedupeadas, distribución de riesgo y orden de planning. Al épico, no a cada Story.
quiz · handoff
Artefactos & Handoff
Q1Una Story refinada está en estado Backlog. ¿Hasta dónde la transiciona el handoff?
AHasta Ready For Dev — lista para el sprint
BHasta Estimation (analyze → estimate) y para ahí — guardrail
CHasta QA Approved
Estimation. backlog → (analyze) → shift_left_qa → (estimate) → estimation. Guardrail duro: nunca más allá. PO + Dev lead son dueños de estimate → ready_for_dev; ellos le ponen los puntos.
Q2¿Para qué sirve el label shift-left-reviewed cuando la Story llega luego a Ready For QA?
AEs decorativo — solo marca que QA la vio
BDeja que /sprint-testing salte las Phases 1-3 — el trabajo se reutiliza, no se repite
CBloquea que la Story entre al sprint
Short-circuit. /sprint-testing Stage 1 lo detecta y salta las Phases 1-3 de planning (ya hechas pre-sprint). Esa reutilización es la economía del shift-left: refinas una vez en la fase 1×, no repites en la 10×.
Guardrail (para en estimation) y el short-circuit (el label permite reutilizar el trabajo in-sprint). Las dos claves del handoff.
nunca hagas esto
Anti-Patrones del Shift-Left
- L1 · No fuerces preguntas para llenar checklist. Story limpia = lista vacía válida.
- L2 · No saltes el label shift-left-reviewed al transicionar — rompe el short-circuit.
- L3 · No mezcles bugs con Stories en el batch. Solo Stories.
- L5 · No transiciones a Estimation sin un ATP DRAFT poblado — sin él, PO estima a ciegas.
- L4 · No escribas ADF a mano — Markdown local, deja que la conversión md-to-ADF actúe.
- L6 · No refines >12 Stories por sesión — la calidad y la atención colapsan.
- L7 · No preguntes lo que el AC ya responde — la banda del lector es el recurso más escaso.
- Guardrail · No avances más allá de Estimation — PO/Dev son dueños de estimar.
Los anti-patrones L1-L7 + el guardrail. L1 (no forzar preguntas) y L5 (ATP poblado antes de estimar) son los más load-bearing.
el checklist del refinador
Cómo Hacerlo Bien
- Veto antes que score — dinero/auth/datos/integraciones se fuerzan a full.
- Recorre arquetipos, no preguntes al azar — cada Story toca 2-3.
- Cita el contexto en vez de preguntar lo ya documentado.
- Etiqueta cada gap a su técnica (BVA/State/Decision/Pairwise).
- Marca lo inferido con NEEDS PO/DEV CONFIRMATION.
- Clasifica con juicio — Critical (bloquea PO) vs Edge (no bloquea).
- Incluye la estimación de cobertura — alimenta los story points.
- Calidad > cantidad — una pregunta real vale más que diez de relleno.
La meta
Que PO + Dev lleguen al sprint planning con ACs sin ambigüedad, riesgos visibles y una Story estimable — para que Dev construya lo correcto a la primera.
El checklist operativo del CÓMO hacerlo bien. Cada punto es una palanca de calidad del refinamiento.
por qué en TODO proyecto
Por Qué Cada Proyecto lo Necesita
1×
costo en requisitos
la fase más barata para matar un defecto — donde shift-left actúa
~70%
trabajo reutilizado
la lógica de refinamiento se reusa in-sprint, no se repite
0
preguntas forzadas
solo riesgo real — una Story limpia sale limpia
No es solo para proyectos grandes
Cualquier proyecto con requisitos tiene ambigüedades, huecos y ACs no testeables. Shift-left los convierte en preguntas baratas antes de que sean defectos caros. El ROI es estructural: horas de refinamiento vs semanas de retrabajo.
Cierre del POR QUÉ que pidió el usuario: el costo 1× vs 100×, la reutilización del 70%, y que aplica a todo proyecto (no solo grandes). El ROI es estructural.
para llevar
Tres Ideas que se Quedan
1
Prevenir, no detectar
QA entra en los requisitos, no al final. Un AC ambiguo es un defecto esperando. Costo 1× vs 100×.
2
El corazón es el refinamiento
Ambigüedades, huecos, edge cases, testabilidad. El banco de preguntas como rúbrica — calidad > cantidad.
3
Entrega que se reutiliza
ATP DRAFT estimable + labels que dejan al sprint saltar el trabajo ya hecho. Una vez, no dos.
Los tres conceptos núcleo: prevención (porqué), refinamiento (cómo), handoff reutilizable (la economía).
Mueve la Calidad a la Izquierda.
Selecciona por riesgo → refina el corazón (ambigüedades, huecos, el banco de preguntas) → entrega un ATP DRAFT estimable que el sprint reutiliza. Previene el defecto donde cuesta 1×, no donde cuesta 100×.
← → navegar · S notas del orador · O resumen · T tema
Cierra atando porqué + cómo. Shift-left no es una ceremonia extra: es la inversión más barata en calidad que un proyecto puede hacer.