User Stories Applied

Resumen User Stories Applied de Mike Cohn


¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean?

El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y cualquier otra duda que tengas acerca de las historias de usuario, tan conocidas en metodologías ágiles como Scrum o eXtreme Programming.
User Stories Applied - Mike Cohn
En los primeros capítulos (1-7) del libro User Stories Applied, Mike Cohn nos habla de qué son las historias de usuario y qué características tienen. Después nos explica algunas técnicas para obtener la lista de historias de usuario de nuestro producto.

En el 2º bloque (capítulos 8-11) nos da instrucciones sobre cuál es la mejor forma de estimar el tamaño de las historias de usuario. La estimación la utilizaremos después para poder planificar. En el libro se habla de 2 planificaciones: una 1º planificación de entregables o releases con una visión global del producto (meses vista), y una más concreta en iteraciones (semanas vista).

En el 3º bloque (capítulos 12-16) nos da consejos sobre cómo asegurar la calidad de las historias de usuario. Lo complementa con contraejemplos de lo que no son historias de usuario para que sepamos argumentar y diferenciar de otros elementos utilizados para definir producto como los requerimientos o los casos de uso. También nos da una lista de malos olores con los que detectar en qué estamos fallando al crear nuestras historias de usuario.

En el bloque final (capítulos 17-21) nos explica con detalles un ejemplo concreto de creación de un producto, una web de libros de navegación marítima. La concepción del sitio con las primeras historias de usuario, la creación del equipo, la planificación en entregables e iteraciones, problemas típicos y qué soluciones se plantean.

En definitiva, una visión completa de una de las herramientas clave que se utiliza en todo el ciclo de vida Agile. Sea cual sea tu conocimiento sobre las historias de usuario, no te puedes perder este libro. Sin más, el resumen.

User Stories Applied de Mike Cohn

1.US son:

  • Una descripción que sirve de recordatorio y para planificar (Card)
  • Conversaciones para describir los detalles (Conversation)
  • Tests para acabar de documentar los detalles y poder comprobar si la historia está completa o no (Confirmation)

Como punto de comienzo, una US debe poder hacerse y probarse entre medio día y 2 semanas por 1 o 2 developers.

Cuando una US es demasiado grande la partimos. No hasta el punto de tener todos los detalles, eso se dará en la conversación.

Se pueden agregar notas en una US pero nunca será una obligación o contrato.

Tests de aceptación: Capturan las expectativas, como se va a comprobar que la historia está hecha. Los tests pueden estar incompletos e ir variando a medida que se construye el software. Normalmente es mejor escribirlos antes de codificar. Ej:

  • Prueba con una descripción vacía
  • Prueba con un número de cuenta de 100 dígitos
  • Prueba con una tarjeta de crédito expirada

Equipo de cliente (Customer Team): Personas que representan y conocen lo que quiere el cliente (clientes, product managers, diseñadores, testers…). Son los que escriben las US.

2.INVEST

Independent: Cuando existan dependencias (pagar con VISA, pagar con MC, pagar con AMEX)

Combinar las US dependientes en una sola (pagar con tarjeta de crédito)

Separar de forma diferente (pagar con 1 tarjeta, pagar con el resto de tarjetas)

Poner estimaciones condicionales (VISA si es la primera 3, si no 1, MC si es la primera…)

Negotiable: US = pequeña descripción para una conversación. Contendrá:

1 frase o 2 para la descripción (pagar con tarjeta de crédito)

Notas sobre cosas que hay que hablar en la conversación con el cliente (considerar discover cards?)

Si tras la conversación hay más detalle se escribe en la tarjeta, solo el necesario. Los detalles acaban siendo tests. (prueba de pagar con Diners falla, prueba de pagar con una tarjeta expirada falla)

Valuable: Tiene valor para usuarios y para los que pagan la aplicación (desarrolladores harán documentación ISO 9001 compliant)

Evitar las que solo tengan valor para desarrolladores (gestión de errores centralizada en 1 clase). Mejor escribirlas de forma que el cliente pueda priorizarlas (los errores se presentan de forma homogénea)

Por esto es tan importante que sea el propio cliente el que escriba las US.

Estimatable: Debemos conocer su tamaño para convertirlo en algo codificable en un sprint. Varias razones para no poder estimar:

Si no conocemos funcionalmente qué se pide se debe discutir con PO para aclararlo, sin detalle, solo hasta que podamos estimar.

Si no hay conocimiento técnico se creará un SPIKE timeboxed.

