Hola a todos:
Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:
- Las historias de usuario no son especificaciones
- Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
- Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
- Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
- Es en serio, las historias de usuario tienen que ser pequeñas (ver post aquí)
- Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
- Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
- Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
- Un buen sprint backlog tiene entre 6 a 10 historias de usuario (ver más acá)
- Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
- Es un error decir: "la historia de usuario está mal especificada", pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
- Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
- Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
- ¿puedo ponerla en producción?
- ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?
- Una historia de usuario debe ser construible en su totalidad durante un sprint (incluyendo pruebas, documentación, despliegue y todo lo que este en la "Definition of Done")
- "Las historias de usuario son DICHAS, no escritas." / "Key point: User Stories are TOLD, not written".(Ron Jeffries)
@jmbeas @jeffpatton @david_caicedo http://t.co/nZu7d99Va2http://t.co/pcRLrNfs48— Ron Jeffries (@RonJeffries) May 23, 2015
Key point: User Stories are TOLD, not written.
Espero les sean útiles estas cortas ideas.
Saludos Ágiles
Jorge Abad
Muy buen resumen y muy oportuno. En esta carrera de cambiar las cosaa, se esta mal interprestando y dando mal uso a las hitorias de usuarios,
ResponderBorrarQue tal Jorge, de este post revisandolo para tomar una base de argumentos para nuevos equipos, me encontré con 2 dudas.
ResponderBorrarPrimera duda: Punto 5, primera descripción ¿cuál es la experiencia vivida para proponer que la HU se desarrolle entre 3 y 5 dias
Segunda Duda: mismo contexto para la pregunta 7, 6-10 HU estamos tomando la base de la literatura para determinar que el team que puede construir tal cantidad debe ser entre 3 y 9 personas?, ¿de cuantas semanas el sprint? y por ultimo ¿cuales crees que serían las excepciones para que esto no se cumpliera.?
Agradezco tus dudas.