Scrum + XP

Integrar las prácticas de Scrum y XP

Scrum + XP

https://www.visual-paradigm.com/scrum/extreme-programming-vs-scrum/
Scrum + XP

https://www.visual-paradigm.com/scrum/extreme-programming-vs-scrum/
Scrum + XP

https://www.visual-paradigm.com/scrum/extreme-programming-vs-scrum/
Fase de Inicio (Exploración-Sprint 0)
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera
entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías
y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la
arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos
meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

• Formar el Equipo Inicial

• Identificar la vision del Proyecto
• Identificar la estrategia técnica inicial
• Identificar requerimientos iniciales-product backlog inicial
• Establecer ambiente de trabajo y herramientas
• Asegurar presupuesto
• Estimación y priorización (Identificar riesgos, Definición de Terminado,Dividir y unir historias, Pruebas de
Concepto (Spike) técnico/functional)
• Plan de Lanzamiento (Story mapping, otras tecnicas)
Elaborar el Producto BackLog
• Para esto deben participar la parte técnica y la parte de negocio.
• Se debe identificar lo que el cliente quiere/necesita que haga el sistema.
• Es importante la participación de expertos del negocio, ya sea como P.O.,
usuarios o consultores.
• Se pueden emplear reuniones de enfoque de usuario, entrevistas y
demás técnicas para elicitar requisitos.
• El cliente(xp) y dueño del product(scrum) define que item incluir, su
valor de negocio y prioridad para la implementación.
• Los item del product backlog pueden ser tanto de negocio, como
técnicos.
• Los de negocio pueden escribir tanto como historia de usuario, casos de
uso o algún otro formato.
• En los procesos agiles se usa frecuentemente las historias de usuario.
Definir requisitos con historias escritas en tarjetas.
• Cada historia de usuario es una breve descripción del
comportamiento del sistema, desde el punto de vista del usuario del
sistema. En XP, el sistema se especifica completamente a través de
historias.
Tradicional Agile/XP

• El análisis se puede • El análisis informal: le

hacer de manera muy preguntamos al cliente.
formal, con objetos y • Haces análisis todo el
diagramas. tiempo.
• El análisis se realiza al • La HU es el medio de
comienzo del proyecto. análisis y comunicación
entre el cliente y el
programador.
 Historias de Usuario
Las historias de usuario son utilizadas en los métodos ágiles para la
especificación de requisitos, son una descripción breve de una funcionalidad
software tal y como la percibe el usuario (Mike Cohn, 2004).
Describen funcionalidades que dan solución a necesidades o problemas del
cliente o del usuario, representan los "qués" a construir y se escriben en forma
de historia con una o dos frases utilizando el lenguaje común del usuario.
Estas son una forma ágil de administrar los requisitos de los usuarios sin tener
que elaborar gran cantidad de documentos formales y sin requerir de mucho
tiempo para administrarlos.
Las historias de usuario forman parte de la fórmula de captura de
funcionalidades definida en 2001 por Ron Jeffries de las tres C’s.
ESCRIBIENDO HISTORIAS DE USUARIO
• Recomienda trabajar clientes y
programadores uno al lado del
otro escribiendo las historias de
usuario.
Antes de Covid-19
• En estos momentos de
pandemia en video conferencia
compartiendo pantalla.

Después de Covid-19
Procesos de Historias de Usuario
 COMO IDENTIFICAR HISTORIAS DE USUARIO
• Cliente, cuente una historia sobre cómo se utilizará el sistema.
• Programadores, escuchen y hagan preguntas para comprender.
• Programadores, Traten de mantenerse alejado de las
preguntas de implementación.
• Ahora, cliente, escriba la historia, con sus propias palabras, en
una sola tarjeta. Si toda la historia es demasiado grande,
escriba el núcleo esencial.
• A medida que avanza en este proceso, especialmente con
preguntas útiles, a menudo decidirá que una historia que ha
escrito no es del todo correcta. Eso es genial. Rompe esa
tarjeta y haz una nueva.
• Esto es muy importante: el análisis en tarjetas es flexible. No
solo está bien romper una tarjeta y comenzar una nueva, ¡es lo
mejor que puede suceder! Rompe las cartas temprano y con
frecuencia, para que todos se vuelvan buenos en eso,
• Las historias son una promesa de conversación
Tomado del Libro Extreme Programming Installed by Chet Hendrickson; Ann Anderson; Ron Jeffries 2000
 EJEMPLOS DE HU
• Las cuotas sindicales varían según el sindicato y se toman solo en el primer período de
pago del mes. El sistema calcula la deducción automáticamente. El monto se muestra
hu1 en la tabla adjunta.

• Cuando una transacción hace que la cuenta de un cliente entre en sobregiro, transfiera
dinero desde la cuenta de protección contra sobregiros, si la hubiera.
hu2
• Cuando una transacción hace que la cuenta de un cliente entre en sobregiro, envíe un
correo electrónico que muestre la transacción y el saldo al cliente. Si la protección
contra sobregiros está vigente, muestre la transacción de sobregiro y los saldos de
hu3 cuenta resultantes en el correo electrónico.

• Si la emisora ​que se está reproduciendo actualmente contiene información digital, la

información se muestra en la pantalla LCD de la radio. Si no hay información digital
HU disponible, muestre la frecuencia de la estación.

Tomado del Libro Extreme Programming Installed by Chet Hendrickson; Ann Anderson; Ron Jeffries 2000
 EJEMPLOS DE HU
•Permita que el usuario agregue nuevos tipos de servicios a la lista inicial del sistema. Por ejemplo, es posible que desee
agregar una entrada especial para lavar el automóvil en el lavado "gratuito" de la escuela secundaria. Incluya la cantidad
y fecha de los campos estándar, además de permitir que el usuario agregue cualquier texto adicional o campos

HU numéricos. Los informes deben sumar automáticamente cualquier campo numérico. (Nota del programador: la historia
debe dividirse. Separe los campos numéricos y de texto en dos historias, más una para la suma).

•(División 1) Permita que el usuario agregue nuevos tipos de servicios, incluidos los campos estándar más cualquier
campo de texto adicional que desee.
HU

•(División 2) Permitir al usuario agregar campos numéricos a los tipos de servicios definidos por el usuario.

HU

•(División 3) En todos los informes, muestre los totales de todos los campos numéricos, no solo los campos estándar de
galones y cantidades en dólares.
HU