Si el problema es que es demasiado grande se partirá, aunque no debe haber problema en estimar una épica a alto nivel.

Small: Una US debe ser pequeña para caber en un sprint, pero lo suficientemente grande para tener sentido y agregar valor.

Si una US es demasiado grande se debe partir, bien a través de las operaciones CRUD, bien por sus campos.

Si una US es demasiado compleja, tiene riesgo y no se puede partir fácilmente, se separa en un SPIKE timeboxed y una US posterior.

Si el problema es que tenemos US demasiado pequeñas, es posible agrupar 5-6 pequeñas en 1 sola US (por ejemplo agrupando bugs o cambios estéticos).

Testable: La US debe poder probarse, esto es, debemos saber cuándo una US está terminada.

Los tests deben ser automatizables al  99%.

Como desarrolladores, somos responsables de ayudar a los usuarios a escribir US que tengan valor, sean testables, independientes entre sí, y con el tamaño adecuado. Si hay historias técnicas, debemos escribirlas mostrando el valor para el usuario.

Como usuarios, somos responsables de escribir US que inviten a la conversación, tengan valor, sean testables, independientes entre sí, y con el tamaño adecuado.

Un sistema tendrá normalmente muchos usuarios con diferente formación, dedicación, objetivos… Los usuarios normalmente los agruparemos por afinidad en roles. Una funcionalidad se puede compartir entre diferentes roles.

User Stories Applied

3.Role Modeling

Para identificar y seleccionar los roles (1 hora):

  1. Brainstorming: Tanto negocio como desarrollo se reúnen en una sala y escriben en postits todos los roles que se les van ocurriendo, sin censura ni juicio. Se acaba cuando a nadie se le ocurren más (~15 minutos). Una alternativa podría ser BrainWriting.
  2. Organizar el resultado: Pon postits relacionados encima de los que hay, más encima cuanto más se solapan.
  3. Consolida los roles que tengan muchas características solapadas y elimina los que sobren
  4. Indica los detalles de cada rol: frecuencia de uso de la app, experiencia, destreza con el software, objetivos… Deben ayudarnos a distinguir entre roles
  5. OPCIONAL, crea user personas y ponles foto
  6. OPCIONAL, casi no recomendado, crea personas extremas (el Papa, un “camello”, una prostituta…)

No es necesario identificar todos y cada uno de los roles de usuario, solo los más importantes (pueden ser también roles de sistemas no-humanos).

No es necesario conseguir mucho detalle en una primera pasada de toma de requisitos, con las US podemos simplemente capturar una frase que después detallaremos. Aunque sea imposible en una pasada conseguir todos los requisitos, es necesaria una pasada inicial para estimar coste y volumen del proyecto, y conseguir detalle para una 1º release.

4.Métodos para conseguir US

Son (mejor combinar que no usar uno solo):

  1. Entrevistas con los usuarios o con proxies, mejor los primeros y que tengan diferentes roles. Normalmente los usuarios saben el problema pero no la solución, por lo que mejor evitar preguntas como ¿qué necesitas?
  2. Preguntas abiertas y sin contexto, para llegar a los detalles es mejor utilizar preguntas abiertas, ¿prefieres una app móvil o una web?, y sin un contexto o respuesta preferente, ¿quieres una web, verdad?
  3. Cuestionarios, para priorizar US que ya tienes, no funciona para los detalles porque no puedes hacer preguntas en función de las respuestas que te vayan dando.
  4. Observación de los usuarios reales con la aplicación
  5. Talleres de US, es la manera más eficiente. Recomendado 1 taller por release. Se empieza escribiendo cuantas más US mejor (brainstorm), no se intenta llegar a los detalles y se prima la cantidad (no se juzgarán las ideas, aunque al final se priorizará). Se pueden usar flipchart o tarjetas para describir el flujo principal de la app (no llegar a las pantallas y campos). Preguntas a hacer en un punto de la sesión o con el flujo delante:
    1. Qué haría el usuario a continuación?
    2. Qué errores podría cometer el usuario aquí?
    3. Qué podría confundir al usuario aquí?
    4. Qué información adicional podría necesitar el usuario aquí

User Stories Workshop

5.User Proxies

