{"id":9205,"date":"2022-02-07T10:08:40","date_gmt":"2022-02-07T10:08:40","guid":{"rendered":"https:\/\/www.cybermedian.com\/es\/?p=9205"},"modified":"2026-04-20T09:12:27","modified_gmt":"2026-04-20T09:12:27","slug":"como-escribir-una-historia-de-usuario-efectiva-con-los-principios-invest","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/es\/how-to-write-effective-user-story-with-invest-principles\/","title":{"rendered":"\u00bfC\u00f3mo escribir una historia de usuario efectiva con los principios INVEST?"},"content":{"rendered":"

Principio INVEST para crear historias de usuarios<\/span><\/h3>\n

Adem\u00e1s de un formato estandarizado y elementos completos, una buena\u00a0historia de usuario<\/a>\u00a0tambi\u00e9n debe seguir los principios de\u00a0INVEST<\/strong>\u00a0: 1.\u00a0Yo<\/strong>\u00a0dependiente;\u00a02.\u00a0N<\/strong>\u00a0egociable;\u00a03.\u00a0Valioso<\/strong>\u00a0;\u00a04.\u00a0Estimable<\/strong>\u00a0;\u00a05.\u00a0Peque\u00f1o<\/strong>\u00a0;\u00a06.\u00a0T<\/strong>\u00a0estable.<\/p>\n

<\/p>\n

1.\u00a0Independiente<\/strong>\u00a0: es importante que una historia de usuario sea lo m\u00e1s independiente posible de las otras historias de usuario.\u00a0Mantener la independencia entre las historias de los usuarios no solo facilita la priorizaci\u00f3n y la alineaci\u00f3n, facilita la planificaci\u00f3n de versiones e iteraciones, facilita la comprensi\u00f3n independiente, el seguimiento, la implementaci\u00f3n, las pruebas y la entrega frecuente, sino que tambi\u00e9n hace que el alcance de la estimaci\u00f3n del tama\u00f1o de la historia del usuario sea m\u00e1s claro y, por lo tanto, el sesgo de estimaci\u00f3n. menor.<\/p>\n

2.\u00a0Negociable<\/strong>\u00a0: el contenido de una historia de usuario es negociable;\u00a0una historia de usuario no es un contrato.\u00a0Una historia de usuario es solo una breve descripci\u00f3n de la historia de usuario sin muchos detalles;\u00a0los detalles espec\u00edficos se producen durante la fase de comunicaci\u00f3n.\u00a0Una historia de usuario con demasiados detalles en realidad limita al usuario, las ideas y la comunicaci\u00f3n del equipo.<\/p>\n

3.\u00a0Valioso<\/strong>\u00a0: cada historia debe ser valiosa para el cliente (ya sea un usuario, un comprador o un rol interno de la empresa).\u00a0Las historias de usuario son valiosas para el usuario final, por lo que deben escribirse desde la perspectiva del usuario, describiendo una CARACTER\u00cdSTICA en lugar de una TAREA.<\/p>\n

Esta caracter\u00edstica facilita un cambio del estilo de trabajo tradicional basado en directivas a un estilo de trabajo autodirigido y orientado al valor para los miembros del equipo de desarrollo y pruebas, de modo que todos en el equipo conozcan el valor del trabajo que hacen todos los d\u00edas.<\/p>\n

4.\u00a0Estimable<\/strong>\u00a0(se puede evaluar): una parte muy importante dentro de la reuni\u00f3n de planificaci\u00f3n es la estimaci\u00f3n de los puntos de la historia.\u00a0En realidad, es una estimaci\u00f3n aproximada de la historia de usuario que se desarrollar\u00e1 para que el equipo pueda conocer la complejidad (carga de trabajo) de esta historia de usuario.<\/p>\n

La atenci\u00f3n se centra en si la historia de usuario se puede completar en la iteraci\u00f3n actual de acuerdo con las condiciones de recepci\u00f3n de esa historia de usuario y los DoD (criterios de finalizaci\u00f3n) definidos por el equipo, y si no se puede completar, se da el motivo y el PO decide si dividir o redise\u00f1ar la historia de usuario.<\/p>\n

Los problemas que dificultan que los desarrolladores calculen la historia provienen de: falta de conocimiento del dominio (en cuyo caso se necesita m\u00e1s comunicaci\u00f3n) o la historia es demasiado grande (en cuyo caso se debe cortar en partes m\u00e1s peque\u00f1as).<\/p>\n

5.\u00a0Peque\u00f1a<\/strong>\u00a0: una buena historia debe ser lo m\u00e1s corta posible en t\u00e9rminos de carga de trabajo, preferiblemente no m\u00e1s de 10 personas ideales por d\u00eda, al menos para garantizar que se complete en una iteraci\u00f3n.\u00a0Cuanto mayor sea la historia de usuario, mayor ser\u00e1 el riesgo en la programaci\u00f3n, la estimaci\u00f3n de la carga de trabajo, etc.<\/p>\n

6.\u00a0Comprobable<\/strong>\u00a0(comprobable): una historia de usuario debe ser comprobable para confirmar que se puede completar.\u00a0Si una historia de usuario no se puede probar, entonces no puede saber cu\u00e1ndo se completar\u00e1.\u00a0Un ejemplo de una historia de usuario no comprobable: el software debe ser f\u00e1cil de usar.<\/p>\n

Tres Directrices<\/span><\/h3>\n

Una historia de usuario es b\u00e1sicamente una buena historia de usuario cuando se siguen los principios de INVEST.\u00a0Luego nos enfocamos en tres pautas para ayudar a cumplir mejor con los principios al producir historias de usuarios.<\/p>\n

Las tres pautas son: un usuario, valor completo y sin dependencia.<\/p>\n

1.\u00a0Un tipo de usuarios<\/strong>\u00a0: incluya solo un tipo de usuarios, ya que varios usuarios suelen tener matices.\u00a0Por lo general, es un usuario t\u00edpico, a menudo con una necesidad com\u00fan de alg\u00fan tipo.<\/p>\n

2.\u00a0Valor completo<\/strong>\u00a0: brinde valor al cliente en su totalidad.\u00a0Una historia de usuario completa significa que cuando esta historia est\u00e1 completa, el usuario puede alcanzar un objetivo claro y significativo.<\/p>\n

3.\u00a0No dependencia<\/strong>\u00a0: los tres tipos comunes de dependencias son: superposici\u00f3n, secuencia y contenci\u00f3n.<\/p>\n

En general, se debe evitar la superposici\u00f3n de puntos funcionales entre pisos;\u00a0las relaciones secuenciales son una realidad y pueden resolverse por alg\u00fan medio en la mayor\u00eda de los casos;\u00a0y las relaciones de inclusi\u00f3n son \u00fatiles para sistemas complejos, con implicaciones para programar versiones y planes de iteraci\u00f3n que necesitan atenci\u00f3n.<\/p>\n

Dependencias superpuestas<\/strong><\/p>\n

Las dependencias superpuestas son la forma de dependencias que causan m\u00e1s problemas, especialmente cuando varias historias de usuario contienen varias partes superpuestas diferentes.\u00a0Es dif\u00edcil encontrar un conjunto de historias de usuarios que puedan representar el conjunto de funciones para ese producto m\u00ednimo viable, que debe contener y solo contener las funciones necesarias una vez.<\/p>\n

Soluci\u00f3n<\/strong><\/p>\n

Elimina las partes superpuestas como historias de usuario separadas.
\nDivisi\u00f3n racional de las historias de usuario y mantenimiento de las superposiciones en solo una de las historias de usuario m\u00e1s cohesivas.
\nUsa el modelo de desarrollo Scrum.<\/p>\n

Dependencias secuenciales<\/strong><\/p>\n

La dependencia secuencial significa que para que se complete una historia de usuario, se deben completar una o m\u00e1s historias de usuario antes.\u00a0Las dependencias secuenciales suelen ser inofensivas y existen formas de mitigar dichas dependencias.<\/p>\n

Desde una perspectiva de desarrollo \u00e1gil, todo el sistema evoluciona gradualmente desde un producto viable m\u00ednimo inicial hasta un producto robusto, y cada paso posterior se basa en los anteriores.<\/p>\n

Pero desde otra perspectiva, las dependencias secuenciales innecesarias dificultan la clasificaci\u00f3n y la priorizaci\u00f3n, lo que a su vez afecta el desarrollo de los planes de lanzamiento e iteraci\u00f3n y dificulta la estimaci\u00f3n del tama\u00f1o de las historias de usuario.<\/p>\n

Soluci\u00f3n<\/strong><\/p>\n

Haga que las historias de usuario dentro de una iteraci\u00f3n est\u00e9n lo m\u00e1s libres posible de dependencias intr\u00ednsecas.
\nMantener solo dependencias unidireccionales entre iteraciones, con solo dependencias unidireccionales en el tiempo desde historias en iteraciones posteriores hasta historias en iteraciones anteriores (dependencias hacia adelante).
\nEliminar las dependencias centrales como historias separadas y no mezclar requisitos dependientes y no dependientes en una sola historia.<\/p>\n

Inclusi\u00f3n de dependencias<\/strong><\/p>\n

Las dependencias contenidas se refieren al uso de la gesti\u00f3n jer\u00e1rquica en la organizaci\u00f3n de historias de usuario, como la gesti\u00f3n com\u00fan de dos niveles de historias de caracter\u00edsticas, donde una caracter\u00edstica contiene varias historias de usuarios, lo que constituye una dependencia contenida de la caracter\u00edstica en sus historias subordinadas.<\/p>\n

Soluci\u00f3n<\/strong><\/p>\n

El nivel de historia de usuario se usa para la planificaci\u00f3n de iteraciones, evitando la planificaci\u00f3n de iteraciones de granularidad gruesa con el nivel de caracter\u00edsticas, que se puede usar para la planificaci\u00f3n de versiones.<\/p>\n

El nivel de funci\u00f3n tambi\u00e9n se puede dividir hasta que alcance el nivel de una funci\u00f3n comercializable m\u00ednima, y \u200b\u200blas historias de usuario que contiene se pueden agrupar por separado en las funciones reci\u00e9n divididas.<\/p>\n

Siguiendo el concepto de producto m\u00ednimo viable, una caracter\u00edstica se implementa en m\u00faltiples iteraciones de m\u00faltiples historias de usuarios, cada una de las cuales puede resultar en un producto potencial o proporcionar comentarios internos o externos.<\/p>\n

 <\/p>\n

Referencias<\/p>\n