Tomado del Libro Extreme Programming Installed by Chet Hendrickson; Ann Anderson; Ron Jeffries 2000
Las tres C’s de Ron Jeffries(2001)
• En XP y en general en los procesos agiles se
usan las HU para identificar los requisitos del
sistema.
Card • Card: Escribimos una descripción rápida de la
función en una tarjeta,
• Conversation la discutimos con nuestro cliente
Conversation (piense en el propietario del producto Scrum)
y luego
• (Confirmation)creamos ejemplos concretos
comprobables para confirmar que la función
Confirmation
hizo lo que nosotros y el cliente queríamos
Las tres C’s
• Las historias de usuario están escritas en tarjetas.
• La tarjeta no contiene toda la información que constituye el
requisito.
Card • En cambio, la tarjeta tiene suficiente texto para identificar
el requisito y recordarles a todos cuál es la historia.
• La tarjeta es una ficha que representa el requisito.
Conversation
• Se usa en la planificación.
• Se escriben notas en él, que reflejan la prioridad y el costo.
Confirmation
• A menudo se entrega a los programadores cuando la
historia está programada para ser implementada y se
devuelve al cliente cuando la historia está completa.
Las tres C’s
• El requisito en sí mismo se comunica del cliente a los
programadores a través de una conversación:
• un intercambio de pensamientos, opiniones y sentimientos.
Card • Esta conversación tiene lugar a lo largo del tiempo,
particularmente cuando se estima la historia (generalmente
durante la planificación del lanzamiento),
• y nuevamente en la reunión de planificación de iteraciones
cuando la historia está programada para su implementación.
Conversation
• La conversación es en gran parte verbal, pero se puede
complementar con documentos. Los mejores suplementos son
ejemplos; los mejores ejemplos son ejecutables, prototipos de
UI. A estos ejemplos los llamamos confirmación.
Confirmation
Las tres C’s
• Define las pruebas de aceptación que se utilizarán para demostrar
que la historia se ha implementado correctamente.
• Este componente es la prueba de aceptación.
Card • En lugar de documentos se confirmación, se prefiere: la confirmación
mediante ejemplos, preferiblemente automatizados, funciona mejor.
• Los programadores implementan la historia y también implementan
las pruebas de aceptación.
• Algunos equipos crean herramientas que permiten al cliente ingresar
Conversation a las pruebas por sí mismo, y otros equipos tienen personas de
control de calidad o evaluadores que ayudan con el trabajo.
• Al final de la iteración, cuando la historia está terminada, los
programadores le muestran al cliente que la historia está terminada,
confirmando el éxito mostrando que las pruebas de aceptación se
Confirmation ejecutan correctamente.
• La confirmación proporcionada por la prueba de aceptación es lo que
hace posible el enfoque simple de la tarjeta y la conversación.
 FORMATOS DE HU
• En los enfoque agiles no son partidarios de formatos, sin embargo hay
varios formatos para escribir HU:
• Las tres R o el formato Connextra (de uso generalizado)
• Cinco W
• Kaizen-UX template

Historia de las Historias de Usuario

Tomado del Libro Extreme Programming Installed by Chet Hendrickson; Ann Anderson; Ron Jeffries 2000
Las tres R o el formato Connextra
"As a role I want feature so that benefit“ (Rachel Davies, 2001)
"As a type of user I want capability so that business value“ (Mike Cohn, 2004)

• Formato más común. Presentando por Rachel Davies, 200s.

• Y popularizado: En 2004, Mike Cohn el libro: User Stories Applied: For Agile Software Development

• Como _____ [rol -> persona] , quiero _____ [requisito -> resultado], para _____ [motivo -> resultado].
• La tercera parte R (motivo) de esta plantilla es opcional.
• La primera iteración del ejemplo del sitio de comercio electrónico con excedentes de comestibles: como comprador, quiero ver el
contenido de mi carrito de compras en cualquier momento, incluido el valor total, la cantidad de artículos y su peso combinado,
incluidos los costos de envío totales, para que Pueda tomar decisiones sobre cómo agregar más elementos.
• Esto contiene demasiados detalles, un error común. Entonces, eliminemos lo que no es un detalle crítico aquí: como comprador,
quiero ver el contenido de mi carrito de compras para poder tomar decisiones sobre cómo agregar más artículos.
• Mucho mejor, pero la tercera parte R (para que pueda tomar decisiones sobre la adición de más elementos ) se puede omitir y la
historia del usuario seguirá funcionando según lo previsto. No solo se puede omitir, sino que debemos recortar cualquier texto
innecesario de nuestras historias de usuario para seguir el principio de simplicidad de la sección anterior.
• El ejemplo simplificado debería decir: Como comprador, quiero ver el contenido de mi carrito de compras . Así es como se ve una
historia de usuario en el formato Three R.
Cinco W
• Como ______ [ ¿quién? -> persona ] ______ [¿cuándo?]
______ [¿dónde?], yo ______ [ ¿qué? -> salida ] porque ______ [
¿por qué? -> resultado ].
• como comprador, durante el proceso de búsqueda de artículos
adicionales, en una vista dedicada , quiero ver el contenido de mi
carrito de compras, porque necesito tomar decisiones sobre cómo
agregar más artículos.

Mi concepto: Demasiado detalle para ser una historia de usuario

Lean Startup by Eric Ries'

______ [outcomeoptional] -> ______ [output]

______ [Para/Razón optional] -> ______ [quiero output]

Ejemplo
quiero ver el contenido de mi carrito de compras.

Lean Startup, es una metodologías para crear productos para StarpUp, se

concentran en el desarrollo e identificación de clientes.
INVEST: Características de una buena HU
En 2003 Bill Wake desarrolló un • I - Independent (independiente)
método llamado INVEST para • N - Negotiable (negociable)
asegurar la calidad en la escritura
de HU. • V Valuable (valiosa)
El método sirve para comprobar la • E - Estimable (estimable)
calidad de una historia de usuario • S - Small (pequeña)
revisando que cumpla una serie • T - Testable (comprobable)
de características:
 INVEST: Características de una buena HU
•I de Independiente, Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo
cual facilita el trabajo posterior del equipo). Resaltar que las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.
I

•N de Negociable, Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el
cliente o el usuario durante la fase de conversación. Por tanto, se debe evitar historias de usuario con demasiados detalles porque limitaría la conversación acerca de las mismas.
N

•V de Valioso: Uno de los principios ágiles es entregar software valioso. Queremos crear algo valioso para alguien, idealmente tanto para el usuario como para la empresa. En realidad, el
experto en UX necesita equilibrar los objetivos comerciales con las necesidades del usuario.
V

•E de Estimable, Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o propietario del producto a priorizar y planificar su
implementación. La estimación generalmente la realizará el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño
E es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).

•S de Small (pequeñas) Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una
descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación. Las HU grandes, son comúnmente llamadas Epic’s o Epicas.
S

•T de Testeable, La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa
que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.
T
 Historias técnicas o elementos no funcionales
Se require ______ porque ____________
Se refiero a cosas que deben hacerse pero que no son un entregable ni están directamente
relacionadas con ninguna historia específica, y no son de valor inmediato para el Product Owner.
• Se requiere Instalar un servidor de compilación continua:
• Por qué debe hacerse: porque ahorra cantidades inmensas de tiempo a los desarrolladores y reduce el riesgo
de problemas explosivos de integración al final de la iteración.
• Se requiere Escribir una descripción general del diseño:
• Por qué debe hacerse: porque los desarrolladores olvidan constantemente el diseño general, y entonces
escriben código inconsistente. Necesitan una visión global documentada para mantener a todo el mundo en la
misma línea de diseño.
• Se requiere Refactorizar la capa de acceso a datos:
• Por qué debe hacerse: porque la capa de acceso a datos se ha vuelto realmente desordenada y le está
costando tiempo a todo el mundo debido a la confusión y los errores innecesarios. Limpiar el código ahorraría
tiempo a todo el mundo y mejoraría la robustez del sistema.
• Se requiere Actualizar Jira (seguimiento de errores)
• Por qué debe hacerse: la actual versión es demasiado lenta y falla demasiado. Actualizar a una nueva versión
ahorrará tiempo a todo el mundo.

Tomado de Libro Scrum y XP desde las Trincheras