Cuando no podemos acceder a los usuarios reales de la aplicación (recomendable) podemos hacer el producto con user proxies (representantes del usuario que están en el proyecto).

  • El jefe de los usuarios: Mejor convencerlo de que nos deje acceder al menos a uno de los usuarios, aunque sea con su supervisión.
  • Jefe de desarrollo: Están más interesados en la tecnología y en los resultados a nivel de gestión de proyectos que en pensar en los usuarios.
  • Gerente de ventas: Interesados en priorizar las características que les han hecho perder las últimas ventas. Lo bueno que tienen es que puedes pedirles que te presente a usuarios y que les acompañes a visitas.
  • Expertos de dominio, son útiles para el modelo de dominio y las reglas de negocio, pero para definir el workflow y UX mejor los usuarios reales siempre
  • Grupo de marketing: No llegan correctamente a los detalles necesarios, solo visión alto nivel
  • Ex-usuarios: Puede que no tengan la visión correcta de los usuarios actuales y potenciales
  • Clientes: Son los que compran la aplicación. Se les debe tener muy en cuenta ya que son los que pagan, táctica: calidad esperada para los usuarios y calidad percibida para los clientes.
  • Trainer o personal de soporte: priorizarán lo que es fácil de enseñar y lo que es fácil de mantener
  • Analistas: Prefieren intuir y pensar en el problema en lugar de entrevistarse con los usuarios para que se los expliquen, también tienden a hacer demasiado análisis upfront.
  • Cuando estemos trabajando con user proxies podemos:
    • Proponer hacer user task force (lluvias de ideas en grupo, taller de historias de usuario, inception)
    • Recurrir a más de un user proxy de diferentes tipos
    • De ninguna forma pensar que los desarrolladores solos podrán hacerlo solos

6.Tests de aceptación

Se conciben como un proceso en 2 pasos:

  1. Escribir a alto nivel un listado de lo que se debe probar detrás de la tarjeta de la US (ej: probar que funciona con VISA y mastercard, probar que no funciona con Diners, probar que falla con una tarjeta caducada)
  2. Traducir estos tests en tests completos paso a paso

Los tests nos deben dar un criterio claro de si está completa la funcionalidad o no, para evitar dedicar demasiado tiempo. Mejor escribir los tests antes de codificar, ya que son una guía para el desarrollo bestial. Los tests los debe escribir el usuario, si bien el equipo de desarrollo probablemente los completará con tests adicionales. Es algo iterativo, cuanto más detalle, más tests. El límite lo da el valor, mientras los tests aporten valor a la historia hay que crearlos, cuando dejen de clarificar la US deja de escribir. Hay que dejar los tests de límites al equipo de desarrollo (ej. 30 de febrero).

Tipos de tests:

  • Test de interfaz de usuario, comprueba que los componentes de front se comportan bien
  • Test de usabilidad, comprueba que es fácil de usar por el usuario
  • Test de rendimiento (performance), comprueba tiempos de respuesta con diferentes cargas
  • Test de stress, comprueba que la aplicación aguanta las cargas extremas

7.Tips adicionales para conseguir buenas US:

  • Empieza preguntando a cada rol de usuario cuál es su objetivo prioritario con la aplicación
  • Desglosa las US grandes en pequeñas piezas que aporten valor (no técnicas), para reducir el riesgo técnico y para poder hacer release en cualquier momento
  • Escribe US completas, atómicas, concretas y con un propósito que se consigue y se demuestra (evitar “el usuario puede gestionar su CV”)
  • Escribe las restricciones técnicas (la BBDD debe soportar 200 usuarios, debe soportar todos los navegadores…) en tarjetas, aunque no las trates como US (no estimarlas, no planificarlas). Implementa tests automáticos si es posible para comprobar que se cumplen estas restricciones a lo largo del tiempo.
  • Entra en el detalle de aquellas US que vayas a desarrollar en las próximas iteraciones, pero no más allá.
  • Evitar detallar la UI al principio del proyecto, pero detalla la UI cuando ya está maduro el proyecto para que sea consistente
  • No intentes usar el formato “historia de usuario” para cosas que no son US (tareas técnicas, contratos con proveedores, interfaces entre sistemas…)
  • Utiliza los roles de usuario al escribir las historias de usuario (yo como candidato… en lugar de yo como usuario…). El formato es: Yo como [role] quiero […] para […]. Utiliza siempre el rol en singular y el verbo en voz activa.
  • Las US las escriben los usuarios o clientes (los desarrolladores solo ayudan pero nunca sustituyen)
  • No numeres las US, y si las numeras ponles un título corto y fácil
  • El propósito de una US es mantener una conversación, los detalles que se escriben son para retomar la conversación, no para sustituirla.

8.Estimación de US

