Agile: ¿Qué es y cómo surgió?

¿Qué es Ágil y cómo surgió? A continuación les comparto un video que hice para explicar lo más simple posible y en no más de 5 min.

Referencia:
https://agilemanifesto.org/

Libro: Scrum en las organizaciones

Comparto por este medio el libro que escribí sobre “Scrum en las Organizaciones”. Con este libro comparto una guía para trabajar bajo el marco de trabajo Scrum y para gestionar proyectos de Ingeniería de Software en forma ágil.

Este libro ofrece una guía para el conocimiento e implementación de una manera de trabajar y de gestionar proyectos de Ingeniería de Software, permitiendo encontrar prácticas emergentes en dominios complejos. En él se explica el sistema Scrum de un modo integrador desde diferentes perspectivas y fuentes de conocimiento, proporcionando un marco integral que incluye a los principios filosóficos, estructura, procesos y aspectos complementarios. 

Con este libro se busca ayudar a los equipos a avanzar de intentar emplear Scrum a ejecutarlo correctamente para lograr alcanzar los resultados que aún no se han logrado.

También busca ser una guía y ayuda para quienes se desenvuelven como Scrum Master de equipos de desarrollo de software.

Referencias:

• Amazon en papel pasta blanda.
• Amazon Kindle.

Agilismo: Cómo ser ágiles

¿Cómo ser ágiles?

Este artículo es un documento donde se analiza cómo se puede fomentar la agilidad (en el contexto de marcos de trabajo ágil y/o desarrollo de software) y cómo se puede ser ágil en forma consciente en una organización, las acciones necesarias para poder lograrlo y una vía simple de contagiar la agilidad.

Introducción

Trabajando en una organización, en la cual los integrantes dicen ser ágiles e implementar algún marco de trabajo como Scrum, cabe preguntarse a modo de reflexión lo siguiente: ¿Nuestra organización es realmente ágil? ¿Somos realmente ágiles?

Para ello podemos preguntar, en cualquier momento y a personas tomadas al azar, si saben cuáles son los valores ágiles. Pues si no tienen la más remota idea o no los recuerdan, podemos comenzar a pensar que algo puede andar mal, en principio darle camino a la duda.

Si sospechamos, de algún modo, que no somo ágiles, también podemos preguntarnos por qué no… ¿Cómo ser ágiles? ¿Cómo contagiar la agilidad al resto de la organización?

Hay muchas maneras de llegar a ser ágiles, aunque hay una relevante que es la que se expone aquí: partir de nuestra forma de pensar.

 
Valores

La agilidad se construye en base a sus valores cimientos y estos son cualidades que consideramos valiosas o deseables tener en cuenta.

"To be agile, you need to adhere to the Agile Manifesto…

As long as you're sticking to the Agile Manifesto's values and principles and delivering high-value software regularly to your customers, you should be considered Agile." [Stephen Haunts 2015]

Un valor es lo que tu pones delante de otra cosa cuando decides algo [Sergio Fernandez 2014]. No es difícil tomar decisiones cuando sabemos cuales son nuestros valores (Roy Disney). Por tal motivo, si somos conscientes de nuestros valores ágiles tomaremos decisiones alineadas a ellos. Nuestros valores tienen una gran determinación sobre nuestros resultados. En consecuencia, nuestra praxis ágil dependerá de nuestra mentalidad, de nuestro

Desde esta perspectiva, para buscar ser ágiles debemos buscar ser conscientes de sus valores y tenerlos en presente en el día a día. Debemos reflexionar si en el trabajo diario actuamos acorde a ellos, si estamos convencidos de sus fundamentos, si comprendemos su alcance y cómo los aplicamos cuando resolvemos problemas o hacemos nuestra labor diaria.

Valores Ágiles

Los valores ágiles expresados en el manifiesto ágil reordenados son los siguientes:

Individuos e interacciones, sobre procesos y herramientas.
Colaboración con el cliente, sobre negociación contractual.
Respuesta ante el cambio, sobre seguir un plan.
Software funcionando sobre, documentación extensiva.

Suele resultar dificil memorizar la lista de valores. Para lograrlo, se puede recurrir a un mantra simple y/o nemotécnico.

 
Mantra

