Master Class: Desde la Visión hasta las Historias de usuario

Enlace a Mural - Clic aquí -

De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo

Hola a todos

Les comparto un ejemplo que desarrollé desde la Idea hasta el Sprint backlog de los primeros tres sprints. Los artefactos elaborados son;

• Elevator Pitch (Visión)
• Product Vision Board
• Ideación de posibles funcionalidades
• Asignación del valor usando la serie de Fibonacci modificada. 
• Asignación del esfuerzo usando la serie de Fibonacci modificada
• Uso del Modelo Kano de priorización para identificación de funcionalidades clave
• Elaboración del User Story Map
• Visión End-2-End
• Cálculo de la relacion Valor / Duración de cada funcionalidad
• Priorización de funcionalidades usando MoSCoW
• Identificacion del Producto Minimo Viable (MVP)
• Plan de Releases
• Roadmap del producto
• Explicacion del cálculo del tiempo y costo
• Product Backlog vertical, donde cada realese esta priorizado por la relación Valor/Duración
• División de historias de usuario de las primeras tres funcionalidades o épicas
• Identificación de los primeros tres sprints donde la velocidad promedio del equipo es aproximadamente 20 puntos de historia por sprint.

La imagen la pueden descargar en alta resolución de:

• formato png - clic aquí 
• formato pdf - clic aquí

Actualización 2022-11-10


Enlace a Mural - Clic aquí -

Tres Ejemplos de Productos concebidos de Forma Ágil - Agile Inception

Hola a todos

A mi criterio, una de las mejores formas de aprender ciertas técnicas, a parte de experimentarlas, es viendo ejemplos, es por esto que a continuación les comparto tres casos de Agile Inception de productos digitales, el resultado final es un plan de releases del cual se pueden luego detallar las historias de usuario.

Estos ejemplos fueron desarrollados por los Estudiantes de la Cohorte 2020-Sem02 de la ESPECIALIZACIÓN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE de la Unab, a quienes tuve la oportunidad de enseñarles la Materia de Metodologías y Marcos Ágiles.

Se desarrollo un caso al cual se le identificó:

• El Problema: qué es lo que intenta ser resuelto con el sistema
• La Visión: Elevator pitch
• El Vecindario: áreas y sistemas con los cuales se relacionará el sistema
• Product Vision Board: usuarios, necesidades, productos y metricas
• User Story Map con identificación del Producto Mínimo Viable - MVP: Épicas priorizadas con estimación de esfuerzo y asignación de valor
• Estimación de Tiempo y Costo
• The Go Product Roadmap: Este artefacto también puede ser conocido como el plan de releases.
• Historias de Usuario con Criterios de Aceptación: se seleccionaron algunas épicas de forma aleatoria y se les escribieron las historias de usuario, simulando un refinamiento.

Espero estos ejemplos les sean de utilidad,

Saludos ágiles

Jorge Abad.

Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor

Hola a todos

Debido a recurrentes conversaciones y aclaraciones sobre:

• Épicas
• Historias de Usuario
• MVP (Minimun Viable Product o Producto Mínimo Viable)
• Agregar Valor
• Agregar Valor Incrementalmente
• y Scrum

Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

Comencemos.

Paso 1. Durante el Inception (9) se creó el siguiente User Story Map

Paso 2. Durante el Inception (9) se realiza la estimación de cada release

Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

Release 1 - MVP	7 sprints
Release 2	6 sprints
Release 3	6 sprints

Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:

Release	Épica	Historia de Usuario
Release 1 - MVP	Formato de solicitud básico	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados
	Validar referencia personales	HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Validación centrales de riesgo 1 y 2	Pendientes por definir (10)
	Calificación	Pendientes por definir (10)
	Creación del crédito	Pendientes por definir (10)
	Desembolso a cuenta propia	Pendientes por definir (10)

Release	Sprint	Historia de Usuario
Release 1 - MVP	Sprint 1	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge
	Sprint 2	HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud
	Sprint 3	HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Sprint 4	Pendientes por definir (10)
	Sprint 5	Pendientes por definir (10)
	Sprint 6	Pendientes por definir (10)
	Sprint 7	Pendientes por definir (10)

Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

Realmente no es un punto, son varios, veamos:

1. Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
2. El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
3. El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
4. Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
5. El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:
• Es en serio, las historias usuario tienen que ser pequeñas (clic aquí)
• Consejo: Que tus Historias de Usuario no sean como Bruce Willis "Duras de Matar" (clic aquí)
6. Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
7. Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
8. Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
9. El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
10. Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volátil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial." 
11. Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
12. En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente:  "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".

Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad

Encontrando el MVP con un Roadmap y el Mapa de Afinidad

Hola a todos