Estimar mejor en story points: El equipo decide que es un story point. Mi favorito es días ideales (sin interrucciones), es más fácil después convertirla a tiempo real. Las estimaciones de US son propiedad del equipo. Los story points no deben ser comparables entre equipos. Las estimaciones deben incluir todo el trabajo necesario para completar la historia, no solo el tiempo de codificación (tests, documentación, reuniones…).

En la sesión de estimación, todo el equipo participa. Planning Poker. Si no hay consenso el que puntúa más alto y más bajo explican por qué estiman así. El objetivo es converger hacia una medida. Si no hay consenso después de 3 rondas, pedir al equipo escoger la más votada o la más alta.

Una vez tengamos 3-4 US podemos usar triangulación para acelerar la estimación del resto de elementos o recolocar anteriores. Cuando desagregamos épicas, la suma de los US no tiene por qué coincidir con la estimación de la épica. De la misma forma, si desglosamos en tareas y las estimamos, tampoco deben coincidir.

Para planificar usamos la velocidad del equipo en story points ya que probabilísticamente se debe mantener en el tiempo si las estimaciones son correctas y no hay grandes impactos en el equipo (vacaciones, gente que se va o que viene…). Esta velocidad no es constante, va evolucionando por aprender nuevas formas de trabajar, conocerse mejor…

Planning Poker

9.Planificación de release

Se puede desglosar un productos en areas de foco (themes).

2 preguntas para comenzar un release planning:

  • Cuándo queremos tener la release? (mejor un rango de fechas, pero puede ser una fecha fija)
  • Cuál es la prioridad de cada US? (para priorizar en una release utilizamos MoSCoW, Must, Should, Could, Won’t). Para priorizar:
    • Tener en cuenta la estimación y el valor de negocio de la US
    • Tener en cuenta tanto el riesgo técnico por incertidumbre o porque es necesaria para asegurar el desarrollo de otras US
    • Tener en cuenta la importancia que le dan los usuarios o los jefes
    • Tener en cuenta la cohesión entre historias aunque no sean dependencias (ej: zoom out y zoom in)

Ante priorizar por riesgo y priorizar por valor, en agile se prefiere el valor. Esto permite tener antes funcionalidad que aporta valor al usuario y no construir complejidad antes de que sea necesaria. Esto no quiere decir que nunca se tenga en cuenta el riesgo. Es común escribir tareas técnicas con riesgo y priorizarlas como si fueran US.

El equipo de desarrollo también participa en la priorización, proponiendo un criterio técnico de ordenación si es el caso. Si no hay acuerdo entre equipo y clientes, gana el cliente.

Si hay US conflictivas y se pueden partir, mejor partirlas.

Las iteraciones duran entre 1 y 4 semanas con preferencia al número más corto que funcione para el equipo y el cliente. Es posible cambiar la duración de las iteraciones si hay una buena razón, pero es mejor mantener un ritmo constante y no alterarlas.

Para planificar necesitas la velocidad, para planificar el proyecto puedes (en orden de preferencia): usar datos históricos, hacer una primera iteración de prueba, adivinarlo (aproximadamente 1 día ideal son 1/3-1/2 días normales).

CUIDADO con establecer expectativas demasiado altas en el release planning, es mejor comprometerse a un rango amplio de fechas y es conveniente ir actualizando constantemente el plan a medida que conocemos más información.

10.Planificación de una iteración

Todo el equipo se reúne en una reunión de planificación, que tiene las siguientes fases:

  • Discutir la US: el equipo hace preguntas al PO hasta que entiende la US y la puede descomponer en tareas. Solo hace falta llegar al detalle para crear las tareas, es posible discutir detalles concretos con parte del equipo tras el planning. En el planning también es posible cambiar prioridades de las US, si eso evita hacerlo en mitad del Sprint.
  • Desglosar en tareas: una US típicamente 1 a 5 días ideales de un programador. Al desglosar en tareas es cuando realmente se diseña en agile. Típicamente se ponen tareas transversales como documentar la ayuda. Algunas guías que pueden ayudar:
    • Separa de la historia las tareas muy complejas o que dependen de terceros
    • Si una tarea se puede hacer en paralelo entre dos mejor separar en tareas separadas
    • Si hay dependencias entre 2 tareas mejor separarlas y hacerlo explícito
  • Asignar tareas: Los desarrolladores en el equipo se autoasignan las tareas. Se apunta el nombre al lado de cada tarea para definir el responsable de la tarea (aunque se haga pair programming). Aunque haya responsables por tarea, el equipo sigue teniendo mentalidad de equipo y es el equipo el último responsable de cumplir el objetivo de la iteración.
  • Estimar y confirmar: Los pasos anteriores se repiten hasta que se llega a la velocidad del equipo con las US que hay. En ese momento todos los desarrolladores estiman lo que han cogido (cada uno lo suyo) y se comprometen. Si no cuadra, o pedimos a algún compañero que coja parte de nuestras tareas, o pedimos al PO que quite parte o toda una US. Todos los desarrolladores deben sentirse seguros de acabar todas sus tareas, y todo el equipo como un todo con llegar al objetivo de la iteración.

