¿Dónde están los detalles?

¿Qué valores pueden buscar los usuarios? ¿Estado? ¿Ciudad? ¿Título del trabajo? ¿Palabras clave?

- ¿El usuario tiene que ser miembro del sitio?

- ¿Se pueden guardar los parámetros de búsqueda?

Muchos de estos detalles pueden ser expresados como historias adicionales. De hecho, es mejor
tener más historias que tener historias demasiado grandes.

pero como punto de partida es bueno tener historias que puedan ser codificadas y probadas entre
medio día y quizás dos semanas por uno o un par de programadores.

Cuando una historia es demasiado grande, a veces se la denomina épica. Las epopeyas pueden
dividirse en dos o más historias de menor tamaño.

Sin embargo, la conversación es la clave, no la nota en la tarjeta de la historia. Ni los desarrolladores

ni el cliente pueden señalar la tarjeta tres meses después y decir: "Pero, mira lo que dije allí". Las
historias no son obligaciones contractuales.

Cuan largas tienen que ser?

Si usas tarjetas de papel, puedes darle la vuelta a la tarjeta y capturar estas expectativas allí. Las
expectativas se escriben como recordatorios de cómo probar la historia

Las descripciones de la prueba están pensadas para ser cortas e incompletas. Las pruebas pueden
ser añadidas o quitadas en cualquier momento. El objetivo es transmitir información adicional sobre
la historia para que los desarrolladores sepan cuando están terminadas.

El equipo del cliente

En un proyecto ideal tendríamos una sola persona que priorice el trabajo para los desarrolladores,
responda omniscientemente a sus preguntas, use el software cuando esté terminado y escriba todas
las historias. Esto es casi siempre demasiado para esperar, así que establecemos un equipo de
clientes.

El equipo del cliente incluye a aquellos que aseguran que el software satisfará las necesidades de sus
usuarios previstos. Esto significa que el equipo del cliente puede incluir probadores, un gerente de
producto, usuarios reales y diseñadores de interacción.

¿Cómo será el proceso?

Un proyecto que utilice historias tendrá un sentido y un ritmo diferente al que usted puede estar
acostumbrado. El uso de un proceso tradicional orientado a la cascada lleva a un ciclo de escribir
todos los requisitos, analizar los requisitos, diseñar una solución, codificar la solución, y finalmente
probarla. Muy a menudo, durante este tipo de proceso, los clientes y usuarios participan al principio
para escribir los requisitos y al final para aceptar el software, pero la participación de los usuarios y
clientes puede desaparecer casi por completo entre los requisitos y la aceptación.

Lo primero que se observa en un proyecto basado en una historia es que los clientes y usuarios
siguen participando durante toda la duración del proyecto. No se espera (¡o se permite!) que
desaparezcan durante la mitad del proyecto.
Los clientes y usuarios previstos del nuevo software deben planear tomar un papel muy activo en la
redacción de las historias de los usuarios

Las historias iniciales de un proyecto suelen escribirse en un taller de escritura de historias, pero las
historias pueden escribirse en cualquier momento a lo largo del proyecto.

todos hacen una tormenta de ideas con tantas historias como sea posible. Armados con un conjunto
inicial de historias, los desarrolladores estiman el tamaño de cada una.

En colaboración, el equipo del cliente y los desarrolladores seleccionan una duración de iteración, de
quizás una a cuatro semanas. La misma duración de iteración se utilizará para la duración del
proyecto. Al final de cada iteración los desarrolladores serán responsables de entregar código
totalmente utilizable para algún subconjunto de la aplicación.

El equipo del cliente permanece altamente involucrado durante la iteración, hablando con los
desarrolladores sobre las historias que se desarrollan durante esa iteración. Durante la iteración el
equipo del cliente también especifica las pruebas y trabaja con los desarrolladores para automatizar
y ejecutar las pruebas. Además, el equipo del cliente se asegura de que el proyecto esté en
constante movimiento hacia la entrega del producto deseado.

Una vez seleccionada la duración de la iteración, los desarrolladores estiman la cantidad de trabajo
que podrán realizar por cada iteración.

Para planear un lanzamiento, clasificamos las historias en varios montones, cada uno de los cuales
representa una iteración. Cada pila contendrá un cierto número de historias, cuyas estimaciones no
superan la velocidad estimada. Las historias de mayor prioridad van en el primer montón. Cuando
ese montón está lleno, las siguientes historias de mayor prioridad pasan a un segundo montón (que
representa la segunda iteración). Esto continúa hasta que se han hecho tantos montones que no se
tiene tiempo para el proyecto o hasta que los montones representan una nueva versión deseable del
producto.

Antes del comienzo de cada iteración el equipo del cliente puede hacer correcciones a medio camino
del plan. A medida que se completan las iteraciones, aprendemos la velocidad real del equipo de
desarrollo y podemos trabajar con ella en lugar de la velocidad estimada. Esto significa que cada pila
de historias puede necesitar ser ajustada añadiendo o quitando historias. Además, algunas historias
resultarán ser mucho más fáciles de lo previsto, lo que significa que el equipo a veces querrá que se
le dé una historia adicional para hacer en esa iteración. Pero algunas historias serán más difíciles de
lo previsto.

¿Por qué el cliente escribe las historias?

El equipo del cliente, más que los desarrolladores, escribe las historias de los usuarios por dos
razones principales. En primer lugar, cada historia debe ser escrita en el lenguaje de la empresa, no
en la jerga técnica, para que el equipo del cliente pueda priorizar las historias para incluirlas en las
iteraciones y lanzamientos. Segundo, como los principales visionarios del producto, el equipo del
cliente está en la mejor posición para describir el comportamiento del producto.

Planificación de lanzamientos e iteraciones

Una liberación se compone de una o más iteraciones. La planificación de la liberación se refiere a
disuadir la extracción de un equilibrio entre una línea de tiempo proyectada y un conjunto de
funciones deseadas. La planificación de la iteración se refiere a la selección de historias para su
inclusión en esta iteración. El equipo del cliente y los desarrolladores están involucrados en la
planificación de la liberación y la iteración.

Para planear un lanzamiento, el equipo del cliente comienza por priorizar las historias. Mientras
priorizan querrán considerar:

- La conveniencia de la característica para una amplia base de usuarios o clientes

- La conveniencia de la característica para un pequeño número de usuarios o clientes importantes

Los desarrolladores tienen diferentes prioridades para muchas de las historias. Pueden sugerir que
se cambie la prioridad de un relato en función de su riesgo técnico o porque es complementario de
otro relato. El equipo del cliente escucha sus opiniones pero luego prioriza las historias de manera
que se maximice el valor entregado a la organización. Las historias no pueden ser priorizadas sin
considerar sus costos.

El costo de una historia es la estimación que le dan los desarrolladores. A cada historia se le asigna
una estimación en puntos de historia, que indica el tamaño y la complejidad de la historia en
relación con otras historias. Así pues, se prevé que un relato estimado en cuatro puntos de relato
tardará el doble de tiempo que un relato estimado en dos puntos de relato.

El plan de liberación se construye asignando historias a las iteraciones de la liberación. Los

desarrolladores indican su velocidad esperada, que es el número de puntos de historia que creen
que completarán por cada iteración. Luego el cliente asigna historias a las iteraciones, asegurándose
de que el número de puntos de historia asignados a cualquier iteración no exceda la velocidad de
equipo esperada.

¿Qué son las pruebas de aceptación?

Las pruebas de aceptación son el proceso de verificar que las historias se desarrollaron de tal
manera que cada una funciona exactamente como el equipo del cliente esperaba que funcionara.
Una vez que comienza una iteración, los desarrolladores comienzan a codificar y el equipo del
cliente empieza a especificar pruebas. Esto puede significar cualquier cosa, desde escribir pruebas en
el reverso de la tarjeta de la historia hasta poner las pruebas en una herramienta de pruebas
automatizada.

Las pruebas deben ser escritas tan pronto como sea posible en una iteración. Escribir las pruebas
temprano es extremadamente útil porque más de las suposiciones y expectativas del equipo del
cliente se comunican antes a los desarrolladores

¿Por qué cambiar? (Con respecto al enfoque tradicional)

algunas de las razones son:

- Las historias de usuarios enfatizan la comunicación verbal en lugar de la escrita.

- Las historias de usuarios son comprensibles tanto para usted como para los desarrolladores.
- Las historias de usuarios tienen el tamaño adecuado para la planificación.

- Las historias de usuario funcionan para el desarrollo iterativo.

Dado que las historias de usuarios hacen hincapié en la comunicación oral y no en la escrita, las
decisiones importantes no quedan plasmadas en documentos que no es probable que se lean. En
cambio, los aspectos importantes de las historias se capturan en pruebas de aceptación
automatizadas y se ejecutan con frecuencia

