INVEST: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Meta-bok|min=4}} | |||
'''INVEST''' es un método para verificar la calidad de una [[Historia de usuario|historia de usuario]] revisando que cumpla seis características: Independiente, Negociable, Valiosa, Estimable, Pequeña y Comprobable. Fue desarrollado por Bill Wake en 2003 y popularizado por Mike Cohn en ''User Stories Applied'' (2004). Su objetivo es asegurar que las historias sean claras, manejables y capaces de entregar valor de forma efectiva. | |||
Fue desarrollado por Bill Wake en 2003 | |||
== Las seis características == | |||
== | |||
=== Independent — Independiente === | |||
=== | |||
Cada historia de usuario debe poder planificarse e implementarse en cualquier orden, sin depender de otra historia. Las dependencias entre historias reducen la flexibilidad del equipo para priorizar y aumentan la complejidad de la planificación. Cuando las dependencias son inevitables, pueden reducirse combinando historias o dividiéndolas de forma diferente. | |||
=== Negotiable — Negociable === | |||
=== | |||
Una | Una historia de usuario es una descripción corta de una necesidad, no un contrato cerrado. Los detalles se acuerdan en la conversación entre el equipo y el propietario del producto durante la planificación o el refinamiento. Una historia con demasiados detalles predefinidos limita esa conversación y reduce su utilidad. | ||
=== Valuable — Valiosa === | |||
=== | |||
La historia | La historia debe aportar valor al cliente o al usuario. Una práctica que fomenta el valor es que las historias las escriban los propios usuarios o el propietario del producto, no el equipo técnico. | ||
== | === Estimable — Estimable === | ||
El equipo debe poder estimar el tamaño de la historia con suficiente precisión para priorizarla y planificarla. Si no puede estimarse, suele indicar que la historia está mal definida o que el equipo carece del conocimiento necesario para implementarla. | |||
== | === Small — Pequeña === | ||
== | Las historias deben ser lo suficientemente pequeñas para completarse en pocas semanas por una persona —idealmente en días—. Una descripción corta ayuda a mantener el tamaño controlado. Las historias demasiado grandes son [[Epic|épicas]] que necesitan dividirse. | ||
*[[ | === Testable — Comprobable === | ||
La historia debe poder probarse: deben existir [[Criterios de aceptación|criterios de aceptación]] claros que determinen cuándo está terminada. Si el propietario del producto no sabe cómo probarla, es señal de que la historia no está suficientemente clara o no es suficientemente valiosa. | |||
== Beneficios == | |||
* Mejora la comunicación: las historias INVEST son más claras y comprensibles para todo el equipo. | |||
* Facilita la estimación: las historias pequeñas y bien definidas son más predecibles. | |||
* Contribuye a la entrega continua de valor: las historias independientes y valiosas son las que generan incrementos útiles al final de cada sprint. | |||
== Desafíos == | |||
* Dividir historias grandes en partes independientes y valiosas puede ser complejo. | |||
* El propietario del producto y los usuarios pueden necesitar orientación para escribir historias que cumplan los criterios. | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Usar INVEST como lista de verificación burocrática.''' INVEST es una guía para la conversación, no un formulario de calidad. Si el equipo revisa mecánicamente cada criterio sin debatir el significado de cada historia, pierde el valor principal de la herramienta. Una historia que no supera INVEST es una señal para conversar más, no para rechazarla automáticamente. | |||
</div> | |||
== Referencias == | |||
* Wake, Bill. (2003). "INVEST in Good Stories, and SMART Tasks". XP123. | |||
* Cohn, Mike. (2004). ''User Stories Applied: For Agile Software Development''. Addison-Wesley. | |||
== Véase también == | |||
<div class="bok-tags"> | |||
[[Historia de usuario]] [[Criterios de aceptación]] [[Epic]] [[Backlog refinement]] [[A punto]] [[Planificación del sprint]] | |||
</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:Estimación]] | [[Category:Estimación]] | ||
[[Category:Prácticas ágiles]] | [[Category:Prácticas ágiles]] | ||
[[Category:Standard scrum]] | [[Category:Standard scrum]] | ||
Revision as of 13:33, 15 May 2026
INVEST es un método para verificar la calidad de una historia de usuario revisando que cumpla seis características: Independiente, Negociable, Valiosa, Estimable, Pequeña y Comprobable. Fue desarrollado por Bill Wake en 2003 y popularizado por Mike Cohn en User Stories Applied (2004). Su objetivo es asegurar que las historias sean claras, manejables y capaces de entregar valor de forma efectiva.
Las seis características
Independent — Independiente
Cada historia de usuario debe poder planificarse e implementarse en cualquier orden, sin depender de otra historia. Las dependencias entre historias reducen la flexibilidad del equipo para priorizar y aumentan la complejidad de la planificación. Cuando las dependencias son inevitables, pueden reducirse combinando historias o dividiéndolas de forma diferente.
Negotiable — Negociable
Una historia de usuario es una descripción corta de una necesidad, no un contrato cerrado. Los detalles se acuerdan en la conversación entre el equipo y el propietario del producto durante la planificación o el refinamiento. Una historia con demasiados detalles predefinidos limita esa conversación y reduce su utilidad.
Valuable — Valiosa
La historia debe aportar valor al cliente o al usuario. Una práctica que fomenta el valor es que las historias las escriban los propios usuarios o el propietario del producto, no el equipo técnico.
Estimable — Estimable
El equipo debe poder estimar el tamaño de la historia con suficiente precisión para priorizarla y planificarla. Si no puede estimarse, suele indicar que la historia está mal definida o que el equipo carece del conocimiento necesario para implementarla.
Small — Pequeña
Las historias deben ser lo suficientemente pequeñas para completarse en pocas semanas por una persona —idealmente en días—. Una descripción corta ayuda a mantener el tamaño controlado. Las historias demasiado grandes son épicas que necesitan dividirse.
Testable — Comprobable
La historia debe poder probarse: deben existir criterios de aceptación claros que determinen cuándo está terminada. Si el propietario del producto no sabe cómo probarla, es señal de que la historia no está suficientemente clara o no es suficientemente valiosa.
Beneficios
- Mejora la comunicación: las historias INVEST son más claras y comprensibles para todo el equipo.
- Facilita la estimación: las historias pequeñas y bien definidas son más predecibles.
- Contribuye a la entrega continua de valor: las historias independientes y valiosas son las que generan incrementos útiles al final de cada sprint.
Desafíos
- Dividir historias grandes en partes independientes y valiosas puede ser complejo.
- El propietario del producto y los usuarios pueden necesitar orientación para escribir historias que cumplan los criterios.
Error frecuente
Usar INVEST como lista de verificación burocrática. INVEST es una guía para la conversación, no un formulario de calidad. Si el equipo revisa mecánicamente cada criterio sin debatir el significado de cada historia, pierde el valor principal de la herramienta. Una historia que no supera INVEST es una señal para conversar más, no para rechazarla automáticamente.
Referencias
- Wake, Bill. (2003). "INVEST in Good Stories, and SMART Tasks". XP123.
- Cohn, Mike. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
Véase también
¿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.