¿Qué es y qué no es una historia de usuario?

Question

Tengo un problema en el trabajo donde acabamos de empezar a usar scrum como equipo de desarrollo. Tengo problemas con las historias de los usuarios que recibimos porque no parecen ajustarse a mi interpretación de lo que es una historia de usuario.

Aquí es un ejemplo real de los casos de uso que han dado para este Sprint:

• Como usuario del sitio web que desea tener una página de registro para que pueda registrarse y suministrar más detalles.

• Como usuario comercial, quiero tener la validación en el formulario de registro para que proporcione la información correcta. (Esto se refiere a la validación de formularios)

• Como usuario comercial Quiero ayuda al registrarme para responder cualquier pregunta que tenga sobre los detalles requeridos. (Esto se relaciona con información sobre herramientas en el formulario)

El primero en mi mente es la historia de usuario. Los segundos dos parecen ser requisitos tradicionales de la primera historia de usuario y creo que probablemente deberían ser criterios de aceptación de la primera historia de usuario.

La otra confusión que tengo es en el último sprint teníamos:

• Como usuario Quiero ser capaz de iniciar sesión en el sitio web.

• Como usuario, deseo poder iniciar sesión en el sitio web con un nombre de usuario.

El propietario del producto dice que se trata de dos historias de usuarios diferentes que deben probarse por separado.

Mi problema es que al crear casos de prueba y criterios de aceptación para los otros dos, es difícil ya que son muy específicos y están relacionados con la primera historia de usuario. Parece que simplemente estamos poniendo requisitos tradicionales en una tarjeta en un tablero y llamándolo de otra manera. Principalmente, solo quiero saber si estoy equivocado sobre esto/¿por qué?

Me parece que actualmente solo dejamos que los usuarios creen lo que quieran como historia de usuario y no les ayuda a filtrarlos de los requisitos a las historias de usuario adecuadas. Me han dicho que debemos mantenerlos separados para informar, de modo que podamos mantener un registro de todo lo que el usuario solicite.

Answer 1

Historias de usuarios se centran en el valor del cliente. ... El trabajo real que se está realizando se desarrolla a través de la colaboración en torno a la historia del usuario como el sistema avanza el desarrollo. ... Para limitar el alcance, las historias de los usuarios tienen criterios de aceptación desarrollados en colaboración que definen cuándo la historia del usuario cumple con las expectativas de los interesados. Los casos de prueba suelen ser desarrollados como código (con desarrollo impulsado por prueba) o documentados como se desarrolla el código .

[Énfasis mío.]

Como usuario, deseo poder iniciar sesión en el sitio web.

Como usuario, deseo poder iniciar sesión en el sitio web con un nombre de usuario.

Dado que ninguno proporciona ningún valor de cliente, tampoco son historias de usuario.

Utiliza software de aplicación para administrar información, tomar decisiones y (en última instancia) realizar una acción. Si la historia del usuario no proporciona alguna pista sobre qué información, decisión o acción se toma, no hay valor del cliente, es solo una carpeta técnica - detalles de implementación que un cliente debe soportar para llegar a la parte interesante de la solicitud.

Iniciar sesión, específicamente, tiene cero valor del cliente. Es un obstáculo que la TI erige entre los clientes y la valiosa información que necesitan para tomar decisiones y tomar medidas. Es un mecanismo de seguridad y a la mayoría de las personas no les gusta la seguridad. La seguridad se impone al cliente por TI. La contraseña más popular (IIRC) es "aaaaaaaa". ¿Por qué? A los clientes no les gusta la seguridad.

Detallado, microscópico inicio de sesión historias de usuarios pueden ser un síntoma de no poder ver el valor real para el cliente.

---

Simplemente me parece que estamos actualmente sólo dejar que los usuarios crean lo que quieran como una historia de usuario

buena.

Me han dicho que debemos mantenerlos separados para el informe, de modo que podamos mantener un registro de todo lo que el usuario solicite.

No es un mal plan, de verdad.

El problema es separar "mierda del usuario que pasó a decir" de "cosas que tiene sentido que podamos construir". Es muy, muy importante permitir que los usuarios digan cualquier mierda que quieran decir. Es bueno dejarlos pasear.

Periódicamente (antes de cada sprint) priorizará la basura que el usuario dijo en algunas cosas que (1) podría construir durante el sprint y (2) crear el valor de usuario más significativo y dramático posible crear. Algunas historias serán ignoradas. Algunos serán de baja prioridad. Algunos se combinarán y otros se dividirán. Algunas cosas que el usuario dijo serán contradictorias. Algunos serán mentiras directas. Algunos estarán incompletos. Está todo bien. Es solo basura que el usuario dijo por casualidad. No directivas divinas de la boca de los dioses directamente a usted.

Este conjunto revisado de historias de usuarios impulsa el sprint. Ahora empiezas a colaborar con los usuarios para obtener detalles, escribir casos de prueba, definir aceptación, etc., etc.

Mientras corres hacia la entrega, los usuarios pueden seguir diciendo basura que se adjuntará a la acumulación de historias de usuario no implementadas. Es muy, muy importante permitir que los usuarios digan cualquier mierda que quieran decir. Es bueno dejarlos pasear.