Cada historia de usuario representa una pieza discreta de funcionalidad, es decir, algo que un
usuario probablemente haría en un solo escenario. Esto hace que las historias de usuarios sean
apropiadas como herramienta de planificación. Un proceso iterativo es aquel que avanza a través de
refinamientos sucesivos.

Con cada iteración el programa informático se mejora mediante la adición de mayores detalles. Las
historias funcionan bien para el desarrollo iterativo porque también es posible iterar sobre las
historias

Escribir historias
Para crear buenas historias nos centramos en seis atributos. Una buena historia es:

- Independiente

- Negociable

- Valioso para los usuarios o clientes

- Estimable

- Pequeño

- Testeable

Siglas INVEST (la S es de Small pequeño)

Independiente

En la medida de lo posible, se debe tener cuidado de evitar la introducción de dependencias entre

las historias. Las dependencias entre historias llevan a problemas de priorización y planificación.

Cuando se presenta este tipo de dependencia, hay dos maneras de evitarla:

- Combinar las historias de dependencia en una historia más grande pero independiente

- Encuentra una forma diferente de dividir las historias

Negociable

Las historias son negociables. No son contratos escritos o requisitos que el software deba
implementar. Las tarjetas de historia son breves descripciones de la funcionalidad, cuyos detalles
deben negociarse en una conversación entre el cliente y el equipo de desarrollo. Dado que las
tarjetas de historia son recordatorios para tener una conversación en lugar de requisitos
completamente detallados por sí mismos, no es necesario que incluyan todos los detalles relevantes.
Sin embargo, si en el momento en que se escribe la historia se conocen algunos detalles
importantes, deben incluirse como anotaciones en la tarjeta de historia

Valioso para los compradores o usuarios

Es tentador decir algo como "Cada historia debe ser valorada por los usuarios". Pero eso estaría mal.
Muchos proyectos incluyen historias que no son valoradas por los usuarios. Hay que tener en cuenta
la distinción entre usuario (alguien que usa el software) y comprador (alguien que compra el
software),

La mejor manera de asegurar que cada historia sea valiosa para el cliente o los usuarios es que el
cliente escriba las historias. Los clientes a menudo se sienten incómodos con esto inicialmente,
probablemente porque los desarrolladores los han entrenado para que piensen que todo lo que
escriben es algo que se les puede reprochar más tarde. La mayoría de los clientes comienzan a
escribir historias por sí mismos una vez que se sienten cómodos con el concepto de que las tarjetas
de historia son recordatorios para hablar más tarde en lugar de compromisos formales o
descripciones de funcionalidad específica

Estimable

Es importante que los desarrolladores puedan estimar (o al menos adivinar) el tamaño de una
historia o la cantidad de tiempo que llevará convertir una historia en código de trabajo. Hay tres
razones comunes por las que una historia puede no ser estimable:

1. Los desarrolladores carecen de conocimiento del dominio.

2. Los desarrolladores carecen de conocimientos técnicos.: La solución en este caso es enviar a uno o
más desarrolladores en lo que "Programación Extrema" llama un S.P.I.K.E., que es un breve
experimento para aprender sobre un área de la aplicación. Durante el S.P.I.K.E los desarrolladores
aprenden lo suficiente para poder estimar la tarea. El propio S.P.I.K.E. siempre se le da una cantidad
máxima de tiempo definida (llamada caja de tiempo), lo que nos permite estimar el S.P.I.K.E. De esta
manera una historia inestimable se convierte en dos historias: un S.P.I.K.E. rápido para reunir
información y luego una historia para hacer el trabajo real

3. La historia es demasiado grande

Pequeño/Small

El tamaño de la historia es importante porque si las historias son demasiado grandes o demasiado
pequeñas no se pueden utilizar en la planificación. Las épicas son difíciles de trabajar porque
frecuentemente contienen múltiples historias.

--Separar las historias

Las epopeyas típicamente caen en una de dos categorías:

- La historia compuesta: Una historia compuesta es una epopeya que comprende múltiples historias
más cortas.
- El relato complejo: el relato complejo es un relato de usuarios que es inherentemente grande y no
puede ser fácilmente desglosado en un conjunto de relatos constituyentes

--combinando historias

A veces las historias son demasiado pequeñas. Una historia que es demasiado pequeña es
típicamente una que el desarrollador dice que no quiere escribir o estimar porque hacer eso puede
tomar más tiempo que hacer el cambio. Un buen enfoque para las historias pequeñas, común entre
los equipos de Programación Extrema, es combinarlas en historias más grandes que representen
desde un medio día hasta varios días de trabajo.

Testeable

Las historias deben ser escritas para ser comprobadas. Pasar con éxito sus pruebas prueba que una
historia se ha desarrollado con éxito. Si la historia no puede ser probada, ¿cómo pueden los
desarrolladores saber cuando han terminado de codificar?

Las historias no comprobables comúnmente se muestran para requisitos no funcionales, que son
requisitos sobre el software pero no directamente sobre su funcionalidad.

Historias de usuarios, pruebas de aceptación/ Acceptance Testing

User Stories
Una razón para escribir pruebas de aceptación es expresar muchos de los detalles que resultan de
las conversaciones entre los clientes y los desarrolladores. En lugar de escribir largas listas de
declaraciones de requisitos de estilo "El sistema deberá...", las pruebas se utilizan para rellenar los
detalles de una historia de usuario.

Las pruebas se ven mejor como un proceso de dos pasos: Primero, se anotan notas sobre las futuras
pruebas en el reverso de las tarjetas de la historia. Esto puede hacerse cada vez que alguien piensa
en una nueva prueba. En segundo lugar, las notas de la prueba se convierten en pruebas completas
que se utilizan para demostrar que la historia ha sido codificada correcta y completamente.

Las pruebas de aceptación también proporcionan criterios básicos que pueden utilizarse para
determinar si una historia se ha implementado completamente. Tener criterios que nos digan
cuándo se hace algo es la mejor manera de evitar poner demasiado, o demasiado poco, tiempo y
esfuerzo en ello.

Pruebas de escritura antes de la codificación

Naturalmente, para que los programadores se beneficien de esta manera, las pruebas de aceptación
de una historia deben ser escritas antes de que comience la programación de esa historia. Las
pruebas se escriben generalmente en los siguientes momentos:

 cuando el cliente y los desarrolladores hablan de la historia y quieren captar detalles

explícitos
 como parte de un esfuerzo dedicado al comienzo de una iteración pero antes de que
comience el programa...
 siempre que se descubran nuevas pruebas durante o después de la programación de la
historia
El cliente especifica las pruebas

Debido a que el software está siendo escrito para cumplir con una visión sostenida por el cliente, las
pruebas de aceptación deben ser especificadas por el cliente. El cliente puede trabajar con un
programador o probador para crear realmente las pruebas, pero mínimamente el cliente necesita
especificar las pruebas que se usarán para saber cuándo una historia ha sido desarrollada
correctamente.

Las pruebas son parte del proceso

Con las historias de usuarios es vital que las pruebas sean vistas como parte del proceso de
desarrollo, no como algo que ocurre "después de que se hace la codificación". La especificación de
las pruebas suele ser una responsabilidad compartida entre un gerente de producto y un probador.

¿Cuántas pruebas son demasiadas?

El cliente debe seguir escribiendo pruebas mientras añadan valor y aclaración a la historia. El cliente
no es responsable de identificar todas las pruebas posibles. El cliente debe centrar sus esfuerzos en
escribir pruebas que aclaren la intención de la historia a los desarrolladores.

Las pruebas de aceptación tienen por objeto demostrar que una aplicación es aceptable para el
cliente que ha sido responsable de guiar el desarrollo del sistema. Esto significa que el cliente debe
ser quien ejecute las pruebas de aceptación. Como mínimo, las pruebas de aceptación deben ser
ejecutadas al final de cada iteración. Debido a que el código de trabajo de una iteración puede
romperse por el desarrollo en una iteración posterior, es importante ejecutar pruebas de aceptación
de todas las iteraciones anteriores.

Tipos de pruebas

Hay muchos tipos de pruebas, y el cliente y el equipo de desarrollo deben trabajar juntos para
asegurarse de que se están realizando los tipos de pruebas apropiados. Por ejemplo, puede
considerar cualquiera o todos los siguientes:

 Pruebas de la interfaz de usuario, que aseguran que todos los componentes de la interfaz de
usuario se comportan como se espera
 Pruebas de uso, que se hacen para asegurar una aplicación que pueda ser utilizada
fácilmente
 Pruebas de rendimiento, que se hacen para medir cuán bien la aplicación se desempeñará
bajo varias cargas de trabajo
 Pruebas de estrés, en las que la aplicación se somete a valores extremos de usuarios,