En vez de recordar cuatro oraciones se nos puede hacer más fácil recordar solo una, un mantra. En un artículo de una revista conocida, decía una frase: «La belleza de un mantra es que todos esperan que sea breve y dulce» (Guy Kawasaki). Aunque, más que breve y dulce, un mantra es una especie de faro para guiarnos. Es un lema de alto nivel que representa un ideal como objetivo guía y motivación. Y la agilidad no es otra cosa que un ideal a seguir.

El que se puede elegir como opción para guiarnos en el camino de la agilidad es el siguiente:

"Me relaciono, colaborando, como agente de cambio, para que las cosas funcionen mejor"

Aquí las palabras claves son: relaciono, colaborando, cambio y funcionen. Cada palabra se corresponde con un valor ágil en forma re-ordenada. A continuación podemos explicar el mantra.

 

Me relaciono

Relacionarse simboliza priorizar a individuos e interacciones. Si se aspira a una organización democrática en el que prevalecen las relaciones humanas en vez de los procesos y herramientas, las personas son absolutamente centrales y completamente imprescindibles; donde la impronta de cada individuo deja su aporte al sistema organizacional y no se subordina totalmente a los procesos del sistema. Esto favorece a lograr una organización orgánica y adaptable, y no a una mecánica y rígida.

Las empresas están formadas por humanos. Como dice Maturana, hay que reconocer que lo humano no se constituye exclusivamente desde lo racional. Es cierto que lo racional es importante en el tipo de vida que vivimos, pero el primer paso para revalorar la emoción sería aceptar que entrelazado a un razonar está siempre presente un emocionar. En el momento en que uno acepta la presencia de la emoción y amplía su mirada reflexiva se da cuenta de que la emoción es el fundamento de todo quehacer, el que lleva a la realización de la convivencia, a la realización del vivir con otro; esto solamente se puede dar en la medida en que la convivencia se hace en la aceptación del otro como un legítimo otro [Maturana 2004]. Esto fomenta lograr una organización creativa y colaborativa.

Maturana dice que el 99% de las enfermedades son consecuencia de la negación del amor (Maturana 2004). Con riesgo de sonar cursi, se puede decir que algo semejante sucede en las organizaciones empresariales. Pues, no somos máquinas, somos humanos, que trabajamos mejor si nos relacionamos humanamente con relaciones cordiales de confianza y de estas relaciones surge la libertad para cambiar a los procesos, para mejorarlos y trabajar mejor. Las personas deben estar a gusto para poder ser creativas, para hacer aportes productivos a los proyectos y a la organización. Esto ayuda a que las personas estén voluntariamente y fuertemente comprometidas con el éxito del producto, del proyecto y de la organización. Además, las personas felices trabajan mejor.

¿Cómo hacerlo?

• Proporcionar oportunidades para que las personas funcionen como seres humanos, en vez de que sean considerados recursos de un sistema.
• Motivar a las personas, darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. [Agilemanifesto 2001] Confiar en los miembros del equipo respecto a su forma de trabajo, por sobre juzgarlos y "medirlos" para control.
• Brindar ambientes que posibiliten la auto-organización de las personas y la asociación voluntaria en vez de aquellos que fomentan la jerarquía y la obediencia (Google recomienda eliminar símbolos de
• [Laszlo Bock 2015]). Conceda a las personas algo más de confianza, libertad y autoridad de la que a usted le resulta tranquilizador [Laszlo Bock 2015].
• Proporcionar oportunidades a cada miembro de la organización para que puedan desarrollar su potencial acordes a su individualidad y tengan un crecimiento profesional a la par de su persona (desarrollo integral).
• Formar ambientes donde las personas puedan reunirse en grupo para conversar y compartir.
• Facilitar sistemas participativos para que las personas se sientan tenidas en cuenta y de que sus decisiones sopesan.  Solicitar se respete las decisiones del equipo por sobre los procesos "pre-establecidos" cuando es necesario y justificado (Cambio en los integrantes del equipo, participación en las entrevistas, definición de "RoadMap", DoD, etc.).
• Desarrollar el liderazgo integrador donde la “la gente es lo primero”.
• Fomentar el cara a cara. Priorizar las conversaciones cara a cara en vez de las hechas por mail, chat o herramientas remotas. [Steve Jobs 2015][Agilemanifesto 2001]
• Priorizar las presentaciones sin dispositivas o con diapositivas minimalistas por sobre largas presentaciones formales y hacer los diálogos emocionales e integradores, que llegue a las personas. [Steve Jobs 2015]
• Preferir levantarse, buscar y preguntar sobre soluciones hechas por otros a reinventar la rueda en forma aislada.
• Facilitar herramientas que simplifiquen las conversaciones y aumenten la cohesión social.
• Considerar que los estándares y procesos no están escritos en piedra y brindar la posibilidad de que las personas aporten a su mejora.
• Permitir libertad razonable de horarios en vez de perseguir respetar jornadas estrictas de trabajo. La libertad razonable de horarios debe ser acordada en “bandas horarias”  [UNTREF, 2014] funcionales al equipo y a la organización.
• Hay que respetar el trabajo "
• ", haciendo el desarrollo en las jornadas que corresponden, condiciones que corresponden y la paz necesaria, pues el trabajo extra desgasta a las personas y perjudica su vida extralaboral.
• No usar “argumentum ad hominem” o “falacia de ataque a las persona” en las discusiones. No buscar convencer o desacreditar las opiniones de las personas por su condición jerárquica, su rol, su aptitud o su actitud personal. Buscar discutir ideas.
• No comunicar decisiones que repercuten en la vida de las personas sin la previsión necesaria. En este sentido hay que brindar transparencia para generar confianza.
• Motorización de la "felicidad" de los miembros del equipo o de la organización.

 
Colaborando