Historias técnicas o elementos no funcionales
Se pueden agregar a la pila del producto, pero complica la priorización y mantenimiento
por el Dueño de Producto. Es como comparar peras con manzanas.
• Intentamos evitar las historias técnicas. Busca efusivamente formas de transformar las
historias técnicas en historias normales con valor de negocio mensurable.
• Si no podemos transformar una historia técnica en una historia normal, intentamos ver
si es posible hacerla como una tarea dentro de otra historia.
• Si lo anterior falla, definirla como historia técnica y mantener una lista separada con
dichas historias. Permitimos al Dueño de Producto que vea dicha lista, pero no que la
modifique.
Tomado de Libro Scrum y XP desde las Trincheras (Henrik Kniberg)

¿Deben existir las Historias Técnicas? Javier Garzas

Tipos de Historias Técnicas
• Arquitectura: construyen elementos como las API's que crean la estructura, funcionamiento e interacción entre distintas las partes
del software. Ejemplo: "Implementar un sistema de login seguro".
• Infraestructura de producto: historias que son consumidas directamente por historias de usuario. Esto podría incluir
infraestructura nueva y/o modificada, y oportunidades de refactorización originada por alguna necesidad funcional. Ejemplo:
"Preparar los servidores de base de datos y web".
• Infraestructura del equipo: historias que respaldan al equipo en su capacidad para entregar software. Suelen ser historias para
herramientas y marcos de pruebas, métricas, diseño, planificación... y también pueden implicar que el equipo "desarrolle" o
"compre e instale" algo. Ejemplo: "Preparar un sistema de integración continua"
• Refactorización: estas son historias que representan candidatos para refactorizar, como por ejemplo lo es la deuda técnica. Pero
no solo el código necesita de refactorización, también puede incluir diseños, automatización, herramientas y cualquier
documentación de proceso. Ejemplo: "Homogeneizar el código de la función de cálculo de préstamos".
• Spikes: historias de exploración limitadas en tiempo que dan respuesta a una cuestión, o reúnen información para una toma de
decisión posterior o el diseño de una solución. Ejemplo: "Evaluar Oracle versus SQL/Server". o
• Spike técnico: si no estamos seguros de cómo desarrollar algo desde un punto de vista técnico creamos este tipo de spike, una breve actividad
que se centra en encontrar un enfoque de desarrollo, en determinar la factibilidad y el impacto de las estrategias de diseño. O
• Spike funcional: sirven a los equipos para descubrir los detalles de las funcionalidades y los diseños a través de la creación de prototipos y
llegar a entender exactamente lo necesita el cliente.
De Temas y Epics hasta Tareas

Se denomina epic a una superhistoria

de usuario que se distingue por su gran
tamaño de alta granuralidad
A medida que aumenta su prioridad y se
acerca al momento de su
implementación, el equipo la
descompone en historias de usuario con
un tamaño más adecuado para ser
gestionada con los principios y técnicas
ágiles: estimación y seguimiento
cercano (normalmente diario).
Temas, representan una colección Epics
o Historias de Usuario.
Información de Historias de Usuarios

X
 Información de Historias de Usuarios

Valor de
Negocio

Prioridad

Estimación
Riesgo
(Costo)

http://www.pmoinformatica.com/2013/04/que-son-las-historias-de-usuario-7.html
User-Persona
La técnica se basa en la idea de conocer a los usuarios del producto que vamos a construir mediante
arquetipos descritos como personajes de ficción, como por ejemplo una representación realista de la
audiencia clave de nuestra web o aplicación.

Tomado de User Experience Mapping, Peter W. Szabo

Historias de Usuarios: Prioridad

Valor de X
Negocio

Prioridad

Estimación
Riesgo
(Costo)
Valor de negocio
• La información "valor" representa el valor de negocio que aporta una
HU una vez realizada.
• Representa "cuánto dinero está dispuesto a pagar nuestro cliente
por esa funcionalidad".
• El valor de negocio es muy importante para priorizar correctamente,
focaliza al equipo de desarrollo en todo momento en aquello que es
importante construir y maximiza el valor y la satisfacción percibida
por el cliente en cada sprint.
Valor de negocio
Como se puede medir:
• El valor se puede medir con: serie de Fibonacci, escala de numero
naturales por ejemplo escalas del uno al 10 ó del uno al 100, etc.
• Una forma muy estimulante es repartir billetes del Monopolio por el
valor total del proyecto a cada uno de los usuarios de negocio
involucrados, y que estos repartan el dinero en función del valor que
le atribuyen a cada historia de usuario.
• Otra forma es usar cartas de planning poker con la serie de Fibonacci
similar a la estimación del esfuerzo que hace el equipo, entre el
producto owner y el equipo de negocio.
Riesgo
• El riesgo es algo que todavia no ha ocurrido pero que puede poner en
peligro la realización el Proyecto.
• Riesgos comunes en proyectos de software:
• No cumplir con los plazos programados.
• Que la técnología no cumpla con las expectativas.
• Qué lo que se implemente no sea lo que los clientes/usuarios quieren.
• Riesgos que se mitigan en las HU:
• El riesgo de cada HU es determinado por el equipo.
• Con base al conocimiento y experiencia en la tecnologia y dominio (negocio)
• Pueden ver riesgos
Riesgo: Mitigación

Riesgo Mitigación
No cumplir con los plazos programados. ??
Que la técnología no cumpla con las Spike o Pruebas de Concepto
expectativas.
Qué lo que se implemente no sea lo que los Mockup Prototipos
clientes/usuarios quieren.
Estimación de Esfuerzo
Esfuerzo necesario para completar una HU.
• Ayuda en la priorización de las mismas por parte del propietario del
producto
• Permite al equipo hacer el corte en la pila de producto de qué historias
caben en el sprint.
Cómo se estima
• La estimación ágil se basa en la estimación relativa, y una buena serie para
la estimación de historias de usuario es la serie de Fibonacci modificada
• Es un hecho que para historias de usuario pequeñas la incertidumbre en la
estimación es mucho menor que para las historias grandes, y mientras el
tamaño de las historias crece linealmente la incertidumbre crece
exponencialmente.
 Estimación ágil: Quién lo hace
• La estimación la debe realizar el Todo el equipo de desarrollo.
• Reforzar el compromiso de todo el equipo respecto a las fechas que dan al
cliente.
• Reforzar el compromiso de cada miembro del equipo respecto al resto.
• Hacer que todo el mundo se sienta oído.

https://proyectosagiles.org/2009/07/01/estimacion-planificacion-agil-quinto-encuentro-agil-barcelona/
 Estimación ágil: Unidad de Medida
• La estimación se puede realizar utilizando alguna de las siguientes
unidades:
• Días ideales: los días necesarios para que el equipo pueda completar un
objetivo, sin considerar interrupciones.
• Para pasar a días reales hay que aplicar un factor de corrección que puede ir del 60 %
al 70 % de dedicación real al proyecto. Asimismo, habrá que tener en cuenta un
margen para imprevistos como bajas por enfermedad, etc.
• Puntos de historia de usuario: la complejidad que tiene cada historia de
usuario. Un equipo en un proyecto determinado es capaz de completar un
número semi-regular de puntos de historia cada iteración (“velocidad”).

https://proyectosagiles.org/2009/07/01/estimacion-planificacion-agil-quinto-encuentro-agil-barcelona/
 Estimación ágil: Planning Pocker