11.Medir y monitorizar la velocidad

La velocidad en puntos de las iteraciones es la medida principal tenida en cuenta para planificar. No es conveniente coger solo la velocidad de la 1º iteración, al menos 2 o 3. No se deben tener en cuenta puntos de US parcialmente completadas. Tampoco se debe permitir cambiar los puntos de la US una vez empezada la iteración, incluso si se ha desviado mucho.

Es muy útil tener un gráfico que nos diga la velocidad real vs la planificada para cada sprint. También un gráfico de puntos acumulado por sprint para decidir si debemos mover la fecha de release o cambiar scope, tipo burndown por si se incrementa el número de puntos.

Durante la iteración también hay monitorización, con el daily burndown chart, que mide las horas de trabajo que faltan para finalizar la iteración. En las dailies los miembros del equipo estiman lo que les queda de las tareas pendientes, sobre todo las que están en curso. Mejor no medir las horas invertidas (sensación de microgestión, imprecisión de los datos). Se pueden añadir nuevas tareas siempre y cuando sean necesarias para completar la historia actual. Si son nuevas peticiones irán debidamente priorizadas en la siguiente iteración.

12.Qué no son US

No son requerimientos, no llegan al detalle ni son un contrato. Desde luego no se escriben desde el punto de vista de desarrollo ni de ningún departamento, sino siempre desde el usuario. Otra diferencia es que los requerimientos se centran en características del sistema, no las necesidades ni objetivos del usuario. Una manera sencilla de evitar los requerimientos innecesarios es pedirle al cliente que describa escenarios de uso de esa característica.

No son casos de uso, no contemplan todos los casos posibles (principal caso de éxito y caminos alternativos, cada caso es un escenario de uso). Los escenarios sí que pueden ser casos de test. Otra diferencia es que los casos de uso incluyen detalles del UI. Los casos de uso no dejan sitio para una conversación, contienen nuevamente todos los detalles. La mayor diferencia, el caso de uso se escribe para finalizar un análisis, mientras que la US se escribe para iniciarla.

No son escenarios (descripción de interacción entre usuario y sistema, no escenarios de uso). Los escenarios contienen actores, situaciones, objetivos y eventos. Normalmente estos escenarios cuentan una historia, pero mucho más grande que una US (generalmente contienen más de una US). Como las US, los escenarios no describen los detalles.

Sizing User Stories

13.¿Por qué US?

  • Enfatiza la comunicación verbal, la conversación permite feedback inmediato, no los documentos. También se evitan los contratos firmados en documentos, y se mejora la comunicación entre todo el equipo.
  • Son comprensibles por todo el equipo (gente de negocio, equipo de desarrollo y hasta los usuarios)
  • Tienen el tamaño adecuado para planificar
  • Funcionan en desarrollo iterativo, primero se escriben en tamaño épica y cuando se priorizan se dividen en US más pequeñas
  • Promueven dejar los detalles para el final, de esta forma al principio nos enfocamos en el valor y en priorizar correctamente por los objetivos de los usuarios, y en etapas más futuras preocuparnos por los detalles
  • Promueven el diseño oportunista, de forma que tanto los desarrolladores como los clientes definen el sistema con toda la información posible
  • Promueven el diseño participativo, sobre todo de los clientes que normalmente no participan demasiado. También evitan que los diseñadores tengan que asumir cosas, ya que el usuario está involucrado al igual que ellos.
  • Ayudan a construir el conocimiento tácito. Cuanto más participen y se comuniquen equipo de desarrollo y clientes mayor conocimiento compartido tendrá todo el equipo y menos tendrán que escribir.

Desventajas de las US:

  • Dificultad de ver las dependencias entre US
  • Dificulta la trazabilidad de los requerimientos con el software o con los tests, aunque se puede suplir con trabajo adicional
  • No escalan en equipos muy grandes a la hora de compartir conocimiento