Se busca la colaboración con el cliente sobre negociación contractual. Siendo extensible al resto de la organización y suponiendo que en cualquier relación de trabajo existe un cliente y un proveedor, buscamos que exista colaboración entre los mismos. Antes de priorizar un contrato o lo previamente establecido como lo que cada parte debe cumplir, se debe buscar colaborar. Nuestros clientes deberían ser nuestro punto de contacto principal, nuestro compañero de trabajo con el que nuestro accionar conjunto fluye en vez de ser frenado por fricciones burocráticas o contractuales.

 
¿Cómo hacerlo?

• Compartir información y experiencias, y brindar los medios para que todos lo puedan hacer.
• Plantear negociaciones ganar-ganar. Pues llevar a cabo una estrategia basada en la cooperación ganar-ganar debería ser mucho más que una actitud ante circunstancias específicas, debería ser una forma de relacionarse colaborando.
• Hacer frecuentes reuniones técnicas en equipo. Los diseños deben ser emergentes desde la colaboración en equipo y no desde la anarquía grupal o de la mente de un iluminado esperto. También hacer frecuentes reuniones estrategias y tácticas.
• Fomentar el liderazgo democrático y facilitar sistemas democráticos para la toma de decisiones.
• Colaborar y coordinar con otros equipos para desarrollar componentes o soluciones transversales, en vez de resolver solo nuestros problemas funcionales a nuestras aplicaciones o a nuestra área en forma aislada. Desde el punto de vista del desarrollo, hay que tomarse un tiempo cada vez que tengamos que implementar algo, tratar dentro de lo posible de mirar hacia el lado, conversar con alguien, ver si lo que estamos haciendo tiene calidad, por ejemplo si puede ser reutilizado, si no deja deuda técnica o simplemente si existe una forma mejor de hacerlo.
• El cliente debe estar presente colaborativamente en el equipo. En equipos Scrum el PO debe tener dedicación, en lo posible, exclusiva al equipo. Debemos tener presente a nuestros clientes internos y a las personas que les servimos para que realmente les sirvamos.
• Buscar la ayuda temprana ante problemas. Poseer un sistema de "alarma" interna cuando alguien está bloqueado o entrampado con un tema.

 

Como agentes de cambio

El cambio parece ser la única constante en nuestras vidas y aunque no sea del todo bienvenido debemos estar abiertos a él. Ser agentes de cambio es lograr respuestas ágiles ante el cambio sobre seguir un plan. Con este valor buscamos, en general, priorizar la flexibilidad para la adaptación a cambios en vez de la rigidez de seguir un plan detallado, seguir documentación, o reglas y estructuras rígidas. Debemos buscar que la organización sea orgánica y dinámicamente flexible, adaptándose constantemente y no una automata mecánica que sigue una programación previa detallada. Además, no bastaría con ser aptos al cambio, aceptarlo y ser reactivos, sino que también hay que ser pro-activos. Debemos ser agentes de cambio, ser agentes de nuevas posibilidades, de que las cosas ocurran, facilitadores del proceso de cambio hacia una cultura ágil y de que el nuevo status quo ágil suceda.