Una de las técnicas más utilizadas en
procesos agiles.
Se recomiendan diversas series para
la estimación
HU: Serie de Fibonacci modificada, para
estimas HU.
Epics: Tallas de camisas.

theagilebox.com
Los valores representan el peso/ esfuerzo/complejidad para terminar una historio de usuario.
Estimando con Planning Pocker
1. El cliente toma un historia de usuario, la lee y explica

2. El equipo le hace preguntas para entender su alcance (Identificar criterios de aceptación)

3. Cada miembro del equipo piensa en el esfuerzo necesario para completar la HU (en secreto)

4. Todos muestran sus tarjetas simultáneamente (evitar sesgos)

5. Las personas que están más alejadas del consenso explican por qué su votación es más alta o mas baja.

6. El equipo vuelve a votar, hasta que alcanza un acuerdo. No hay democracia

Planing Pocker: Tip’s

• Elegir un objetivo de tamaño típico en el proyecto como patrón con

el que comparar el resto de objetivos y asignarle una puntuación de
carta también media (por ejemplo un 5).
• Puede ser conveniente no jugar con las cartas más altas, ya que el
error de estimación es mucho mayor.
• Estimación relativa: Comparar el tamaño que se va dando a cada
objetivo respecto al de otros (triangulación).
Planing Pocker: Tip’s

• Elegir un objetivo de tamaño típico en el proyecto como patrón con

el que comparar el resto de objetivos y asignarle una puntuación de
carta también media (por ejemplo un 5).
• Puede ser conveniente no jugar con las cartas más altas, ya que el
error de estimación es mucho mayor.
• Estimación relativa: Comparar el tamaño que se va dando a cada
objetivo respecto al de otros (triangulación).
Historias muy grandes o historias muy
pequeñas.
Para propósitos de planificación, las historias deben abarcar una o dos
semanas de tiempo del programador.
Elegimos ese número para darle al cliente un buen control sobre el
alcance, pero también porque las estimaciones del programador son
bastante buenas en ese rango de tiempo.
Cuando un programador mira una historia, pone los ojos en blanco y
murmura: "Eso podría ser un mes, tal vez seis semanas", estamos
bastante seguros de que realmente no sabe cómo hacerlo. Entonces le
pedimos al cliente que divida la historia.
Historias muy grandes o historias muy
pequeñas.
• Por lo general, es fácil dividir una gran historia en dos o más pequeñas.
• A menudo, la historia tiene una parte muy importante y una parte menos importante: ese es
un buen lugar para dividir.
• Otras veces, la historia cubre varios casos relacionados: considere hacer de cada uno una
historia.
• Clientes, no se preocupen por no conseguirlo todo. Puede seleccionar todas estas
historias para implementarlas si lo desea. Solo tenemos que dividirlos en trozos
pequeños para estimarlos.
• Otras veces, las historias serán demasiado pequeñas.
• Cuando las historias obtienen estimaciones de solo un par de días o menos,
pueden retrasar el proceso de planificación. Es mejor juntar historias
relacionadas y estimarlas como grupo.
• Use su propio criterio aquí, pero si la planificación parece ralentizarse o se vuelve
muy rutinaria, puede ser el momento de poner algunas historias en un grupo.
Nuevas historias
• Por lo general las hu podran ir identificandose durante el Desarrollo,
se debe escribir su historia y agregarla a la lista pendientes para
planificarlas
Prioridad
• Aunque todas las historias de usuario puedan ser importantes, para poder focalizarnos en el
trabajo de forma eficiente, es necesario destacar aquellas que den mayor valor al sistema, por
tanto, las historias de usuario deben de estar priorizadas.
• Estas deben de tener asignadas un valor que intervenga en el sistema de priorización, un valor
asignado por el propietario del producto y se basará básicamente en las siguientes variables:
• Beneficios de implementar una funcionalidad
• Pérdida o coste que demande posponer la implementación de una funcionalidad.
• Riesgos de implementarla.
• Coherencia con los intereses del negocio.
• Valor diferencial con respecto a productos de la competencia.
• Uno de los aspectos a tener en cuenta es que la definición de "valor" puede variar para cada uno
de nuestros clientes.
• Más allá de un sistema de clasificación de tipo prioridad alta, media o baja es muy recomendable
utilizar algún tipo de escala cualitativa, una que tenga un significado intrínseco.
• Para esto existen diversas técnicas de priorización. MoSCoW
 Priorización con MoSCoW
Su finalidad es obtener un entendimiento común entre cliente y el equipo del proyecto, en
concreto sobre la importancia de cada historia de usuario.

•M - MUST HAVE – (es necesario): Se debe tener la funcionalidad implementada en la solución,

sino esta fallará o la solución no puede ser considerada un éxito.
Mo

•S - SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la

solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si
S no existe pero debería de haber causas justificadas para no implementarla.

•C - COULD HAVE (podría implementarse): Se podría tener - Es deseable, por tanto sería
conveniente tener esta funcionalidad implementada en la solución, dependerá de las
Co posibilidades de los tiempos y el presupuesto del proyecto.
https://railsware.com/blog/moscow-prioritization/
•W - WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy
baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante.
W Posteriormente, cuando cobre importancia, puede pasar a alguno de los estados anteriores.

Definido por primera vez en 2004 por Dai Clegg de Oracle UK Consulting en el libro Case Method Fast-Track: A RAD Approach
Priorización con MoSCoW
Debe tener Debería tener Podría tener No tendré este tiempo

•No tiene sentido entregar en la fecha •Importante pero no vital •Los requisitos de Podría tener se •Estos son requisitos que el equipo del
prevista sin esto; si no se entrega, no •Puede ser doloroso dejar de lado, definen como: proyecto ha acordado que no se
tendría sentido implementar la pero la solución sigue siendo viable •Deseado o deseable pero menos cumplirán (como parte de este
solución en la fecha prevista •Puede necesitar algún tipo de importante plazo). Se registran en la Lista de
•No es legal sin eso solución alternativa, por ejemplo, •Menos impacto si se deja fuera (en requisitos priorizados donde ayudan a
•Inseguro sin él gestión de expectativas, alguna comparación con un Debería tener) aclarar el alcance del proyecto. Esto
ineficiencia, una solución existente, evita que se reintroduzcan de manera
•No se puede ofrecer una solución •Estos son los requisitos que
papeleo, etc. La solución puede ser informal en una fecha posterior. Esto
viable sin ella proporcionan el principal grupo de
solo temporal también ayuda a gestionar las
•Haga la pregunta '¿qué sucede si no contingencia, ya que solo se
expectativas de que algunos
se cumple este requisito?' Si la •Una forma de diferenciar un requisito entregarían en su totalidad en el
requisitos simplemente no se incluyan
respuesta es 'cancelar el proyecto; no de Debería tener de un Poder tener es mejor de los casos. Cuando ocurre un
en la solución implementada, al
tiene sentido implementar una revisando el grado de dolor causado problema y la fecha límite está en
menos no esta vez. Won't Haves
solución que no cumpla con este por el incumplimiento del requisito, riesgo, uno o más de los Podría tener
puede ser muy poderoso para
requisito', entonces es un requisito medido en términos de valor brindan la primera opción de lo que
mantener el enfoque en este
imprescindible. Si hay alguna forma comercial o número de personas se eliminará de este período de
momento en los May Haves más
de evitarlo, incluso si es una solución afectadas. tiempo.
importantes, Should Haves y
manual y dolorosa, entonces es un particularmente en los Must Haves.
requisito que debería tener o podría
tener. Categorizar un requisito como
Debería tener o Podría tener no
significa que no se
cumplirá; simplemente esa entrega
no está garantizada.
 Priorización con MoSCoW