Realizando talleres Producto Mínimo Viable - MVP (Minimun Viable Product), he encontrado que para cierto tipo de equipos les da dificultad emplear la técnica del User Story Map de Jeff Patton, para estos equipos he ideado esta técnica basada en el Roadmap y el Mapa de Afinidad, espero les guste y también les sirva con sus equipos.

Saludos Ágiles

Bienvenido el Feedback
Jorge H. Abad L.

Encontrando el MVP con un Roadmap y Mapa de Afinidad from Jorge Hernán Abad Londoño

Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User Story Map

Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se muestran los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton

---

Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User Story Map from Jorge Hernán Abad Londoño

Un ejemplo de artefáctos ágiles

Un ejemplo de artefáctos ágiles desarrollado por los estudiantes

• John Sebastian Assa Bolaños
• Jeremy Antony Bolaños Vasquez

De la Especialización en Construcción en Software de la Universidad de Nariño, Contiene:

• Elevator Pitch
• User Story Map
• Estimación top-down de costo y tiempo
• Historias de usuario
• Mockup de las historias de usuario

Del sistema S.R.E.D. (Sistema de Reserva de Escenarios deportivos) para acceder haga clic aquí.

User Story Map - Mapas de Historias de Usuario. Elaboración y Cálculo de Tiempo y Costo

Hola a todos

Les comparto esta oportunidad que medio devAcademy.la de compartir un devHangout sobre Mapa de Historias de Usuario o User Story Map.

Saludos Ágiles
Jorge Abad.

PRESENTACIÓN EN SLIDESHARE

Mapa de Historias de Usuario - User Story Map de Jorge Hernán Abad Londoño

VIDEO DEL DEVHANGOUT

Ejemplos de Artefactos Ágiles

Hola a todos


Tuve la oportunidad en este semestre (2016-01) impartir la materia "Planificación de Proyectos Informáticos" a los estudiantes de la Especialización en Ingeniería de Software de la Universidad de Medellín (clic aquí), la materia fue dividida en mitad gestión ágil y la otra mitad en gestión tradicional.

Se armaron 2 equipos de trabajo que trabajaron en sus respectivos proyectos en los cuales debían generar los siguientes entregables:

• Elevator Pitch
• Product Vision Board
• Product Backlog Board
• User Story Map
• Plan de Releases y Costo del Proyecto
• Historias de usuario
• Simulación de Scrum

Los proyectos son

• SCRUM Gymsoft - sistema para administración de gimnasios -  (clic aquí)
• ZER - sistema para administrar zonas de estacionamiento regulado - (clic aquí)

Espero les sirvan estos ejemplos para comprender más sobre estos artefactos.

Saludos ágiles

Jorge Abad

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum UNAB 2015-02

Hola a todos

Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.

Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS  II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).

En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un area de gestión de incidentes empleando Kanban (debo un post sobre este tema).

Los entregables desarrollados son:

• Agile Inception
• Mapa de Impacto (Impact Map)
• Product Vision Board
• Visión
• Grupos de usuarios
• Necesidades
• Funcionalidades
• Beneficios
• Product Backlog  Board
• Técnica Personas
• Restricciones
• Lo que no nos deja dormir (Riesgos)
• Sería genial que pasara (Oportunidades)
• Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
• Incluido en el alcance
• Fuera del alcance
• Modelos /Diagramas
• Despliegue
• Procesos
• Diagrama de contexto
• Mockups
• User Story Map / Construcción del Release Plan 
• Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
• Construcción del Product Backlog basado en requerimientos con historias de usuario
• Simulación de Scrum
• Simulación de tres sprints de scrum, durante una sesión de 4 horas, generando los siguientes entregables:
• Historias de usuario
• Bocetos asociados a las historias de usuario
• Gráfica de Burndown de cada Sprint
• Gráfica de Velocidad
• Gráfica de Release Burn Up
• Mejoras identificas cada sprint

En estos links encontrarán los cuatro proyectos con los entregables citados:

• SerVIP -Sistema para la notificación oportuna de daño en los servicios públicos  link
• Enjoytravel -Sistema planear un viaje empleando un vehículo propio- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

Ejemplo User Story Map - Solicitud de Crédito

Hola a todos

Les comparto este Mapa de Historias de Usuario - User Story Map, para un proceso de solicitud de crédito.

User Story Map - Sin Priorizar

User Story Map - Con Releases

Espero les sea útil.

Saludos Ágiles

Jorge Abad.

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum (Semestre 02 - 2015)

Hola a todos

Con mis alumnos de "Gestión de Proyectos Informáticos" del semestre 8 del pregrado Ingeniería de Sistemas de la Universidad Eafit - www.eafit.edu.co, realizamos durante el primer módulo la simulación de la gestión ágil de un proyecto de software, generando los siguientes entregables:

• Agile Inception
• Product Vision Board
• Visión
• Grupos de usuarios
• Necesidades
• Funcionalidades
• Beneficios
• Product Backlog  Board
• Técnica Personas
• Restricciones
• Lo que no nos deja dormir (Riesgos)
• Sería genial que pasara (Oportunidades)
• Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
• Incluido en el alcance
• Fuera del alcance
• Modelos /Diagramas
• Despliegue
• Procesos
• Mockups
• User Story Map / Construcción del Release Plan 
• Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
• Construcción del Product Backlog basado en requerimientos con historias de usuario
• Simulación de Scrum
• Simulación de tres sprints de scrum, durante una sesión de 3 horas, generando los siguientes entregables:
• Historias de usuario
• Bocetos asociados a las historias de usuario
• Gráfica de Burndown de cada Sprint
• Gráfica de Velocidad
• Gráfica de Release Burn Up
• Mejoras identificas cada sprint

En estos links encontrarán los cuatro proyectos con los entregables citados:

• Optitraffic Gestion -Sistema para apoyo de la movilidad de la ciudad-  link
• MetroTime -Sistema para conocer tiempos del metro y sistemas integrados- link
• Uber Bus App site -Sistema de información de movilidad pública- link
• Sismat -Sistema de Gestión de Matriculas de Colegios- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

Meetup: Impact Mapping/ Impact Map / Mapa de Impacto y ejemplo para Soluciones de Software

Hola a todos:

El pasado 2 de Junio en la comunidad Ágiles Colombia realizamos un meetup de Impact Mapping (ver links - convocatoria - fotos - )

El Impact Mapping es una excelente herramienta ideada por Gojko Adzic (@gojkoadzic) para garantizar que lo que construimos se encuentra alineado con las necesidades u objetivos del negocio.

Esta herramienta se basa en responder en un mapa mental.

• Por qué -  Why -  ( Objetivo )
• Quienes - Who -  (Quienes serán afectados con el objetivo)
• Cómo - How - (Impacto que afectará a los "quienes" del punto anterior, mi sugerencia en este caso es comenzar a redactar los impactos utilizando el verbos  gerundio  o verbos en infinitivo, de forma que queden en acciones y no en resultados - de esta forma se evita que se confunda con el punto posterior)
• Qué -  What - (qué ENTREGABLES se construirán para generar esos impactos)

Ver poster a continuación en el cual se resume la técnica:

Cómo resultado se obtuvieron 5 excelentes mapas que comparto a continuación.

• Evitar el sacrificio de animales domésticos (clic aquí)
• Optimizar el tiempo de entrega de medicamentos (clic aquí)
• Reducir el tiempo de atención el las EPS (empresas prestadoras de servicios de salud) en un 50% (clic aquí)
• Aumentar la recolección de cartera (clic aquí)
• Reduccir accidentalidad en Medellín (clic aquí)

Dentro de las conclusiones de la sesión se tuvo:

• Respecto a la forma de priorizar los entregables, se puede hacer una calificación identificando
1. Los más críticos
2. Los de bajo costo y alto impacto
3. Los que más personas impacten
• Respecto a los beneficios de la técnica se tienen:
1. Salida del pensamiento puramente técnico de TI
2. Se desarrollan soluciones que tienen un objetivo tangible
3. Permite visualizar con claridad qué se va a hacer y por qué
4. Permite entender el problema y las diferentes soluciones propuestas
5. Es un excelente ejercicio para lograr el consenso de los interesados
6. Permite visualizar el ecosistema de las soluciones.

Dentro de los pendientes que me quedaron:

1. Plublicar los Mapas (¡Hecho !- acá tuve ayuda de los fotógrafos-)
2. Publicar el link hacia una presentación donde se vincula el Impact Mapping con el User Story Map (-http://es.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen - clic aquí) - (¡Hecho!)
3. Publicar un Mapa de impacto completamente orientado a software.Ver mapa a continuación. (¡Hecho!)

En este mapa se evidencia la posibilidad de escribir historias épicas y por ende ir construyendo el Product Backlog a partir del Mapa de Impacto, usando el formato:

    Yo como QUIEN
    Deseo un QUE
    para un IMPACTO / COMO


Ejemplos:
    Yo como PACIENTE
    Deseo conocer  el LISTADO DE MÉDICOS Y CITAS DISPONIBLES
    Para ACCEDER A UNA CITA DE FORMA RÁPIDA

    Yo como PACIENTE
    Deseo conocer  el CANCELACIÓN DE MI CITA VIA SMS
    Para LIBERAR MI CITA PARA OTROS


---

Gracias a la comunidad por asistir y por permitirme aprender más. Definitivamente la mejor forma de aprender es enseñando y practicando.

Gracias a los compañeros que co-facilitaron la sesión:
- Lucho Salazar (@luchosalazarc) - (el ministro)
- Leonardo Agudelo (@sweepnoise) - (el magnánimo)
- Guillermo Trujillo - (el patrón)
- Robinson Rico Mendez (@rimerz77) - (el coste)


Saludos ágiles
Jorge Abad

Calculando el Costo y Tiempo Estimado de un Proyecto Ágil Usando un User Story Map

Hola a todos

Una pregunta constante en las capacitaciones y cuando un equipo comienza a trabajar con metodologías ágiles es:

¿Cómo determino el costo de mi proyecto ágil?

Pues bien, una de las formas es utilizando mapas de historias de usuario (user story maps) y luego asignar valores a las historias épicas encontradas

A continuación les comparto la hoja de cálculo y los tips para usarla.

 ---->    Hoja de cálculo (clic aquí para descargar)   <-----

---

Para hacer uso de esta hoja de cálculo debes saber que es un User Story Map, te recomiendo estos links Qué es un User story map (la información desde la fuente misma - Jeff Patton) user_story_mapping Ejemplos de User Story Map Ejemplo 1 - User Story Map Ejemplo 2 - User Story Map Ejemplo 3 - User Story Map Luego de elaborar tu User Story Map, debes tallar las historias épicas con tallas de camiseta  y tu propia tabla de equivalencia de tallas (a continuación te comparto una posible)

S	es el pivote o punto de comparación
M	Equivale a	2	"s"
L	Equivale a	5	"s"
XL	Equivale a	10	"s"
XXL	Equivale a	20	"s"
XXXL	Equivale a	40	"s"

Este tallaje es de acuerdo a la percepción de tamaño que les de el equipo de desarrollo a las historias épicas y buscando que las que son de similar talla queden con misma asignación, por ejemplo así

• User Story Map con tallaje - User Story Map con tallas

Paso seguido determinar la cantidad de  "S" por cada release, de acuerdo a la tabla anterior.

Por lo tanto, luego de determinar que en Release "0" tienes  10 historias épicas talla "S" y 3

historias épicas talla " L", equivale a 25 "s"y así hacer con el resto de releases.

---

De la hoja de cálculo recordar que todo lo que esta en Amarillo puede ser modificado.

                   

De igual forma, un estimado no es algo preciso, y por ejemplo afirmar "UNA ESTIMACIÓN EXACTA"es un completo contra-sentido (u oxímoron).

_

Esta hoja de Calculo te ayudará a saber el costo y duración de tu proyecto ágil de forma aproximada.

No olvides leer el los derechos de autor y si tienes mejoras, pues publícalas y compártelas

Saludos ágiles

Jorge Abad

Trabajo sobre gestión ágil - Alumnos Pregrado Sistemas - Eafit 2015- sem 01

Hola a todos

Mis alumnos de pregrado  hhhbbbbnngrado grado do de Gestión de proyectos informáticos tienen la mitad del semestre una entrega sobre gestión ágil y otra sobre gestión tradicional.

Les comparto los dos trabajos sobre gestión ágil que resaltaron este semestre:

Los trabajos tienen:

• Visión
• Product Vision Board
• Product Backlog Board
• User Story Map
• Plan de Releases
• Costo del producto por releases
• Historias de usuario
• Simulación de Scrum empleando Mockups / Bocetos / Scketches
• Gráficas de Velocidad, y burndown

Estos son los links

• BankShieldApp - Sistema para Vigilancia de Ataques informáticos a Bancos -  https://sites.google.com/site/bankshieldapp/
• Infotaxi - Sistema de información para administración de una flota de taxis - https://sites.google.com/site/infotaxiapp/home

Espero los disfruten y les ayude en sus proyectos.

Saludos Ágiles

Jorge Abad

Cómo se ve un User Story Map (mapa de historias de usuario)

Tomado de: http://winnipegagilist.blogspot.no/2012/03/how-to-create-user-story-map.html?goback=.gde_117832_member_162001454

User Story Dojo - ( User Story Map y User Stories)

Nivel del post: Medio

Lugar: www.ceiba.co - Ceiba Softaware House. (Empresa donde trabajo y me desempeño como Scrum Master y Scrum Coach)
Ciudad: Medellín, Colombia


Temas trabajados en el dojo.

• Desarrollo Orgánico
• Cómo construir un User Story Mapping * (técnica de Jeff Patton - http://www.agileproductdesign.com/presentations/user_story_mapping/index.html o en español en  http://www.caminoagil.com/2013/02/visual-story-mapping-aplicado.html)
• Cómo elaborar Historias de Usuario - User Stories (taller. Criterio CCC e INVEST)

-
-

o acceder a directamente a  youtube

-
-

*El nombre correcto es User Story Mapping dado por Jeff Patton (en algunos medios se emplea Visual Story Mapping / Visual Story Map)