¿Cómo hacerlo?

• Buscar que se cumplan los valores anteriores. Tener la capacidad de relacionarse en forma efectiva con las personas de la organización y los participantes en el proceso de cambio, debe crear un clima de confianza, apertura, respeto y colaboración entre todos los participantes [García López 2010].
• Buscar cómo se puede lograr el aumento de la eficacia de la organización en toda sus metas [García López 2010]. Proponer ideas, cambios y mejoras a los producto como a los procesos y políticas de la compañía.
• Escuchar a las personas y comprenderlas aún cuando no esté de acuerdo con ellas para vencer la resistencia al cambio [García López 2010].
• Diagnosticar situaciones y comportamientos que estén provocando problemas a la organización, o simplemente ver oportunidades de mejorar [García López 2010]. Levantar riesgos a las "noticias" o "decisiones" que se nos imponen y qué cosas obstaculizan la agilidad.
• Confrontar a personas o grupos, proporcionándoles retroinformación constructiva para que acepten, adopten e impulsen el cambio y no lo obstruyan [García López 2010].
• Sugerir soluciones y orientar acciones para desarrollar las organizaciones [García López 2010].
• Reorganizarse como equipo frente a cambios o problemas antes que esperar que nos digan qué y cómo enfrentarlos. Ser proactivo como equipo.
• Asegurar que las retrospectivas o reflexiones grupales de mejora contínua tengan acciones que se cumplan y no sean solo momentos de terapia o conversaciones de resultados estériles en el futuro.
• Involucrarse en las prácticas de otros equipos que no aparentan ser ágiles e intentar generar nexos que mejoren la comunicación con ellos en prácticas ágiles; y compartirles experiencias motivadoras.

• Buscar ser abiertos de mente y ser aptos para la adaptación a otras maneras de pensar o puntos de vista. Para ello no hay que tener miedo al conflicto, hay que lograr una aceptación del "conflicto positivo".

• Experimentar buscando la mejora por sobre preferir hacer lo que veníamos haciendo.
• Buscar que la organización sea inteligente, una organización que aprenda. Los mejores deben enseñar al resto [Laszlo Bock 2015].

Para hacer que las cosas funcionen mejor

Hacer que las cosas funcionen deriva de software funcionando sobre documentación extensiva. Este valor indica que hay que estar orientado al producto o focalizarse en él y de este modo requerir un incremento de producto completado y funcionando como resultado final de cada ciclo de trabajo, en vez de tener que cumplir con grandes y engorrosas documentaciones, protocolos y estándares o formalismos burocráticos. El producto concreto y funcionando es lo que permite a la organización guiarse hacia el éxito. Y esto se puede extender a cualquier producto, cualquier objetivo entregable o subsistema dentro de la organización y no solo al software. Lo clave es que lo que importa es que las cosas funcionen, que los procesos funcionen, que el sistema funcione y que nuestros resultados sean funcionales. Además, con que funcionen no es suficiente, deben hacerlo cada vez mejor; como un proceso evolutivo. El mero acto de hacer que las cosas sucedan es lo que crea el cambio y por lo tanto es garantía de éxito como agentes de cambio dentro de una organización.

¿Cómo hacerlo?

• Buscar entregar valor en forma frecuente a nuestros clientes (o a todas las personas que laboralmente esperan algo de nosotros) y recibir retroalimentación constante de ello. Evaluar constantemente si lo que estamos haciendo o entregando aporta valor, desde la revisión de un estándar hasta la refactorización de código.
• No trabajar bajo demanda o esperar que los demás nos contacten, que sigan los procesos, lo pactado o los planes; en vez de ello, hay que ir a los demás para asegurarse de que las cosas funcionan. No hay que descansar en nuestra autoridad, en comunicados memos, en documentos o en la definición de procesos; sino que hay que actuar y hacer que las cosas sucedan.
• Buscar que las cosas fluyan, que los procesos fluyan. Resolver impedimentos y facilitar para que los procesos sean ágiles. Además, hay que hacer la vida fácil a las personas de la organización [Laszlo Bock 2015].
• Buscar el aumento de la eficacia de la organización en toda sus metas.
• Probar con usuarios, con el equipo o con el cliente; buscar el “feedback temprano” por sobre la investigación teórica para probar tempranamente el funcionamiento (del software, de diseños, de procesos, etc.).