• En un proyecto tradicional, todos los requisitos se tratan como
imprescindibles, ya que la expectativa se establece desde el principio
de que todo se entregará y que, por lo general, el tiempo (la fecha de
finalización) se deslizará si se encuentran problemas. Los proyectos
DSDM tienen un enfoque muy diferente; fijando tiempo, costo y
calidad y características de negociación. Al final de Fundaciones, se
confirman las fechas de finalización del proyecto y del primer
Incremento del Proyecto.
• MoSCoW para el proyecto
• MoSCoW para el incremento del proyecto
• MoSCoW para este Timebox
https://www.agilebusiness.org/page/ProjectFramework_10_MoSCoWPrioritisation
Prioridad: ROI
• Otra herramienta que ayuda al propietario del producto a priorizar la pila
de producto de forma adecuada es el cálculo del ROI (Return of
Investment) o retorno de la inversión:
• Valor de negocio: el valor relativo del elemento para negocio o el cliente.
• Tamaño: estimación en puntos de historia del esfuerzo necesario teniendo
en cuenta complejidad y tamaño.
ROI = Valor de negocio / Tamaño

• El ROI aplicado de forma descendente resulta en una excelente guía para

priorizar la pila, cuanto más alto el retorno de inversión tanto más alta es la
prioridad del elemento.
 Prioridad:Modelo de Kano