transacciones o cualquier otra cosa que pueda poner la aplicación bajo tensión
Dean Leffingwell and Pete Behrens – A user story primer
Una historia de usuario es una breve declaración de intenciones que describe algo que el sistema
debe hacer por el usuario.

Las historias de usuario son una herramienta para definir el comportamiento de un sistema de
manera que sea comprensible tanto para los desarrolladores como para los usuarios. Las historias de
usuario centran el trabajo en el valor definido por el usuario en lugar de una estructura de desglose
funcional, que es la forma en que tradicionalmente se ha encargado el trabajo. Proporcionan un
enfoque ligero y eficaz para gestionar los requisitos de un sistema.

Un relato de usuario captura una breve declaración de la función en una index card/ficha, o tal vez
con una herramienta en línea.

Los relatos de usuarios ayudan a salvar la brecha de comunicación entre el desarrollador y el

cliente

En el desarrollo "ágil", el trabajo del desarrollador es hablar el lenguaje del usuario, no el de la

tecnología. La comunicación efectiva es la clave, y necesitamos un lenguaje común. La historia del
usuario proporciona el lenguaje común para construir el entendimiento entre el usuario y el equipo
técnico

Las historias de usuarios no son requisitos

Si bien las historias de usuarios hacen la mayor parte del trabajo que antes se hacía con las
especificaciones de los requisitos de software, los casos de uso y otros similares, son materialmente
diferentes en una serie de formas sutiles, pero críticas.

 No son especificaciones de requisitos detalladas (algo que un sistema debe hacer) sino más
bien expresiones de intención negociables (necesita hacer algo al respecto)
 Son breves y fáciles de leer, comprensibles para los desarrolladores, las partes interesadas y
los usuarios - Representan pequeños incrementos de la valiosa funcionalidad, que pueden
desarrollarse en un período de días a semanas
 Son relativamente fáciles de estimar, por lo que el esfuerzo para implementar la
funcionalidad puede determinarse rápidamente
 No se llevan en documentos grandes y poco manejables, sino que se organizan en listas que
se pueden ordenar y reordenar más fácilmente a medida que se descubre nueva
información
 No se detallan al principio del proyecto, sino que se elaboran justo a tiempo, evitando así
una especificidad demasiado temprana, retrasos en el desarrollo, inventario de necesidades
y una declaración demasiado restrictiva de la solución
 Necesitan poco o ningún mantenimiento y pueden ser descartados de forma segura
después de la aplicación
Forma de las users

La tarjeta representa 2 ó 3 oraciones usadas para describir la intención de la historia. La tarjeta sirve
como una ficha memorable, que resume la intención y representa un requisito más detallado, cuyos
detalles quedan por determinar.

La conversación representa una discusión entre el equipo, el cliente, el propietario del producto y
otras partes interesadas, que es necesaria para determinar el comportamiento más detallado
requerido para implementar la intención. En otras palabras, la tarjeta también representa una
"promesa para una conversación" sobre la intención.

La confirmación representa la prueba de aceptación, que es la forma en que el cliente o el

propietario del producto confirmará que la historia ha sido implementada a su satisfacción. En otras
palabras, la Confirmación representa las condiciones de satisfacción que se aplicarán para
determinar si la historia cumple o no la intención, así como los requisitos más detallados

Voz de la historia del usuario / User Story Voice

En los últimos años se ha aplicado una nueva forma estandarizada que refuerza significativamente
la construcción de la historia del usuario. La forma es la siguiente:

Como un <ROLE> puedo<ACTIVIDAD> para que <Valor de Negocio> donde:

 Rol - representa quién está realizando la acción o quizás uno que está recibiendo el valor de
la actividad. Incluso puede ser otro sistema, si eso es lo que está iniciando la actividad.
 Actividad - representa la acción a realizar por el sistema.
 Valor del negocio - representa el valor para el negocio.

Llamamos a esto la forma de "voz del usuario" de la expresión de la historia del usuario y la
encontramos una construcción extremadamente útil porque abarca el espacio del problema ( <Valor
del Negocio> entregado) y el espacio de la solución ( <Actividad> el usuario realiza con el sistema).
También proporciona una perspectiva de usuario primero (<ROLE>) al equipo, que los mantiene
enfocados en el valor del negocio y en la solución de problemas reales para gente real.

Esta forma de historia de usuario mejora enormemente la comprensión del "por qué" y el "cómo"
que los desarrolladores necesitan para implementar un sistema que realmente satisfaga las
necesidades de los usuarios.

Detalle de la historia de usuario

Los detalles de las historias de los usuarios se transmiten principalmente a través de la conversación
entre el propietario del producto y el equipo, manteniendo al equipo involucrado desde el principio.
Sin embargo, si se necesitan más detalles sobre la historia, pueden proporcionarse en forma de
anexo (maqueta, hoja de cálculo, algoritmo o lo que sea), que se adjunta a la historia de usuario.