Conclusión

Se puede concluir que una forma simple de buscar ser ágil es:

• En primera instancia, tener presente los valores ágiles. Para ello podemos recurrir a recordar un mantra como el que dice:  "Me relaciono, colaborando, como agente de cambio, para que las cosas funcionen mejor".
• Meditar frecuentemente sobre si nuestras acciones cotidianas están alineadas a ellos o a nuestro mantra ágil.
• Pensar en cómo podemos hacer para que lo que hacemos diariamente respete algún valor ágil.

Entonces, cuando decimos "soy Ágil", estamos diciendo que aceptamos y nos comprometemos con los valores ágiles (que conocemos), y que estamos avanzando en esa dirección [Walter Bodwell 2009].

Siendo ágil contagiamos la agilidad, además lo hacemos compartiendo nuestro mantra con los demás.

Nota final

Recordar que para ser realmente ágiles también hay que aplicar los doce principios ágiles que se desprenden de los valores ágiles y que están en el manifiesto ágil [Agilemanifesto 2001], aunque estos 12 principios no fueran tratados en este artículo; y aplicar un marco o proceso ágil de trabajo (Scrum, XP, Lean kanban, etc.).

También hay que tener en cuenta que tanto los valores como los principios no son exclusivos de desarrolladores, programadores, Team Members, o; sino que se pueden hacer extensibles a cualquier rol dentro de la organización. Cualquier persona que desarrolla cualquier rol en nuestra compañía puede ser ágil.

Referencia:

[Agilemanifesto 2001] Agilemanifesto.org, 2001.

[UNTREF, 2014] UNTREF (2014). Construcción de software: una mirada ágil. Por Nicolás Paez, Diego Fontdevila, Pablo Suárez, Carlos Fontela, Marcio Degiovannini, Alejandro Molina. Universidad Nacional de Tres de Febrero (UNTREF).

[Stephen Haunts 2015] Agile Software Development Succinctly By Stephen Haunts Foreword by Daniel Jebaraj. 2015 by Syncfusion, Inc. Courtney Wright.

[Maturana 2004] Transformación en la convivencia. Humberto Maturana, 2004.

[Steve Jobs 2015] Lecciones de liderazgo. Walter Isaacson, 2015.

[Sergio Fernandez 2014] El nuevo paradigma laboral. Sergio Fernández, 2014.

[García López 2010] El agente de cambio organizacional: su rol y propósitos, García López, J.M., en Contribuciones a la Economía, abril 2010.

[Walter Bodwell 2009] What Is Agile? by Walter Bodwell, wbodwell on Sun (wbodwell's blog), 09/27/2009.

[Laszlo Bock 2015] La nueva fórmula de trabajo. Revelaciones de Google que cambiarán su forma de vivir y liderar, Por Laszlo Bock, 2015.

Agilismo: ¿Qué es ser ágil?

¿Qué es ser ágil?

La palabra ágil fue asociada con el desarrollo de software en 2001 cuando el Manifiesto Ágil fue escrito por un grupo de visionarios y líderes en desarrollo de software [Stephen Haunts 2015]. Este manifiesto es la base pilar que tiene cuatro valores como cualidades que consideramos valiosas o deseables tener en cuenta para ser ágil. En consecuencia, ser ágil es adherir a estos valores y a sus principios, o sea al manifiesto y actuar acorde a ello [Walter Bodwell 2009][Stephen Haunts 2015].

What Is to be Agile? "To be agile, you need to adhere to the Agile Manifesto…As long as you're sticking to the Agile Manifesto's values and principles and delivering high-value software regularly to your customers, you should be considered Agile." [Stephen Haunts 2015]

Un valor es lo que tu pones delante de otra cosa cuando decides algo. No es difícil tomar decisiones cuando sabemos cuales son nuestros valores (Roy Disney). Por tal motivo, si somos conscientes de nuestros valores ágiles tomaremos decisiones alineadas a ellos. Nuestros valores tienen una gran determinación sobre nuestros resultados. En consecuencia, nuestra praxis ágil dependerá de nuestra mentalidad, de nuestro “mindset”.

Desde esta perspectiva, ser ágiles es que seamos conscientes de estos valores y que los tenemos presente en el día a día; que reflexionamos en el trabajo diario si actuamos acordes a ellos, si estamos convencidos de sus fundamentos, si comprendemos su alcance y cómo los aplicamos cuando resolvemos problemas o hacemos nuestra labor diaria.

Los valores ágiles expresados en el manifiesto ágil reordenados son los siguientes:

1. Individuos e interacciones, sobre procesos y herramientas.
2. Colaboración con el cliente, sobre negociación contractual.
3. Respuesta ante el cambio, sobre seguir un plan.
4. Software funcionando sobre, documentación extensiva.

[Agilemanifesto 2001]

Referencias:

[Agilemanifesto 2001] Agilemanifesto.org, 2001. URL: http://agilemanifesto.org/iso/es

[Stephen Haunts 2015] Agile Software Development Succinctly By Stephen Haunts Foreword by Daniel Jebaraj. 2015 by Syncfusion, Inc. Courtney Wright.

[Walter Bodwell 2009] What Is Agile? by Walter Bodwell, wbodwell on Sun (wbodwell's blog), 09/27/2009. (URL: http://www.walterbodwell.com/what_is_agile)

[dosideas.com 2009] Qué significa ser ágil. URL: http://www.dosideas.com/noticias/reflexiones/732-ique-significa-ser-agil.html

[Scrumalliance 2016] What Is Agile?

https://www.scrumalliance.org/why-scrum/what-is-agile?mkt_tok=eyJpIjoiWmpWaVpHSmhNV1psWWprMCIsInQiOiJGNkpORGFmalwvK2VEQXZqdVV3SDZaU0NvNklOKzFGU2RWTFRFWWtHV3FESEtxM1k0ZHNIRGRcL1hjdjlIOXkzc0ZXcG1YZFhJSGp3ZTErU29jM1Vkb3FcL2ZVWFB0SEVkMDBTRkpUYjVCa1JYQT0ifQ%3D%3D

Agile: Qué es una Story y qué no

Criterio de demarcación de una Story

¿Qué es una Story y qué no? ¿Cuál es el criterio de demarcación?

¿Qué es una Story?

Según el concepto general de metodología Ágil, la Story se define como una "promesa de una conversación " o una "descripción de una característica" [UNTREF 2014] [Dan North 2015]. Según esta perspectiva, representa una "funcionalidad de aplicación" para un usuario y que brinda un beneficio (ROL + FUNCIONALIDAD + BENEFICIO):

COMO <ROL> QUIERO <FUNCIONALIDAD> PARA QUE <BENEFICIO>

No es exactamemte un requerimiento pero puede considerarse como el título de un requerimiento como recordatorio de algo relevante a conversar con el usuario (o cliente). En consecuencia lo relevante es su evolución como conversación [UNTREF 2014].

La Story describe lo que el usuario quiere hacer desde la perspectiva de una interacción con un proceso de negocio, describe el objetivo del usuario en términos de necesidad de obtener algo que se hace en el negocio [Bellware Scott 2014].

Según Dan North y en el marco de Behavior-Driven Development (BDD), una Story es más un requerimiento, pues tiene que ser una descripción de un requisito y su beneficio para el negocio, y un conjunto de criterios con los que todos estamos de acuerdo de qué es o lo que se hace, "lo que el cliente necesita" [Dan North 2015]. 

Story para Scrum

Para Scrum existen items de Backlog de producto PBI que se los suele denominar como Story. El Product Backlog incluye incisos o Stories que aportan valor al cliente y que suelen ser descripción de requisitos funcionales. Aunque también puede incluir entradas para exploración de características, necesidades del cliente u opciones técnicas, requerimientos no funcionales, el trabajo necesario para lanzar el producto, y otros incisos, así como la configuración del entorno o arreglar defectos [Scrum-Institute , 2015]. O sea que puede proporcionar valor en forma indirecta mediante el aumento de la calidad o la reducción de los incidentes en el largo plazo [Scrum-Institute , 2015].

¿Cuál es el criterio de demarcación?

El criterio de demarcación aceptado en metodología ágil en general es el criterio INVEST que consta de seis características a cumplir:

1- Independiente: debe ser atómica.
2- Negociable: debe ser conversable y en consecuencia negociable (es viva).
3- Valueble: debe generar un valor al usuario o cliente. Una Story sin una declaración de la motivación del usuario a menudo se piensa que es no accionable; es decir, la historia no se puede estimar o implementar fácilmente [Bellware Scott 2014].
4- Estimable: se debe poder estimar.
5- Pequeña: debe ser lo suficientemente pequeña para entrar en un sprint o iteración.
6-  Probable: debe poder ser testeable.


[UNTREF 2014][Agile Alliance 2015] (Bill Wake's)

¿Qué NO es una Story?

Si no cumple con el criterio INVEST es bastante probable que no sea una Story. Por ejemplo una tarea puramente técnica (que le interesa solo al desarrollador), un refactoring técnico o un Spike no cumplen con INVEST y en su generalidad no son Story. Veamos:

Spike: 

No es una Story ya que es una tarea de investigación y/o experimentación en formato time-boxing por lo que no cumple con ser testeable ni estimable (no cumple con dos criterios).

Refactoring Task: 

Es una tarea técnica que no es valuable o su valoración es a futuro o en relación a un atributo de calidad que puede no estar directamente solicitado por el cliente o no impacta en beneficio inmediato para el cliente, ya que podría estar resolviendo una deuda técnica. Esto no quiere decir que no pueda haber una "story de refactoring" que puede proporcionar valor en forma indirecta mediante el "aumento de la calidad o la reducción de los incidentes en el largo plazo".

Technical Story:

“Cada historia tiene que ser valorado por los usuarios. Pero eso sería un error." [Mike Cohn 2004] Pues en realidad, una historia de usuario describe la funcionalidad que será valiosa para un usuario o comprador de un sistema o software [Mike Cohn 2004]. Hay historias que especifican aspectos técnicos que no son valiosos para el usuario sino mas bien para el cliente o comprador (la valoración es transitiva y no directa). Historias técnicas pueden ser valorados por los compradores que contemplan la compra del producto, pero no serían valorados por los usuarios reales. Pero esto no es lo que podemos llamar una "Technical Story" sino que es una Story con aspectos técnicos que tiene valor para el cliente. Para Scott Ambler en Agile Modeling, una Story es una definición de muy alto nivel de un requerimiento que puede ser funcional o no, por ejemplo de un requerimiento técnico [Scott Ambler 2015], por ejemplo: "como usuario quiero que las transcripciones estén disponibles en línea a través de un navegador estándar lo que me permite acceder desde cualquier lugar" [Scott Ambler 2015].

Cuando se habla de "Technical Story" se referencia a aquella historia técnica que sólo es valorada por los desarrolladores. Estas historias son las que se quieren evitar y considerar como Technical Story que podría ser una tarea técnica o una historia mejor redactada. Este tipo de historias se centran en la tecnología y las ventajas para los programadores. Es muy posible que las ideas detrás de estas historias sean buenas, pero en cambio deben ser escritas para que los beneficios a los clientes o usuarios sean evidentes. Esto permitirá que el cliente priorizar inteligentemente estas historias en el calendario de desarrollo [Mike Cohn 2004].

Para la Agile Alliance una Story no se corresponden en general a un "componente técnico" o de la "interfaz de usuario", pues a pesar de que a veces puede ser un atajo útil hablar de por ejemplo "la historia de diálogo de búsqueda", pantallas, cuadros de diálogo y botones, no son historias de usuario [Agile Alliance 2015].

Referencias:

[Mike Cohn 2004]

User Stories Applied For Agile Software Development. Mike Cohn, 2004.

[Dan North 2015]

WHAT’S IN A STORY? Dan North, 2015.

[UNTREF 2014]

Construcción de software: una mirada ágil. Nicolás Paez, Diego Fontdevila, Pablo Suárez, Carlos Fontela, Marcio Degiovannini, Alejandro Molina. Universidad Nacional de Tres de Febrero (UNTREF), 2014.

[Bellware Scott 2014]
Behavior­Driven Development. By Bellware Scott. Code Magazine, by EPS Software Corp. 1993 ­ 2014. All rights reserved. (www.codemag.com/article/0805061)

[Scott Ambler 2015]
User Stories: An Agile Introduction. Scott Ambler and Associates, Agile Modeling, 2015. URL: http://www.agilemodeling.com/artifacts/userStory.htm

[Agile Alliance 2015]
Agile Alliance, User Stories. URL: http://guide.agilealliance.org/guide/user-stories.html

[Scrum-Institute , 2015]

Scrum revealed: the only book can simply learn scrum! International Scrum Institute (scrum-institute.org) o ISI.