Esta técnica fue desarrollada por Noriaki Kano, experto en gestión de
calidad y satisfacción del cliente a finales de los `80. Con esta técnica
podemos determinar que funcionalidades son realmente importantes
para los usuarios y cuanto lo son.
• Funcionalidades Básicas (Basic, must have) Requerimientos mínimos
imprescindibles que un producto debe tener. El cliente da por
supuesto que el producto tiene estas funcionalidades. Sin estas
funciones, los usuarios no usaran nuestro producto, pero desarrollar o
perfeccionar en exceso estas funcionalidades, no aumenta la
satisfacción del cliente.
• Funcionalidades Lineales (Linear features). Estas
funcionalidades ofrecen satisfacción a los usuarios, y esta satisfacción
es directamente proporcional al nivel de desarrollo de las
funcionalidades de esta categoría. Cuanto mejor desarrollada esta la
funcionalidad, clientes más felices. Normalmente son funcionalidades
que el cliente pediría.
• Funcionalidades Emocionales y sorprendentes (Exciters and
delighters) Son las funcionalidades inesperadas que gustan y
satisfacen muchísimo. Son funcionalidades atractivas que nos dan
ventaja competitiva, fidelizan y generan placer.
• Funcionalidades Indiferentes (Indifferent): Características que no
afectarán al consumidor de ninguna manera y deben ser eliminadas.

En ISO 9001 la meta no es la calidad, es aumentar la satisfacción del cliente

 Prioridad:Modelo de Kano
Los requisitos básicos no se aportan al 100% y
en perfectas condiciones, siempre habrá una
insatisfacción, por pequeña que sea. No es nada
fácil obtener elevados niveles de satisfacción
actuando sólo sobre este tipo de características.
Los requisitos de desempeño evolucionan
linealmente con la satisfacción. Desde un
cumplimiento 0 de estos requisitos y una
insatisfacción enorme, podemos ir aumentando
la satisfacción conforme vamos proporcionando
más y mejores características de este tipo.
Los requisitos de deleite (delighters) siempre
sitúan la satisfacción por encima de la situación
neutral. A medida que vamos proporcionando
características de este tipo, la satisfacción
aumenta mucho más rápidamente de lo que
conseguimos aportando características de
desempeño.

En ISO 9001 la meta no es la calidad, es aumentar la satisfacción del cliente

Prioridad: Método de los 100 puntos
• El método de los 100 puntos fue desarrollado en el 2003 por Dean
Leffingwell y Don Widrig.
• Dicho método implica otorgar 100 puntos al cliente a fin de que los
pueda utilizar para votar por las características que consideren más
importantes.
Prioridad: Dinero de Monopoly
• El dinero de Monopoly es una técnica que consiste en darle al cliente
dinero del juego Monopoly, o “dinero falso”, equivalente a la cantidad
del presupuesto del proyecto, solicitando que lo distribuyan entre las
historias de usuario que están a consideración.
• De esta forma, el cliente prioriza con base en lo que está dispuesto a
pagar por cada historia de usuario.
Prioridad: Esquemas simples
• Los esquemas simples implican etiquetar elementos como prioridad
“1”, “2”, “3” o “alta”, “media” y “baja”, y así sucesivamente. Aunque
se trata de un método sencillo y directo, puede llegar a ser
problemático, ya que a menudo hay una tendencia en etiquetar todo
como prioridad “1” o “alta”.
• Incluso los métodos de priorización tales como “alta”, “media” y
“baja” pueden encontrarse con dificultades similares
Prioridad No => Importancia
• La importancia que el Dueño de Producto da a esta historia. Por
ejemplo, 10. O 150. Más alto = más importante.
• Suelo evitar el término “prioridad” porque típicamente “1” se
considera la “máxima prioridad, lo que es muy incómodo si
posteriormente decides que algo es más importante. ¿Qué prioridad
le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?

Henrik Kniberg, Consultor de Spotify Scrum y XP desde las trincheras

User Story Mapping
• User Story Mapping es una técnica que consiste en organizar
el Product Backlog en dos dimensiones con el objetivo de construir
un Roadmap. Este mapa se compone de dos ejes, en uno de ellos las
releases(vertical) y en el otro las funcionalidades (horizontal).
• Es por ello que tras la fase de Agile Inception, vamos a construir el
mapa utilizando un tablero de post-its, en el que identificamos la
prioridad de las historias de usuario, y el orden de implementación
agrupado en releases. Esto permite mejorar la visión de producto y
construir una hoja de ruta clara y compartida por el equipo.
Blog en Medium
User Story Mapping
• 1. Identificar objetivos
• Lo primero que debemos de realizar es definir nuestros objetivos, para ello escribimos en tarjetas las ideas a muy alto nivel, de lo que representa el
producto para negocio.
• 2. Identificar Actividades
• A continuación debemos de identificar las actividades de alto nivel a partir de los objetivos definidos en el punto anterior. Estas actividades
denominadas “épicas”, deben de posicionarse horizontalmente de tal manera que sigan un orden literario, como si de un storytelling se tratara. Esto
nos proporciona una primera foto del producto.
• 3. Describir el timeline
• A continuación, seguimos descomponiendo las épicas en historias de usuario más pequeñas, que sean más concretas y definan funcionalidades más
específicas. Estas historias compondrán nuestras releases, las que iremos seleccionando en cada Sprint.
• Para ello se colocan las historias debajo de su épica y las ordenamos en un orden lógico desde la perspectiva del usuario.
• 4. Ordenar las historias
• Una vez descompuestas y ordenadas debemos desplazarlas a lo largo del eje vertical, quedando arriba las más importantes y abajo las menos
importantes. Para ello se puede usar métodos como MoSCoW, del que hemos hablado en este blog.
• 5. Identificar Releases
• Una vez descompuestas y ordenadas, debemos de focalizarnos en las historias superiores que definirán el conjunto de funcionalidades necesarias
para definir el mínimo producto viable (MVP). De esta manera trazamos líneas horizontales, agrupando las historias de usuario en “releases” que
marcarán nuestra hoja de ruta y aquellas entregas de funcionalidad que debemos de ir desarrollando. Se pueden mover historias para que el
“release” tenga sentido y sea consistente.
User Story Mapping
• Como hemos podido comprobar, la técnica
de User Story Mapping, permite de una
manera visual y colaborativa definir el mapa
de funcionalidades de un producto. De un
solo vistazo, tenemos el ‘big picture‘ de
nuestro sistema en una sola instantánea,
descompuesto de las ideas más generales a
las más específicas. Además, la dinámica del
ordenar por prioridad, nos permite establecer
las necesidades del negocio.
• Una vez que tenemos plasmado nuestro
mapa es muy sencillo agrupar las
funcionalidades en releases para tener una
hoja de ruta que seguir, aunque este proceso
no debe ser estático, si no que nuestro
mapping puede evolucionar en función de las
necesidades del proyecto.
User Story Mapping: Herramientas
• https://www.featuremap.co/es
User Story Mapping: Herramientas
• https://storiesonboard.com/azure-devops-story-mapping.html
User Story Mapping: Herramientas
• https://storiesonboard.com/azure-devops-story-mapping.html
User Story Mapping: Herramientas
• https://specmap.cc/
• https://marketplace.visualstudio.com/items?itemName=techtalk.spec
map
User Story Mapping: Herramientas
• https://specmap.cc/
• https://marketplace.visualstudio.com/items?itemName=techtalk.spec
map
Criterios de aceptación
• Después de 50 años de historia de ingeniería de software hemos llegado a la conclusión de que los criterios de validación, que a veces se traducen en
pruebas, son un excelente lenguaje para detallar requerimientos funcionales, y es por ello que toman una gran importancia en las historias de
usuario.
• Para medir la calidad de un criterio de aceptación se utiliza el método SMART en el que se han de cumplir en lo máximo posible los siguientes
criterios:
S - Specific (Específicos)
M - Measurable (Medibles)
A - Achievable (Alcanzables)
R - Relevant (Relevantes)
T - Time-boxed (Limitados en el tiempo)
• Se suelen escribir en forma de checklist o descripción de un flujo en cuanto se obtengan historias de usuario susceptibles de entrar en un sprint, y se
acaban de refinar en la planificación de sprint.
• Los criterios de validación ayudan al equipo de desarrollo a entender el funcionamiento del producto, de manera que estimarán mejor el tamaño de
la historia subyacente y, cuando el equipo se encuentre en fase de desarrollo servirá de guía cuando el desarrollador tenga que tomar una decisión,
tomará la más acertada.
• Finalmente el propietario de producto comprueba en la revisión de sprint, a través de estos criterios de validación y la definición de hecho, si cada
una de las historias de usuarios se puede dar como hecha y finalizada.
• Los criterios de validación pueden escribirse con el lenguaje natural, tal como el propietario del producto se expresa, existen diferentes formatos para
escribirlos:
Criterios de aceptación
• Los criterios de validación pueden escribirse con el lenguaje natural,
tal como el propietario del producto se expresa, existen diferentes
formatos para escribirlos:

Comprobar [Criterios]

Demostrar [Comportamiento esperado]

Verificar que cuando [Rol] hace [Acción] consigue [Resultado / Comportamiento esperado]

Dado que [Contexto] y adicionalmente [Contexto] cuando [Evento]

entonces [Resultado / Comportamiento esperado]
Criterios de aceptación
• Una opción excelente es escribirlos con la técnica del
comportamiento por escenarios propia de BDD (Behavior Driven
Development) y con gherkin, un lenguaje específico creado
especialmente para las descripciones de comportamiento de
software. La sintaxis de gherkin es la siguiente:
(Scenario) Escenario [Número de escenario] [Titulo del escenario]:
(Given) Dado que [Contexto] y adicionalmente [Contexto],
(When) cuando [Evento],
(Then) entonces [Resultado / Comportamiento esperado]
Criterios de aceptación
• Derivado de esta sintaxis los elementos de los criterios de aceptación son:
• Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al
escenario asociado a la historia.
• Título del escenario: Describe el contexto del escenario que define un
comportamiento.
• Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan
el escenario.
• Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el
escenario.
• Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por
el usuario, la consecuencia es el comportamiento del sistema en esa situación
Criterios de aceptación
• Ejemplo de una historia de usuario y sus criterios de validación escritos en
Gherkin:
• Como cliente Quiero retirar dinero del cajero automático Para poder evitar ir al
banco a hacer una cola
Escenario 1: Cuenta tiene crédito
• Dado que la cuenta tiene crédito y que la tarjeta es válida y que el cajero tiene
dinero disponible Cuando el cliente pide dinero Entonces la cuenta es debitada y
el dinero es entregado al cliente y el cliente recupera su tarjeta
Escenario 2: La cuenta excede el límite negativo acordado con el banco
Dado que la cuenta excede el límite negativo acordado con el banco y que la tarjeta
es válida Cuando el cliente pide dinero Entonces el cajero muestra un mensaje
negando el pedido y el dinero no es entregado al cliente y el cliente recupera su
tarjeta
Consejos de buenas prácticas:
• Siempre escribir las historias con el
“qué”, evitar el “cómo”.
• No escribir una descripción
exhaustiva, solo lo justo.
• Escribir el criterio de validación y ser
suficientemente explícito.
• Estimar todas las historias, no hacerlo
puede crear falsas expectativas.
• No fiar toda la información en las
tarjetas, a veces es buena idea una
documentación externa como una
wiki por ejemplo.
• Nunca dar una historia por finalizada
cuando está “prácticamente hecha”.
Pruebas de Aceptación
• Las pruebas de aceptación permiten al cliente saber cuándo funciona
el sistema y decirle a los programadores lo que se debe hacer.
• Clientes, recuerden que tienen derecho a ver el progreso en forma de
un sistema en funcionamiento, pasando las pruebas repetibles que
especifiquen. Bueno, aquí está la parte de responsabilidad de eso:
especificar las pruebas de aceptación.
• La responsabilidad del cliente es proporcionar esas pruebas de
aceptación como parte de cada iteración. Si puede llevarlos a los
programadores a la mitad de cada iteración, el proyecto irá más
rápido. Obtendrá más valor comercial antes de la fecha límite. Es una
promesa.
Pruebas de Aceptación
• ¿Qué debo probar? probablemente estás preguntando. La respuesta oficial de XP es, solo tienes que probar
las cosas que quieres que funcionen.
• Los programadores de Smart XP extraerán la información de la hoja de cálculo automáticamente y la leerán
en el sistema. Algunos proyectos utilizan valores calculados manualmente que ingresa alguien del equipo.
• Algunos clientes dan números de entrada a los programadores y verifican la salida con solo leerla. Hay un
problema importante con este que debe mencionarse. Este es un anti-patrón, una mala idea, llamado Guru
Checks Output. Verificar la salida de una computadora es muy propenso a errores. Es fácil mirar los números
y decidir si parecen correctos. También es fácil equivocarse al hacer eso. Es mucho mejor tener las
respuestas esperadas por adelantado, incluso si tienen que calcularse a mano.
• Una cosa más. Los derechos se refieren a pruebas repetibles. Todas las pruebas en un proyecto XP deben
automatizarse. Le brindamos la capacidad de moverse muy rápidamente y de cambiar sus requisitos en
cualquier momento que lo necesite. Esto significa que el código cambiará rápidamente. La única forma de
moverse rápidamente con confianza es tener una sólida red de pruebas, tanto unitarias como de aceptación,
que aseguren que los cambios en el sistema no rompan las cosas que ya funcionan. Las pruebas de
aceptación deben ser automatizadas: insiste en ello como tu derecho.
• No nos gustan mucho las advertencias y predicciones espantosas, pero aquí hay una que es segura: los
defectos en su sistema ocurrirán donde no realice pruebas. Lleve sus pruebas de aceptación al límite, en
amplitud y profundidad. Estarás contento de haberlo hecho.
AUTOMATIZAR LAS PRUEBAS
• Las pruebas deben estar automatizadas o no obtendrá sus insignias de mérito XP. Sin embargo, hay muchas formas de hacerlo. La
elección específica depende de sus programadores. Aquí hay algunas ideas para comenzar:
• Si el programa es un programa por lotes, que lee entradas y produce salidas, cree una serie estándar de archivos de entrada,
ejecute el programa, verifique la salida manualmente (y con cuidado) una vez y luego escriba scripts simples que comparen la
salida de la prueba con el bien conocido. salida.
• Utilice el truco anterior para informes y listas de cualquier programa, por lotes o no.
• Construya sobre el marco de prueba de xUnit . Escriba pruebas funcionales como programas. Mejor aún, cree un pequeño
lenguaje de secuencias de comandos que los programadores puedan usar. Luego, cultívelo y hágalo más fácil hasta que los clientes
puedan usarlo. Tal vez proporcione una pequeña GUI que muestre más detalles que la barra roja / barra verde.
• Permita que los clientes configuren pruebas en su hoja de cálculo favorita, luego lea la prueba y ejecútela. Algunos equipos leen
los datos de la hoja de cálculo de los archivos exportados. Algunos utilizan la función de "automatización" de la hoja de cálculo
para leer la información. ¡Algunos exportan los resultados de las pruebas a la hoja de cálculo! Esto no es tan difícil como parece,
échale un vistazo y fíjate si está dentro de las capacidades de tu equipo.
• Construya un registrador de entrada en el producto, deje que los clientes lo utilicen una vez para definir una prueba. Derrame la
salida a archivos y compruébelos automáticamente.
• Utilice herramientas sencillas basadas en archivos como grep y diff y Perl para comprobar los resultados. Puede automatizar
muchas pruebas muy rápidamente con estas herramientas.
• Siempre cree sus pruebas de aceptación para que sean automáticas, pero cree la automatización de forma simple e incremental
según la necesite. Es fácil dejarse atrapar por invertir en la automatización de pruebas en lugar de en valor comercial. Automatice
las pruebas, pero no se exceda.
OPORTUNIDAD
• Las pruebas de aceptación realmente deben estar disponibles en la misma
iteración en la que está programada la historia. Piénselo: desea calificar el
desarrollo en función de la realización de las historias, y la única forma de
saber si realmente se terminaron es ejecutar las pruebas.
• Programadores, tienen derecho a saber qué se necesita. Insista en este
derecho en forma de pruebas funcionales automatizadas. Estaras contento
de haberlo hecho.
• Clientes, tienen derecho a ver el progreso de un sistema en ejecución, cuyo
funcionamiento se ha comprobado mediante las pruebas automatizadas
que especifique. Insista en este derecho y haga su parte proporcionando la
información necesaria.
División de HU y Mantenimiento del Product Backlog
• Como parte del flujo continuo de toma de
requisitos a través de historias de usuario existe la
reunión de refinamiento para mantener
actualizada la pila del producto.
• Es una reunión propia del propietario del producto,
en la que junto con el equipo, trabaja en el
refinamiento de la pila del producto. En esta
reunión, tal como se ve en la imagen de la derecha,
se añaden, re-priorizan, eliminan y dividen
elementos de la pila.
• Su objetivo es garantizar que las historias de
usuario susceptibles de ser desarrolladas en corto
plazo tengan un nivel de detalle y una estimación
de esfuerzo suficiente para que el equipo pueda
comprometerse.
• La experiencia muestra que las historias de usuario
más pequeñas mejoran el flujo y que las historias
de usuario grandes implican una mayor
incertidumbre funcional y una mayor dificultad
para ser estimadas.
División de HU y Mantenimiento del Product Backlog
División de historias de usuario

Mapa Mental en Español

División de historias de usuario
• Estrategia 1 - División por pasos de flujo de trabajo: para historias de usuario que incluyen algún tipo de flujo de trabajo, estas se pueden dividir según los pasos individuales del
flujo.
• Estrategia 2 - División por reglas de negocio: historias de usuario que conllevan implícita o explícitamente reglas de negocio se pueden dividir por estas reglas. Frecuentemente los
casos de test implican importantes reglas de negocio, por tanto para esta división podemos basarnos en las pruebas.
• Estrategia 3 - División por happy/unhappy flow: las funcionalidades usualmente describen un flujo en que todo va bien y otros flujos en que se tratan desviaciones, excepciones o
problemas, por tanto estos flujos también son una forma de dividir historias grandes.
• Estrategia 4 - División por opciones/plataformas de entrada: en caso de productos que han de rodar en diferentes plataformas, como portátiles, tablets, móviles... pueden
dividirse las historias de usuario por su plataforma de entrada.
• Estrategia 5 - División por tipos de datos o parámetros: algunas historias de usuario se pueden dividir por sus parámetros de entrada o salida, como por ejemplo las diferentes
opciones de una búsqueda.
• Estrategia 6 - División por operaciones: Hay historias que involucran las típicas operaciones de alta, lectura, modificación y baja (CRUD - create, read, update & delete),
operaciones que pueden ser otra forma de división.
• Estrategia 7 - División por casos/escenarios de test: a veces hay historias que son difíciles de dividir funcionalmente, en este caso puede ayudar a preguntarse cuáles van a ser los
escenarios de test de la historia y dividir por estos. Los escenarios pueden ser combinación de reglas de negocio, flujos que van bien y con excepciones, plataformas de entrada,
etc.
• Estrategia 8 - División por roles: para historias de usuario que cubren diferentes roles, estas se pueden dividir por las funcionalidades propias de cada rol.
• Estrategia 9 - División por optimizar ahora o más tarde: las historias de usuario pueden ser implementadas en diferentes grados de perfección y optimización de la funcionalidad
descrita.
• Estrategia 10 - División por compatibilidad de navegador: las historias de usuario para aplicaciones web a menudo tienen que trabajar en una amplia variedad de navegadores, los
más modernos tienden a ser más compatibles con los estándares y los más antiguos suelen necesitar de personalizaciones para que todo funcione correctamente. En todas estas
estrategias la división reduce la incertidumbre, nos permite desarrollar las historias resultantes importantes y dejar historias menos importantes para desarrollos futuros
División de historias de usuario
Comparativa con otras formas de toma de
requisitos
• Historias de usuario versus casos de uso
• Historias de usuario versus requisitos funcionales
EL PROCESO DE LAS TRES C’S RON JEFFRIES
• Paso 1: Card. Escribe lo que te gustaría ver en el software.
• Paso 2: Conversation: Junta a todos los involucrados y hablen acerca
del software que se va a construir.
• Paso 3: Confirmation: Juntos todos los involucrados lleguen a un
acuerdo de como el software va a ser hecho.

• https://ronjeffries.com/articles/019-01ff/3cs-revisited/
EL PROCESO DE LAS TRES C’S RON JEFFRIES
• 1. Card (tarjeta) Escribimos una descripción rápida de la función en
una tarjeta.
• 2. Conversation (Conversación) la discutimos con nuestro cliente
(piense en el propietario del producto Scrum)
• 3. Confirmation luego creamos ejemplos concretos comprobables
para confirmar que la función hizo lo que nosotros y el cliente
queríamos

• https://ronjeffries.com/articles/019-01ff/3cs-revisited/
EL PROCESO DE LAS TRES C’S RON JEFFRIES

• https://ronjeffries.com/xprog/articles/expcardconversationconfirmati
on/
VISION DEL PRODUCTO
• Todos nos reunimos con nuestro Cliente / Propietario del producto y
hablamos sobre el producto. Qué problemas resuelve, cómo podría
resolverlos. Nos contábamos historias sobre problemas y
soluciones. Hacíamos dibujos del producto. Probablemente
hablaríamos con usuarios reales o visitaríamos sus sitios y los
veríamos trabajar. Conceptualizaríamos el producto, tratando de dar
a todo el equipo una visión bastante coherente de lo que se
necesitaba hacer. Esta sería una conversación a gran escala.
• https://ronjeffries.com/articles/019-01ff/3cs-revisited/
VISION DEL PRODUCTO
• A medida que pasaba el tiempo, más como días que semanas o
meses, comenzábamos a desarrollar ideas de funciones, o
capacidades específicas, cosas que podíamos construir. Debido a que
trabajaríamos con una cadencia de una o dos semanas, o incluso uno
o dos días más continuos por historia, rápidamente nos volveríamos
muy específicos. Esta sería una conversación a menor escala y más
enfocada.
VISION DEL PRODUCTO
• A medida que comenzamos a elegir cosas específicas para hacer a
continuación, por supuesto necesitaríamos refinar nuestra
comprensión de esas cosas. Lo haríamos siendo muy específicos sobre
lo que una característica determinada, definida por una historia
determinada, debe hacer. Lo haríamos lo más concreto posible, para
asegurarnos de que todos, Clientes y Desarrolladores, tuviéramos un
entendimiento común de lo que se debe hacer.
VISION DEL PRODUCTO
• ¿Lo haríamos escribiendo un montón de texto en una tarjeta, en un
documento o en Jira? No lo haríamos. Expresaríamos las capacidades
acordadas como ejemplos de lo que debería hacer el sistema. Siempre
que sea posible, se expresarán como pruebas de cliente ejecutables
concretas. A veces, podrían expresarse como dibujos de la GUI o algo
menos concreto, pero siempre que fuera posible, siempre estaríamos
trabajando hacia una forma muy concreta de Confirmación de que el
producto estaba haciendo lo nuevo que nos propusimos hacer.
VISION DEL PRODUCTO
• Entonces, haríamos la cosa. Cuando terminamos, uno o dos días
después, las Confirmaciones concretas estarían funcionando y
pasaríamos a lo siguiente, repitiendo el proceso.

• ¡Puede que ni siquiera haya una tarjeta!

Como escribir historias de usuario
Como escribir historias de usuario
Como escribir historias de usuario
Como escribir historias de usuario
Como escribir historias de usuario
Fase de Inicio (Exploración-Sprint 0)
• https://repository.eafit.edu.co/bitstream/handle/10784/1614/Jhoao_
Gonzalez_Diego_Anduquia_2012.pdf?sequence=3&isAllowed=y
Conceptos
En el sprint
Impedimiento
Refactorización
Deuda Técnica
Pruebas automáticas
• EXPLORACION • INICIO
• PLANIFICACION • PLANIFICACION Y ESTIMACIÓN
• ITERACIONES PARA • IMPLEMENTACIÓN
LANZAMIENTO • REVISIÓN Y RETROSPECTIVA
• PUESTA EN PRODUCCION • LANZAMIENTO
Fase de Inicio – Inception – Exploración (XP)
• Formar el Equipo Inicial
• Identificar la vision del Proyecto de acuerdo a los objetivos
empresariales
• Identificar la estrategia técnica inicial, requerimientos iniciales y
plan de lanzamiento
• Establecer ambiente de trabajo y herramientas
• Asegurar presupuesto
• Identificar riesgos
Fase de Planeación
• Priorizar requistos
• Refinar el plan de lanzamiento
• Plan de Iteraciones
• Estimación de historias de usuario
• Estimación de tareas
ITERACIONES O SPRINT
• Producir la solución potencialmente utilizable
• Atender cambios en necesidades de clients/usuarios
• Mantener o mejorar los niveles de calidad
• Probar la arquitectura lo antes possible
PRODUCCION/TRANSICION/LANZAMIENTO
• Asegurar que la solución esta lista para producción
• Asegurar que los involucrados están listos para recibir la solución
• Desplegar la solución
MEJORAS CONTINUAS
• Lograr la mission del Proyecto
• Mejorar las habilidades de los miembros del equipo
• Aprovechar la infraestructura existente
• Mejorar la infraestructura existente
• Mejorar el proceso del equipo
• Atender los Riesgos
DAD: Ciclo de vida ágil
DAD: Ciclo de vida ágil
DAD: Ciclo de vida ágil
DAD: Ciclo de vida Lean
Fase de Exploración
Definición de la Metafora del Sistema
Identificación de las historias de usuario
Experimentar con la tecnología
Estimaciones
Priorizaciones
Clientes aprender a especificar
Pruebas de Conceptos a tecnologia nueva
Si ya el equipo conoce la tecnología es una fase muy breve (pocas semanas)
• • Planeación-Exploración
• Ingeniería de Requisitos Agiles
• Estimación y Planeación
• Definición de Done
• Planeación Release, Planeación Iteración, Planeación de Tareas
• Iteración y Seguimiento
Objetivos
• Entender y poner en práctica los conceptos fundamentales que
motivan el uso de metodologías ágiles en el desarrollo de software
• Administrar un proyecto de software de tamaño mediano, utilizando
las principales técnicas propuestas por las metodologías ágiles
• Conformar un equipo de desarrollo de software para implementar
una solución siguiendo metodologías ágiles
Objetivos
• Entender y poner en práctica los conceptos fundamentales que
motivan el uso de metodologías ágiles en el desarrollo de software
• Administrar un proyecto de software de tamaño mediano, utilizando
las principales técnicas propuestas por las metodologías ágiles
• Conformar un equipo de desarrollo de software para implementar
una solución siguiendo metodologías ágiles
Agile
• https://sg.com.mx/revista/entrega-%C3%A1gil-disciplinada
• https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-
es.pdf
• Extreme Programming Installed 1st Edition
Método de Desarrollo de Sistemas dinámicos
• https://sg.com.mx/revista/entrega-%C3%A1gil-disciplinada
• https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-
es.pdf
• Extreme Programming Installed 1st Edition