Los detalles adicionales del relato del usuario deben recopilarse a lo largo del tiempo ("justo a
tiempo") mediante debates y la colaboración con el equipo y otros interesados antes y durante la
elaboración.
Criterios de aceptación de los relatos de los usuarios

Además de la declaración de la historia de usuario, se pueden mantener notas adicionales,

suposiciones y criterios de aceptación con una historia de usuario. Es probable que muchas
discusiones sobre una historia entre el equipo y los clientes tengan lugar antes y durante el tiempo
en que la historia se comprometa al código. Los flujos alternos en la actividad, los límites de
aceptación y otras aclaraciones deben ser captados junto con la historia. Muchas de ellas pueden
convertirse en casos de prueba de aceptación, u otros casos de prueba funcional, para la historia.

I.N.V.E.S.T.
El modelo "INVEST" es bastante ubicuo y muchos equipos ágiles evalúan sus historias con respecto a
estos atributos.

Independiente

La independencia significa que una historia puede ser desarrollada, probada, y potencialmente
incluso entregada, por sí misma. Por lo tanto, también puede ser valorada independientemente.
Muchas historias tendrán algunas dependencias naturales y secuenciales a medida que la
funcionalidad del producto se construye, y sin embargo cada pieza puede entregar valor de forma
independiente.

Negociable... y negociado

A diferencia de los requisitos tradicionales, una historia de usuario no es un contrato para una
funcionalidad específica, sino más bien un marcador de posición para que los requisitos se discutan,
desarrollen, prueben y acepten. Este proceso de negociación entre la empresa y el equipo reconoce
la legitimidad y la primacía de los insumos de la empresa, pero permite el descubrimiento mediante
la colaboración y la retroalimentación. Por último, la negociabilidad de los relatos de los usuarios
ayuda a los equipos a lograr la previsibilidad.

Valioso

El objetivo de un equipo ágil es simple: entregar el mayor valor dado sus limitaciones de tiempo y
recursos. Por lo tanto, el valor es el atributo más importante en el modelo I.N.V.E.S.T. y cada historia
de usuario debe proporcionar algún valor al usuario, cliente o "interesado/stackholder" del
producto. Los Backlogs se priorizan por el valor y las empresas tienen éxito o fracasan en función del
valor que los equipos pueden ofrecer.

La creación de historias valiosas requiere que reorientemos nuestras estructuras de desglose

funcional de un enfoque horizontal a uno vertical. Creamos historias que se abren paso a través de la
arquitectura de modo que podamos presentar valor al usuario y buscar su retroalimentación lo
antes posible y con la mayor frecuencia posible

Estimable

Una buena historia de usuario es estimable. Si bien una historia de cualquier tamaño puede estar en
el backlog(SI LEES “ATRASO” ES BACKLOG), para que se desarrolle y se pruebe en una iteración, el
equipo debe ser capaz de proporcionar una estimación aproximada de su complejidad y de la
cantidad de trabajo necesaria para completarla. La inversión mínima en la estimación es determinar
si puede completarse en una sola iteración. Una mayor precisión de la estimación aumentará la
previsibilidad del equipo. Uno de los principales beneficios de la estimación de las historias de los
usuarios no es simplemente obtener un tamaño preciso, sino más bien sacar cualquier supuesto
oculto, los criterios de aceptación que falten y aclarar la comprensión común del equipo sobre la
historia.

Pequeño/Small

Las historias de usuarios deben ser lo suficientemente pequeñas como para poder ser completadas
en una iteración, de lo contrario no pueden aportar ningún valor o considerarse realizadas en ese
momento. Sin embargo, incluso las historias de usuarios más pequeñas proporcionan más agilidad y
productividad. Esto se debe a dos razones principales: el aumento del rendimiento y la disminución
de la complejidad.

Probable /Testeable

En un Agil bien hecho", todo el código es código probado, por lo que se deduce que las historias
deben ser comprobables. Si una historia no parece ser comprobable, entonces la historia está
probablemente mal formada, es demasiado compleja, o tal vez depende de otras historias en el
atraso.

Dividiendo las historias de los usuarios

Una historia de un usuario generalmente comienza como una característica o una epopeya - un
concepto grande y vago de algo que queremos hacer para un usuario. A menudo encontramos estas
grandes y vagas historias durante nuestro proceso de descubrimiento y las capturamos en el atraso.
Sin embargo, estas son historias compuestas, como se muestra a la derecha, y normalmente son
demasiado grandes para ser implementadas dentro de una iteración. Con el fin de preparar el
trabajo para las iteraciones, un equipo debe dividirlas en historias más pequeñas.

Spikes

Los SPIKES son un tipo especial de historia que se utiliza para eliminar el riesgo y la incertidumbre en
una historia de usuario u otra faceta del proyecto. Los Spikes pueden utilizarse por varias razones:

1.El equipo puede no tener conocimiento de un nuevo dominio, y los "spikes" pueden utilizarse para
la investigación básica para familiarizar al equipo con una nueva tecnología o dominio.

2. La historia puede ser demasiado grande para ser estimada apropiadamente, y el equipo puede
usar una espiga para analizar el comportamiento implícito, para poder dividir la historia en partes
estimables.

3.La historia puede contener un riesgo técnico significativo, y el equipo puede tener que hacer
alguna investigación o prototipo para ganar confianza en un enfoque tecnológico que les permita
comprometer la historia del usuario con alguna caja de tiempo futura.

4.La historia puede contener un riesgo funcional significativo, en el sentido de que, si bien la
intención de la historia puede ser comprendida, no está claro cómo el sistema necesita interactuar
con el usuario para lograr el beneficio implícito

Picos/Spikes técnicos y Spikes funcionales

Los Spikes técnicos se utilizan para investigar diversos enfoques técnicos en el ámbito de las
soluciones. Por ejemplo, un pico técnico puede utilizarse para determinar una decisión de
construcción frente a compra, la evaluación del rendimiento potencial o el impacto de la carga de
una nueva historia de un usuario, la evaluación de tecnologías de implementación específicas que
pueden aplicarse a una solución, o por cualquier razón cuando el equipo necesita desarrollar una
comprensión más segura de un enfoque deseado antes de comprometer una nueva funcionalidad en
una caja de tiempo.

Los Spikes funcionales se utilizan siempre que existe una incertidumbre significativa sobre la forma
en que un usuario podría interactuar con el sistema. Los picos funcionales suelen evaluarse mejor a
través de algún nivel de prototipo, ya sean maquetas de la interfaz de usuario, wireframes, flujos de
páginas o cualquier técnica que sea más adecuada para obtener información del cliente o de los
interesados. Algunas historias de usuarios pueden requerir ambos tipos de picos.

Guidelines/directrices para los Spikes

 Estimable, demostrable y aceptable

Como en otras historias, los Spikes se ponen en el atraso, estimados y dimensionados para que
encajen en una iteración. Los resultados de los picos son diferentes a los de una historia, ya que
generalmente producen información, más que código de trabajo. Un pico puede dar lugar a una
decisión, un prototipo, un guión gráfico, una prueba de concepto o alguna otra solución parcial para
ayudar a impulsar los resultados finales. En cualquier caso, la espiga debe desarrollar sólo la
información suficiente para resolver la incertidumbre de poder identificar y dimensionar las historias
ocultas bajo la Spikes.

El resultado de una Spikes/espiga es demostrable para el equipo. Esto aporta visibilidad a la

investigación y a los esfuerzos arquitectónicos y también ayuda a construir la propiedad colectiva y
la responsabilidad compartida de las decisiones clave que se están tomando.

Y como cualquier otra historia, las puntas son aceptadas por el propietario del producto cuando se
han cumplido los criterios de aceptación de la Spikes.

 La excepción, no la regla

Cada historia de un usuario tiene incertidumbre y riesgo - esta es la naturaleza del desarrollo ágil. El
equipo descubre la solución correcta a través de la discusión, la colaboración, la experimentación y
la negociación. Así, en cierto sentido, cada historia de usuario contiene actividades de alto nivel para
eliminar el riesgo técnico y funcional. El objetivo de un equipo ágil es aprender a aceptar y abordar
eficazmente esta incertidumbre en cada iteración. Por otra parte, una historia de picos debe
reservarse para las incógnitas más críticas y de mayor envergadura

Considere la posibilidad de implementar la spike/punta en un sprint separado de las historias

resultantes

Dado que un spike representa la incertidumbre en una o más historias potenciales, la planificación
tanto del spike como de las historias resultantes en la misma iteración es arriesgada y, en general,
debería evitarse. Sin embargo, si la spike es pequeña y sencilla y es probable que se encuentre una
solución rápida, no hay nada malo en completar las historias en la misma iteración.

Modelado de historias con tarjetas de índice/ tarjetas indexadas/las tarjetas con numeros

La escritura de historias y el modelado visual de la entrega de valores utilizando tarjetas de índice

físicas proporciona un poderoso medio visual y cinético para comprometer a todo el equipo en el
desarrollo de los atrasos. Hay una serie de ventajas en este enfoque interactivo:
El tamaño físico de las tarjetas de índice fuerza un límite de longitud de texto, requiriendo que el
escritor de la historia articule sus ideas en sólo una o dos oraciones. Esto ayuda a mantener las
historias de los usuarios pequeñas y centradas - un atributo clave

 Las cartas pueden estar dispuestas por característica (o épica o tema) y pueden estar
escritas en las mismas tarjetas de color que la característica para la diferenciación visual.
 Las tarjetas también pueden ser organizadas por tamaño para ayudar a los desarrolladores a
"ver" las relaciones de tamaño entre las diferentes historias.
 Las tarjetas pueden ordenarse por tiempo o por iteración para ayudar a evaluar las
dependencias, comprender la secuencia lógica, ver el impacto en la velocidad del equipo y
alinear y comunicar mejor las diferentes prioridades de las partes interesadas.
Sommerville Cap 1

Historia de la ingeniería de software

El concepto “ingeniería de software” se propuso originalmente en 1968, en una conferencia

realizada para discutir lo que entonces se llamaba la “crisis del software” (Naur y Randell, 1969). Se
volvió claro que los enfoques individuales al desarrollo de programas no escalaban hacia los grandes
y complejos sistemas de software. Éstos no eran confiables, costaban más de lo esperado y se
distribuían con demora.

A lo largo de las décadas de 1970 y 1980 se desarrolló una variedad de nuevas técnicas y métodos de
ingeniería de software, tales como la programación estructurada, el encubrimiento de información y
el desarrollo orientado a objetos. Se perfeccionaron herramientas y notaciones estándar y ahora se
usan de manera extensa

---------------------

Los sistemas de software son abstractos e intangibles. No están restringidos por las propiedades de
los materiales, regidos por leyes físicas ni por procesos de fabricación. Esto simplifica la ingeniería de
software, pues no existen límites naturales a su potencial. Sin embargo, debido a la falta de
restricciones físicas, los sistemas de software pueden volverse rápidamente muy complejos, difíciles
de entender y costosos de cambiar.

Aún existen muchos reportes tanto de proyectos de software que salen mal como de “fallas de
software”

las llamadas fallas del software son consecuencia de dos factores:

1. Demandas crecientes Conforme las nuevas técnicas de ingeniería de software ayudan a

construir sistemas más grandes y complejos, las demandas cambian. Los sistemas tienen que
construirse y distribuirse más rápidamente; se requieren sistemas más grandes e incluso
más complejos; los sistemas deben tener nuevas capacidades que anteriormente se
consideraban imposibles. Los métodos existentes de ingeniería de software no pueden
enfrentar la situación, y tienen que desarrollarse nuevas técnicas de ingeniería de software
para satisfacer nuevas demandas.
2. Expectativas bajas Es relativamente sencillo escribir programas de cómputo sin usar
métodos y técnicas de ingeniería de software. Muchas compañías se deslizan hacia la
ingeniería de software conforme evolucionan sus productos y servicios. No usan métodos de
ingeniería de software en su trabajo diario . Es necesaria una mejor educación y capacitación
en ingeniería de software para solucionar este problema.

Desarrollo de software profesional

El software profesional, destinado a usarse por alguien más aparte de su desarrollador, se lleva a
cabo en general por equipos, en vez de individualmente. Se mantiene y cambia a lo largo de su vida.

La ingeniería de software busca apoyar el desarrollo de software profesional, en lugar de la

programación individual. Incluye técnicas que apoyan la especificación, el diseño y la evolución del
programa, ninguno de los cuales son normalmente relevantes para el desarrollo de software
personal. Con el objetivo de ayudarlo a obtener una amplia visión de lo que trata la ingeniería de
software. No es solo el programa en si, sino también a toda la documentación asociada y los datos
de configuración requeridos para hacer que estos programas operen de manera correcta. Un
sistema de software desarrollado profesionalmente es usualmente más que un solo programa.
Ésta es una de las principales diferencias entre el desarrollo de software profesional y el de
aficionado.

¿Qué es ingeniería de software? La ingeniería de software es una disciplina de la ingeniería que se

interesa por todos los aspectos de la producción de software.

¿Cuáles son las actividades fundamentales de la ingeniería de software? Especificación, desarrollo,

validación y evolución del software

¿Cuál es la diferencia entre ingeniería de software e ingeniería de sistemas? La ingeniería de

sistemas se interesa por todos los aspectos del desarrollo de sistemas basados en computadoras,
incluidos hardware, software e ingeniería de procesos. La ingeniería de software es parte de este
proceso más general

¿Cuáles son los principales retos que enfrenta la ingeniería de software? Se enfrentan con una
diversidad creciente, demandas por tiempos de distribución limitados y desarrollo de software
confiable.

Existen dos tipos de productos de software:

1. Productos genéricos Consisten en sistemas independientes que se producen por una

organización de desarrollo y se venden en el mercado abierto a cualquier cliente que desee
comprarlos. También abarcan las llamadas aplicaciones verticales diseñadas para cierto
propósito específico, tales como sistemas de información de librería, sistemas de
contabilidad o sistemas para mantener registros dentales.
2. Productos personalizados (o a la medida) Son sistemas que están destinados para un cliente
en particular. Un contratista de software desarrolla el programa especial- mente para dicho
cliente. Ejemplos de este tipo de software incluyen los sistemas de control para dispositivos
electrónicos,

Cuando se habla de la calidad del software profesional, se debe considerar que el software lo usan y
cambian personas, además de sus desarrolladores. En consecuencia, la calidad no tiene que ver sólo
con lo que hace el software. En cambio, debe incluir el comportamiento del software mientras se
ejecuta, y la estructura y organización de los programas del sistema y la documentación asociada.
Esto se refleja en los llamados calidad o atributos no funcionales del software

Ingeniería de software

La ingeniería de software es una disciplina de ingeniería que se interesa por todos los aspectos de la
producción de software, desde las primeras etapas de la especificación del sistema hasta el
mantenimiento del sistema después de que se pone en operación. En esta definición se presentan
dos frases clave:
 1. Disciplina de ingeniería Los ingenieros hacen que las cosas funcionen. Aplican teorías,
métodos y herramientas donde es adecuado. Sin embargo, los usan de manera selectiva y
siempre tratan de encontrar soluciones a problemas, incluso cuando no hay teorías ni
métodos aplicables. Los ingenieros también reconocen que deben trabajar ante restricciones
organizacionales y financieras, de modo que buscan soluciones dentro de tales limitaciones.
2. Todos los aspectos de la producción del software La ingeniería de software no sólo se
interesa por los procesos técnicos del desarrollo de software, sino también incluye
actividades como la administración del proyecto de software y el desarrollo de
herramientas, así como métodos y teorías para apoyar la producción de software.

La ingeniería busca obtener resultados de la calidad requerida dentro de la fecha y del presupuesto.

La ingeniería de software es importante por dos razones:

1. Cada vez con mayor frecuencia, los individuos y la sociedad se apoyan en los avan zados
sistemas de software. Por ende, se requiere producir económica y rápidamente sistemas
confiables
2. A menudo resulta más barato a largo plazo usar métodos y técnicas de ingeniería de
software para los sistemas de software, que sólo diseñar los programas como si fuera un
proyecto de programación personal

El enfoque sistemático que se usa en la ingeniería de software se conoce en ocasiones como proceso
de software

Existen cuatro actividades fundamentales que son comunes a todos los procesos de software, y éstas
son:

1. Especificación del software, donde clientes e ingenieros definen el software que se producirá y las
restricciones en su operación.

2. Desarrollo del software, donde se diseña y programa el software.

3. Validación del software, donde se verifica el software para asegurar que sea lo que el cliente
requiere.

4. Evolución del software, donde se modifica el software para reflejar los requerimientos cambiantes
del cliente y del mercado.

La ingeniería de software se relaciona con las ciencias de la computación y la ingeniería de sistemas:

1. Las ciencias de la computación se interesan por las teorías y los métodos que sub yacen en las
computadoras y los sistemas de software, en tanto que la ingeniería de software se preocupa por los
asuntos prácticos de la producción del software. Cierto conocimiento de ciencias de la computación
es esencial para los ingenieros de software, del mismo modo que cierto conocimiento de física lo es
para los ingenieros electricistas.

2. La ingeniería de sistemas se interesa por todos los aspectos del desarrollo y la evo- lución de
complejos sistemas, donde el software tiene un papel principal. Por lo tanto, la ingeniería de
sistemas se preocupa por el desarrollo de hardware, el diseño de políticas y procesos, la
implementación del sistema, así como por la ingeniería de software

tres problemas generales afectan a muy diversos tipos de software:

 Heterogeneidad Cada vez con mayor frecuencia se requieren sistemas que operen como
distribuidos a través de redes que incluyan diferentes tipos de computadoras y dispositivos
móviles
 Cambio empresarial y social Los negocios y la sociedad cambian de manera increíblemente
rápida, conforme se desarrollan las economías emergentes y nuevas tecnologías están a la
disposición. Ambos necesitan tener la posibilidad de cambiar su software existente y
desarrollar rápidamente uno nuevo
 Seguridad y confianza Dado que el software está vinculado con todos los aspectos de la vida,
es esencial confiar en dicho software. Esto es especialmente cierto para los sistemas de
software remoto a los que se accede a través de una página Web o una interfaz de servicio

Diversidad de la ingeniería de software Existen muchos diferentes tipos de aplicación, incluidos los
siguientes:

 Aplicaciones independientes Se trata de sistemas de aplicación que corren en una

computadora local, como una PC, e incluyen toda la funcionalidad necesaria y no requieren
conectarse a una red
 Aplicaciones interactivas basadas en transacción Consisten en aplicaciones que se ejecutan
en una computadora remota y a las que los usuarios acceden desde sus propias PC o
terminales
 Sistemas de control embebido Se trata de sistemas de control de software que regulan y
gestionan dispositivos de hardware.
 Sistemas de procesamiento en lotes Son sistemas empresariales que se diseñan para
procesar datos en grandes lotes (batch).
 Sistemas de entretenimiento Son sistemas para uso sobre todo personal, que tienen la
intención de entretener al usuario
 Sistemas para modelado y simulación Éstos son sistemas que desarrollan científicos e
ingenieros para modelar procesos o situaciones físicas, que incluyen muchos objetos
separados interactuantes.
 Sistemas de adquisición de datos Son sistemas que desde su entorno recopilan datos usando
un conjunto de sensores, y envían dichos datos para su procesamiento a otros sistemas
 Sistemas de sistemas Son sistemas compuestos de un cierto número de sistemas de
Software
 existen fundamentos de ingeniería de software que se aplican a todos los tipos de sistema
de software:

 Deben llevarse a cabo usando un proceso de desarrollo administrado y comprendido.La

organización que diseña el software necesita planear el proceso de desarrollo,
 La confiabilidad y el desempeño son importantes para todos los tipos de sistemas. El
software tiene que comportarse como se espera, sin fallas, y cuando se requiera estar
disponible.
 Es importante comprender y gestionar la especificación y los requerimientos del software.
Debe conocerse qué esperan de él los diferentes clientes y usuarios del sistema,
 Tiene que usar de manera tan efectiva como sea posible los recursos existentes

Un proceso de software es una serie de actividades relacionadas que conduce a la elaboración de un

producto de software. Estas actividades pueden incluir el desarrollo de software

Existen muchos diferentes procesos de software, pero todos deben incluir cuatro actividades que
son fundamentales para la ingeniería de software:

1. Especificación del software Tienen que definirse tanto la funcionalidad del software como las
restricciones de su operación.

2. Diseño e implementación del software Debe desarrollarse el software para cumplir con las
especificaciones.

3. Validación del software Hay que validar el software para asegurarse de que cumple lo que el
cliente quiere.

4. Evolución del software El software tiene que evolucionar para satisfacer las necesidades
cambiantes del cliente.
Modelos de proceso de software

Un modelo de proceso de software es una representación simplificada de este proceso. Cada

modelo del proceso representa a otro desde una particular perspectiva y, por lo tanto, ofrece sólo
información parcial acerca de dicho proceso.

Tales modelos genéricos no son descripciones definitivas de los procesos de software. Más bien, son
abstracciones del proceso que se utilizan para explicar los diferentes enfoques del desarrollo de
software.

Los modelos del proceso que se examinan aquí son:

1. El modelo en cascada (waterfall) Éste toma las actividades fundamentales del proceso de
especificación, desarrollo, validación y evolución y, luego, los representa como fases
separadas del proceso, tal como especificación de requerimientos, diseño de software,
implementación, pruebas, etcétera

2. Desarrollo incremental Este enfoque vincula las actividades de especificación, desarrollo y

validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión
añade funcionalidad a la versión anterior.

3. Ingeniería de software orientada a la reutilización Este enfoque se basa en la existencia de un

número significativo de componentes reutilizables. El proceso de desarrollo del sistema se
enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde
cero

El modelo en cascada

Debido al paso de una fase en cascada a otra, este modelo se conoce como “modelo en cascada” o
ciclo de vida del software. El modelo en cascada es un ejemplo de un proceso dirigido por un plan;
en principio, usted debe planear y programar todas las actividades del proceso, antes de comenzar a
trabajar con ellas.

Las principales etapas del modelo en cascada reflejan directamente las actividades

fundamentales del desarrollo:

1. Análisis y definición de requerimientos Los servicios, las restricciones y las metas del sistema se
establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como
una especificación del sistema.

2. Diseño del sistema y del software El proceso de diseño de sistemas asigna los requerimientos,
para sistemas de hardware o de software, al establecer una arquitectura de sistema global. El diseño
del software implica identificar y describir las abstracciones fundamentales del sistema de software y
sus relaciones.

3. Implementación y prueba de unidad Durante esta etapa, el diseño de software serea liza como un
conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada
unidad cumpla con su especificación

4. Integración y prueba de sistema Las unidades del programa o los programas individuales se
integran y prueban como un sistema completo para asegurarse de que se cumplan los
requerimientos de software. Después de probarlo, se libera el sistema de software al cliente.
5. Operación y mantenimiento Por lo general (aunque no necesariamente), ésta es la fase más larga
del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir
los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación
de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos
requerimientos

En principio, el resultado de cada fase consiste en uno o más documentos que se autorizaron
(“firmaron”). La siguiente fase no debe comenzar sino hasta que termine la fase previa.

Entrega incremental
es un enfoque al desarrollo de software donde algunos de los incrementos diseñados se entregan al
cliente y se implementan para usarse en un entorno operacional. En un proceso de entrega
incremental, los clientes identifican, en un bosquejo, los servicios que proporciona el sistema.
Identifican cuáles servicios son más importantes y cuáles son menos significativos para ellos.
Entonces, se define un número de incrementos de entrega, y cada incremento proporciona un
subconjunto de la funcionalidad del sistema. La asignación de servicios por incrementos depende de
la prioridad del servicio, donde los servicios de más alta prioridad se implementan y entregan
primero.

Una vez completado y entregado el incremento, los clientes lo ponen en servicio. Esto significa que
toman la entrega anticipada de la funcionalidad parcial del sistema. Pueden experimentar con el
sistema que les ayuda a clarificar sus requerimientos, para posteriores incrementos del sistema.

Modelos de proceso evolutivo

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar
versiones cada vez más completas del software, encontramos el Espiral y Hacer prototipos(LIBRO
INGENIERIA DEL SOFTWARE UN ENFOQUE PRACTICO)

Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales para el
software, pero que no identifique los requerimientos detallados para las funciones y características.
En otros casos, el desarrollador tal vez no esté seguro de la eficiencia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma que debe adoptar la interacción entre el
humano y la máquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos tal vez
ofrezca el mejor enfoque

Modelo en espiral

El proceso de software se representa como una espiral, y no como una secuencia de actividades con
cierto retroceso de una actividad a otra. Cada ciclo en la espiral representa una fase del proceso de
software. Por ende, el ciclo más interno puede relacionarse con la factibilidad del sistema, el
siguiente ciclo con la definición de requerimientos, el ciclo que sigue con el diseño del sistema,
etcétera. El modelo en espiral combina el evitar el cambio con la tolerancia al cambio. Lo anterior
supone que los cambios son resultado de riesgos del proyecto e incluye actividades de gestión de
riesgos explícitas para reducir tales riesgos.

Cada ciclo en la espiral se divide en cuatro sectores:

  Establecimiento de objetivos Se definen objetivos específicos para dicha fase del proyecto.
 Valoración y reducción del riesgo En cada uno de los riesgos identificados del proyecto, se
realiza un análisis minucioso
 Desarrollo y validación Después de una evaluación del riesgo, se elige un modelo de
desarrollo para el sistema.
 Planeación El proyecto se revisa y se toma una decisión sobre si hay que continuar con otro
ciclo de la espiral.

What Is a User Story?

A user story describes functionality that will be valuable to either a user or purchaser of a system or
software. User stories are composed of three aspects:

• a written description of the story used for planning and as a reminder

• conversations about the story that serve to flesh out the details of the story

• tests that convey and document details and that can be used to determine when a story is
complete

The cards “represent customer requirements rather than document them.

The user stories represent functionality that will be valued by users,

Where Are the Details?

What values can users search on? State? City? Job title? Keywords?

• Does the user have to be a member of the site?

• Can search parameters be saved?

Many of these details can be expressed as additional stories. In fact, it is better to have more stories
than to have stories that are too large.

but as a starting point it’s good to have stories that can be coded and tested between half a day and
perhaps two weeks by one or a pair of programmers.

When a story is too large it is sometimes referred to as an epic. Epics can be split into two or more
stories of smaller size.
However, the conversation is the key, not the note on the story card. Neither the developers nor the
customer can point to the card three months later and say, “But, see I said so right there.” Stories
are not contractual obligations.

“How Long Does It Have to Be?”

If you’re using paper note cards, you can turn the card over and capture these expectations there.
The expectations are written as reminders about how to test the story

The test descriptions are meant to be short and incomplete. Tests can be added or removed at any
time. The goal is to convey additional information about the story so that the developers will know
when they are done.

The Customer Team

On an ideal project we would have a single person who prioritizes work for developers, omnisciently
answers their questions, will use the software when it’s finished, and writes all of the stories. This is
almost always too much to hope for, so we establish a customer team.

The customer team includes those who ensure that the software will meet the needs of its intended
users. This means the customer team may include testers, a product manager, real users, and
interaction designers.

What Will the Process Be Like?

A project that is using stories will have a different feel and rhythm than you may be used to. Using a
traditional waterfall-oriented process leads to a cycle of write all the requirements, analyze the
requirements, design a solution, code the solution, and then finally test it. Very often during this
type of process, customers and users are involved at the beginning to write requirements and at the
end to accept the software, but user and customer involvement may almost entirely disappear
between requirements and acceptance.

The first thing you’ll notice on a story-driven project is that customers and users remain involved
throughout the duration of the project. They are not expected (or allowed!) to disappear during the
middle of the project.

The customers and intended users of the new software should plan on taking a very active role in
writing the user stories

A project’s initial stories are often written in a story writing workshop, but stories can be written at
any time throughout the project.

everyone brainstorms as many stories as possible. Armed with a starting set of stories, the
developers estimate the size of each.

Collaboratively, the customer team and developers select an iteration length, from perhaps one to
four weeks. The same iteration length will be used for the duration of the project. By the end of each
iteration the developers will be responsible for delivering fully usable code for some subset of the
application.

The customer team remains highly involved during the iteration, talking with the developers about
the stories being developed during that iteration. During the iteration the customer team also
specifies tests and works with the developers to automate and run tests. Additionally, the customer
team makes sure the project is constantly moving toward delivery of the desired product.
Once an iteration length has been selected, the developers will estimate how much work they’ll be
able to do per iteration.

To plan a release, we sort stories into various piles with each pile representing an iteration. Each pile
will contain some number of stories, the estimates for which add up to no more than the estimated
velocity. The highest-priority stories go into the first pile. When that pile is full, the next highest-
priority stories go into a second pile (representing the second iteration). This continues until you’ve
either made so many piles that you’re out of time for the project or until the piles represent a
desirable new release of the producto.

Prior to the start of each iteration the customer team can make mid-course corrections to the plan.
As iterations are completed, we learn the development team’s actual velocity and can work with it
instead of the estimated velocity. This means that each pile of stories may need to be adjusted by
adding or removing stories. Also, some stories will turn out to be far easier than anticipated, which
means the team will sometimes want to be given an additional story to do in that iteration. But
some stories will be harder than anticipated.

Why Does the Customer Write the Stories?

The customer team, rather than the developers, writes the user stories for two primary reasons.
First, each story must be written in the language of the business, not in technical jargon, so that the
customer team can prioritize the stories for inclusión into iterations and releases. Second, as the
primary product visionaries, the customer team is in the best position to describe the behavior of
the product.

Planning Releases and Iterations

A release is made up of one or more iterations. Release planning refers to deter mining a balance
between a projected timeline and a desired set of functionality. Iteration planning refers to selecting
stories for inclusion in this iteration. The customer team and the developers are both involved in
release and iteration planning.

To plan a release, the customer team starts by prioritizing the stories. While prioritizing they will
want to consider:

• The desirability of the feature to a broad base of users or customers

• The desirability of the feature to a small number of important users or customers

The developers have different priorities for many of the stories. They may suggest that the priority of
a story be changed based on its technical risk or because it is complementary to another story. The
customer team listens to their opinions but then prioritizes stories in the manner that maximizes the
value delivered to the organization. Stories cannot be prioritized without considering their costs.

The cost of a story is the estimate given to it by the developers. Each story is assigned an estimate in
story points, which indicates the size and complexity of the story relative to other stories. So, a story
estimated at four story points is expected to take twice as long as a story estimated at two story
points.
The release plan is built by assigning stories to the iterations in the release. The developers state
their expected velocity, which is the number of story points they think they will complete per
iteration. The customer then allocates stories to iterations, making sure that the number of story
points assigned to any one iteration does not exceed the expected team velocity.

What Are Acceptance Tests?

Acceptance testing is the process of verifying that stories were developed such that each works
exactly the way the customer team expected it to work. Once an iteration begins, the developers
start coding and the customer team starts specifying tests. this may mean anything from writing
tests on the back of the story card to putting the tests into an automated testing tool.

Tests should be written as early in an iteration as posible. Writing tests early is extremely helpful
because morebof the customer team’s assumptions and expectations are communicated earlier to
the developers

Why Change? (Con respecto al enfoque tradicional)

some of the reasons are:

• User stories emphasize verbal rather than written communication.

• User stories are comprehensible by both you and the developers.

• User stories are the right size for planning.

• User stories work for iterative development.

Because user stories shift emphasis toward talking and away from writing, important decisions are
not captured in documents that are unlikely to be read. Instead, important aspects about stories are
captured in automated acceptance tests and run frequently

Each user story represents a discrete piece of functionality; that is, something a user would be likely
to do in a single setting. This makes user stories appropriate as a planning tool. An iterative process
is one that makes progress through successive refinement.

With each iteration the software is improved through the addition of greater detail. Stories work
well for iterative development because it is also possible to iterate over the stories

Writing Stories

To create good stories we focus on six attributes. A good story is:

• Independent

• Negotiable

• Valuable to users or customers

• Estimatable

• Small

• Testable

Independent
As much as possible, care should be taken to avoid introducing dependencias between stories.
Dependencies between stories lead to prioritization and planning problems.

When presented with this type of dependency, there are two ways around it:

• Combine the dependent stories into one larger but independent story

• Find a different way of splitting the stories

Negotiable

Stories are negotiable. They are not written contracts or requirements that the software must
implement. Story cards are short descriptions of functionality, the details of which are to be
negotiated in a conversation between the cus tomer and the development team. Because story
cards are reminders to have a conversation rather than fully detailed requirements themselves, they
do not need to include all relevant details. However, if at the time the story is written some
important details are known, they should be included as annotations to the story card

Valuable to Purchasers or Users

It is tempting to say something along the lines of “Each story must be valued by the users.” But that
would be wrong. Many projects include stories that are not valued by users. Keeping in mind the
distinction between user (someone who uses the software) and purchaser (someone who purchases
the software),

The best way to ensure that each story is valuable to the customer or users is to have the customer
write the stories. Customers are often uncomfortable with this initially—probably because
developers have trained them to think of everything they write as something that can be held
against them later. Most customers begin writing stories themselves once they become comfortable
with the concept that story cards are reminders to talk later rather than formal commitments or
descriptions of specific functionality

Estimatable

It is important for developers to be able to estimate (or at least take a guess at) the size of a story or
the amount of time it will take to turn a story into working code. There are three common reasons
why a story may not be estimatable:

1. Developers lack domain knowledge.

2. Developers lack technical knowledge.: The solution in this case is to send one or more developers
on what “Extreme Programming” calls a S.P.I.K.E., which is a brief experiment to learn about an area
of the application. During the S.P.I.K.E the developers learn just enough that they can estimate the
task. The S.P.I.K.E. itself is always given a defined maximum amount of time (called a time-box),
which allows us to estimate the S.P.I.K.E. In this way an unestimatable story turns into two stories: a
quick S.P.I.K.E. to gather information and then a story to do the real work

3. The story is too big

Small

Story size does matter because if stories are too large or too small you cannot use them in planning.
Epics are difficult to work with because they frequently contain multiple stories.

--Splitting Stories

Epics typically fall into one of two categories:

• The compound story: A compound story is an epic that comprises multiple shorter stories.

• The complex story: the complex story is a user story that is inherently large and cannot easily be
disaggregated into a set of constituent stories

--Combining Stories

Sometimes stories are too small. A story that is too small is typically one that the developer says she
doesn’t want to write down or estimate because doing that may take longer than making the
change. A Good approach for tiny stories, common among Extreme Programming teams, is to
combine them into larger stories that represent from about a half-day to several days of work.

Testable

Stories must be written so as to be testable. Successfully passing its tests proves that a story has
been successfully developed. If the story cannot be tested, how can the developers know when they
have finished coding?

Untestable stories commonly show up for nonfunctional requirements, which are requirements
about the software but not directly about its functionality.

Acceptance Testing User Stories

One reason for writing acceptance tests is to express many of the details that result from the
conversations between customers and developers. Rather tan writing lengthy lists of “The system
shall…” style requirements statements, tests are used to fill in the details of a user story.

Testing is best viewed as a two-step process: First, notes about future tests are jotted on the back of
story cards. This can be done any time someone thinks of a new test. Second, the test notes are
turned into full-fledged tests that are used to demonstrate that the story has been been correctly
and fully coded.

Acceptance tests also provide basic criteria that can be used to determine if a story is fully
implemented. Having criteria that tell us when something is done is the best way to avoid putting
too much, or too little, time and effort into it.
Write Tests Before Coding

Naturally, in order for programmers to benefit in this way, the acceptance tests for a story must be
written before programming begins on that story. Tests are generally written at the following times:

• whenever the customer and developers talk about the story and want to capture explicit details

• as part of a dedicated effort at the start of an iteration but before program- ming begins

• whenever new tests are discovered during or after the programming of the story

The Customer Specifies the Tests

Because the software is being written to fulfill a vision held by the customer, the acceptance tests
need to be specified by the customer. The customer can work with a programmer or tester to
actually create the tests, but minimally the customer needs to specify the tests that will be used to
know when a story has been correctly developed.

Testing Is Part of the Process

With user stories it is vital that testing be viewed as part of the development process, not something
that happens “after coding is done.” Specifying tests is often a shared responsibility of a product
manager and a tester.

How Many Tests Are Too Many?

The customer should continue to write tests as long as they add value and clarification to the story.
The customer is not responsible for identifying every possible test. The customer should focus her
efforts on writing tests that clarify the intent of the story to the developers.

Acceptance tests are meant to demonstrate that an application is acceptable to the customer who
has been responsible for guiding the system’s development. This means that the customer should be
the one to execute the acceptance tests. Minimally, acceptance tests should be executed at the end
of each iteration. Because working code from one iteration may be broken by development in a
subsequent iteration, it is important to execute acceptance tests from all prior iterations.

Types of Testing

There are many types of testing, and the customer and development team should work together to
ensure that the appropriate types of testing are occurring. For example, you may want to consider
any or all of the following:

• User interface testing, which ensures that all of the components of the user interface behave as
expected
• Usability testing, which is done to ensure an application that can be easily used

• Performance testing, which is done to gauge how well the application Will perform under
variousworkloads

• Stress testing, in which the application is subjected to extreme values of users, transactions, or
anything else that may put the application under stress

PAPER

▪ Papers

▫ Dean Leffingwell and Pete Behrens – A user story primer

(2009

A User Story is a brief statement of intent that describes something the system needs to do for the
user.

User stories are a tool for defining a system’s behavior in a way that is understandable to both the
developers and users. User stories focus the work on the value defined by the user rather than a
functional breakdown structure, which is the way work has traditionally been tasked. They provide a
lightweight and effective approach to managing requirements for a system.

A user story captures a short statement of function on an index card, or perhaps with an online tool.

User Stories Help Bridge the Developer – Customer Communication Gap

In “agile” development, it is the developer’s job to speak the language of the user, not the user’s job
to speak the language of technology. Effective communication is the key, and we need a common
language. The user story provides the common language to build understanding between the user
and the technical team

User Stories Are Not Requirements

While user stories do most of the work previously done by software requirements specifications,
use cases, and the like, they are materially different in a number of subtle, yet critical ways.

• They are not detailed requirements specifications (something a system shall do) but are rather
negotiable expressions of intent (it needs to do something about like this)

• They are short and easy to read, understandable to developers, stakeholders, and users • They
represent small increments of valued functionality, that can be developed in a period of days to
weeks

• They are relatively easy to estimate, so effort to implement the functionality can be rapidly
determined

• They are not carried in large, unwieldy documents, but rather organized in lists that can be more
easily arranged and re-arranged as new information is discovered
• They are not detailed at the outset of the project, but are elaborated on a just-in-time basis –
thereby avoiding too-early specificity, delays in development, requirements inventory, and an over-
constrained statement of the solution

• They need little or no maintenance and can be safely discarded after implementation

User Story Form

Card represents 2-3 sentences used to describe the intent of the story. The card serves as a
memorable token, which summarizes intent and represents a more detailed requirement, whose
details remain to be determined.

Conversation represents a discussion between the team, customer, product owner, and other
stakeholders, which is necessary to determine the more detailed behavior required to implement
the intent. In other words, the card also represents a “promise for a conversation” about the intent.

Confirmation represents the Acceptance Test, which is how the customer or product owner will
confirm that the story has been implemented to their satisfaction. In other words, Confirmation
represents the conditions of satisfaction that will be applied to determine whether or not the story
fulfills the intent as well as the more detailed requirements

User Story Voice

In the last few years, a new, standardized, form has been applied which strengthens the user story
construct significantly. The form is as follows:

As a <ROLE> I can<ACTIVITY> so that <BUSINESS VALUE> where:

• Role – represents who is performing the action or perhaps one who is receiving the value from the
activity. It may even be another system, if that is what is initiating the activity.

• Activity – represents the action to be performed by the system.

• Business Value – represents the value to the business.

We call this the “user voice” form of user story expression and find it an exceedingly useful construct
because it spans the problem space ( <BUSINESS VALUE> delivered) and the solution space
( <ACTIVITY> the user performs with the system). It also provides a user-first (<ROLE>) perspective
to the team, which keeps them focused on business value and solving real problems for real people.

This user story form greatly enhances the “why” and “how” understanding that developers need to
implement a system that truly meets the needs of the users.

User Story Detail

The details for user stories are conveyed primarily through conversation between the product owner
and the team, keeping the team involved from the outset. However, if more details are needed
about the story, they can be provided in the form of an attachment (mockup, spreadsheet,
algorithm, or whatever), which is attached to the user story.
The additional user story detail should be collected over time (“just-in-time”) through discussions
and collaboration with the team and other stakeholders before and during development.

User Story Acceptance Criteria

In addition to the statement of the user story, additional notes, assumptions, and acceptance criteria
can be kept with a user story. Many discussions about a story between the team and customers will
likely take place before and during the time the story is committed to code. The alternate flows in
the activity, acceptance boundaries, and other clarifications should be captured along with the story.
Many of these can be turned into acceptance test cases, or other functional test cases, for the story.

I.N.V.E.S.T.

The “INVEST” model is fairly ubiquitous and many agile teams evaluate their stories with respect to
these attributes. Here’s our view of the value of the team’s INVESTment.

Independent

Independence means that a story can be developed, tested, and potentially even delivered, on its
own. Therefore, it can also be independently Valued. Many stories will have some natural,
sequential dependencies as the product functionality builds, and yet each piece can deliver value
independently.

Negotiable... and Negotiated

Unlike traditional requirements, a user story is not a contract for specific functionality, but rather a
placeholder for requirements to be discussed, developed, tested, and accepted. This process of
negotiation between the business and the team recognizes the legitimacy and primacy of the
business inputs, but allows for discovery through collaboration and feedback. Finally, the
negotiability of user stories helps teams achieve predictability.

Valuable

An agile team’s goal is simple: to deliver the most value given their existing time and resource
constraints. Therefore, Value is the most important attribute in the I.N.V.E.S.T. model and every user
story must provide some value to the user, customer, or “stakeholder” of the product. Backlogs are
prioritized by value and businesses succeed or fail based on the value the teams can deliver.

Creating valuable stories requires us to re-orient our functional breakdown structures from a
horizontal to a vertical approach. We create stories that slice through the architecture so that we
can present value to the user and seek their feedback as early and often as posible

Estimable

A good user story is estimable. While a story of any size can be in the backlog, in order for it to be
developed and tested in an iteration, the team should be able to provide an approximate estimation
of its complexity and amount of work required to complete it. The minimal investment in estimation
is to determine if it can be completed within a single iteration. Additional estimation accuracy Will
increase the team’s predictability. One of the primary benefits of estimating user stories is not
simply to derive a precise size, but rather to draw out any hidden assumptions, missing acceptance
criteria, and to clarify the team’s shared understanding of the story.

Small

User stories should be small enough to be able to be completed in an iteration, otherwise they can’t
provide any value or be considered done at that point. However, even smaller user stories provide
more agility and productivity. There are two primary reasons for this: increased throughput and
decreased complexity.

Testable

In properly done agile, all code is tested code, so it follows that stories must be testable. If a story
does not appear to be testable, then the story is probably ill formed, overly complex, or perhaps
dependent on other stories in the backlog.

Splitting User Stories

A user story generally starts out as a feature or an epic – a large, vague concept of something we
want to do for a user. We often find these big vague stories during our discovery process and
capture them in the backlog. However, these are compound stories, as pictured on the right, and are
usually far too big to be implemented within an iteration. In order to prepare the work for iterations,
a team must break them down into smaller stories.

Spikes

SPIKES are a special type of story that is used to drive out risk and uncertainty in a user story or
other project facet. Spikes may be used for a number of reasons:

1. The team may not have knowledge of a new domain, and spikes may be used for basic
research to familiarize the team with a new technology or domain.
2. The story may be too big to be estimated appropriately, and the team may use a spike to
analyze the implied behavior, so they can split the story into estimable pieces.
3. The story may contain significant technical risk, and the team may have to do some research
or prototyping to gain confidence in a technological approach that will allow them to
commit the user story to some future timebox.
4. The story may contain significant functional risk, in that while the intent of the story may be
understood, it’s not clear how the system needs to interact with the user to achieve the
benefit implied

Technical Spikes and Functional Spikes

Technical spikes are used to research various technical approaches in the solution domain. For
example, a technical spike may be used to determine a build vs. buy decision, evaluation of potential
performance or load impact of a new user story, evaluation of specific implementation technologies
that can be applied to a solution, or for any reason when the team needs to develop a more
confident understanding of a desired approach before committing new functionality to a timebox.

Functional spikes are used whenever there is significant uncertainty as to how a user might interact
with the system. Functional spikes are often best evaluated through some level of prototyping,
whether it be user interface mockups, wireframes, page flows, or whatever techniques is best suited
to get feedback from the customer or stakeholders. Some user stories may require both types of
spikes.

Guidelines for Spikes

Estimable, Demonstrable, and Acceptable

Like other stories, spikes are put in the backlog, estimable and sized to fit in an iteration. Spike
results are different from a story, as they generally produce information, rather than working code.
A spike may result in a decision, a prototype, storyboard, proof of concept, or some other partial
solution to help drive the final results. In any case, the spike should develop just the information
sufficient to resolve the uncertainty in being able to identify and size the stories hidden beneath the
spike.

The output of a spike is demonstrable to the team. This brings visibility to the research and
architectural efforts and also helps build collective ownership and shared responsibility for the key
decisions that are being taken.

And like any other story, spikes are accepted by the product owner when the acceptance criteria for
the spike have been fulfilled.

The Exception, not the Rule

Every user story has uncertainty and risk – this is the nature of agile development. The team
discovers the right solution through discussion, collaboration, experimentation, and negotiation.
Thus, in one sense, every user story contains spike-level activities to flush out the technical and
functional risk. The goal of an agile team is to learn how to embrace and effectively address this
uncertainty in each iteration. A spike story, on the other hand, should be reserved for the more
critical and larger unknowns

Consider implementing the spike in a separate sprint from the resulting stories

Since a spike represents uncertainty in one or more potential stories, planning for both the spike and
the resultant stories in the same iteration is risky, and should generally be avoided. However, if the
spike is small and straightforward and a quick solution is likely to be found, there is nothing wrong
with completing the stories in the same iteration.
Story Modeling with Index Cards

Story writing and visually modeling value delivery using physical index cards provides a powerful
visual and kinesthetic means for engaging the entire team in backlog development. There are a
number of advantages to this interactive approach:

The physical size of index cards forces a text length limit, requiring the story writer to articulate their
ideas in just a sentence or two. This helps keep user stories small and focused – a key attribute

 Cards may be arranged by feature (or epic or theme) and may be written on the same
colored cards as the feature for visual differentiation.
 Cards can also be arranged by size to help developers ‘see’ the size relationships between
different stories.
 Cards can be arranged by time or iteration to help evaluate dependencies, understand
logical sequencing, see the impact on team velocity, and better align and communicate
differing stakeholder priorities.