14.Malos olores

  • Historias demasiado pequeñas, y cambian su estimación cuando se planifican (porque también dependen del orden en el que se implementen)
  • US interdependientes, que dificultan su planificación porque forman una cadena, normalmente también se da que son demasiado pequeñas (revisar capítulo 7 para hacer bien las divisiones)
  • Chapado en oro, o seguir haciendo trabajo en una US o en una tarea cuando el esfuerzo ya no merece el valor obtenido. En este caso marcar correctamente el scope de cada US.
  • Muchos detalles, generalmente se da cuando se pasa más tiempo escribiendo y leyendo US que hablando sobre ellas.
  • Incluir demasiado detalle sobre el UI
  • Pensar demasiado en avance, síntomas son que las US tienen demasiado texto, se pide utilizar un software para definirlas, o nos piden una estimación más precisa de lo que queda de proyecto.
  • Dividir demasiadas US, en el planning se puede dividir alguna para que quepa en una iteración, o para hacer primero la parte con más valor, pero más allá de eso suele ser un problema de US demasiado grandes.
  • El cliente tiene problemas priorizando, normalmente porque las US son demasiado grandes, o son demasiado técnicas
  • El cliente no quiere escribir las US ni priorizarlas, en este caso lo recomendable es acompañarlos para escribirlas y pedirles opinión sobre cómo priorizar para hacer de proxy nosotros.

15.US con Scrum

Explicación del funcionamiento de Scrum.

Las dailies mejor que sean abiertas a que todo el mundo pueda venir, y así evitar reporting a los managers. El Scrum Master es responsable de mantener el foco y que solo los involucrados en el proyecto participen activamente.

Una pregunta que nunca puede hacerse en un daily es “cuanto falta para terminar la tarea X”, ya que entonces se convierte en una reunión de reporting.

Cuando se planifica en Scrum no se saben los detalles, p.e. sabemos que vamos a implementar una búsqueda avanzada pero no qué campos va a tener esta.

reuniones diarias scrum 33 consejos

16.Temas adicionales

Requerimientos no funcionales: Como se ha indicado en el capítulo 7 mejor incluirlas como tarjetas de “restricciones”.

Usar notas en papel o software: En XP uno de los valores es la simplicidad, y las notas en papel son más simples, a la vez que por su tamaño nos recuerdan que son imprecisas e incompletas. El software es indicado en equipos distribuidos, y cuando se quiere mantener trazabilidad.

US en la UI: Muchos usuarios tienen problemas para aceptar cambios en la UI una vez la han probado. Ante esto es mejor primero tener todas las US, priorizarlas, y después con el resultado hacer paper prototyping.

Si las US  se guardan una vez desarrolladas: Buenas razones para guardarlas son demostrar el trabajo hecho, que el proceso funciona o cuando se recodifica una aplicación desde cero.

Relación entre US y bugs: Los bugs se pueden juntar en una US para planificar.

Capítulos 17,18,19,20,21

Ejemplo de aplicación de la construcción de una web de venta de productos relacionados con la navegación marítima, en particular una primera fase de venta de libros de navegación. Los pasos que se siguen para construir el sitio desde cero son:

  1. Identificar los usuarios de la aplicación, en este caso será un user proxy (jefa de ventas)
  2. Identificar todos los posibles roles de la aplicación (role modeling)
  3. Eliminar los roles que se solapan
  4. Describir el detalle de cada rol, frecuencia de uso del software, conocimiento del dominio, familiarizado con el software en general y con el site en particular…
  5. Desarrollo de User Personas para los roles que tienen que estar más satisfechos con la aplicación
  6. US workshop de 2 horas recorriendo primera las 2 user personas, y después completando con el resto de roles
  7. Se utiliza el workshop para identificar además las restricciones y requerimientos no funcionales
  8. Estimación de todas las US, mediante PP
  9. Creación del Release Plan
    1. Decidir una longitud de iteración
    2. Estimar la velocidad del equipo
    3. Priorizar las US
    4. Asignar las US más prioritarias (Must and Should, no Could ni Won’t) a las primeras iteraciones
  10. Creación de los tests (por parte del cliente con ayuda de un QA del equipo)

 

Hasta aquí el resumen del libro User Stories Applied. Si te ha gustado y estás pensando en comprarlo, puedes hacerlo desde el siguiente enlace de afiliados. A ti no te cuesta nada y a mí me ayudarás a mantener este blog.

También te puede interesar...

Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Mejores retrospectivas con la Directiva de Kerth Durante la existencia de este blog uno de los temas centrales y que más entradas ha protagonizado ha sido el de las retrospectivas. Recordemos algunas...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *