Desglose de la historia de usuario: tarea técnica + función de usuario

Mi equipo está creando una aplicación web que tiene la siguiente historia de usuario de alto nivel:

Como usuario, me gustaría poder excluir componentes de forma masiva de un país determinado.

El trabajo se divide en dos tareas distintas.

  1. Cree la característica de la aplicación web que excluye componentes por país.
  2. Componente de obtención: datos de asociaciones de países a diario

Al principio, comencé a dividir esto en dos historias de usuarios. Sin embargo, la segunda tarea no encaja realmente en un formato típico de historia de usuario. Empecé a escribir algo como esto:

Como sistema, analizaré los datos del país del feed XYZ.

Por un lado, esta tarea no está centrada en el usuario. Por otro lado, la capacidad de obtener componentes: datos de países es una tarea bien definida, dividida verticalmente, que se puede verificar de forma independiente.

¿Cuál es el desglose adecuado de la historia de usuario para este tipo de escenario? ¿Es incorrecto tener una historia de usuario centrada en el sistema?

¿Por qué tienes que dividirlo en absoluto? Parece que obtener los datos del país será parte del acto de poder excluirlo.
@Daniel Estoy considerando dividirlo porque cada elemento representa una funcionalidad bien encapsulada, y cualquier estimación requiere una revisión distinta de cada función independiente.

Respuestas (3)

Preste atención a la 'V' en el mnemotécnico INVEST .

Una PBI debe entregar valor a los grupos de interés.

Pregúntese: por sí misma , ¿la capacidad de analizar los datos del país del feed XYZ proporciona algún valor a las partes interesadas del proyecto?

Si es así: bien, divídalo. Si no: no, manténgalo como está (o posiblemente divídalo de alguna otra manera que no invalide INVEST.

Nota: 'El Sistema' probablemente no sea una parte interesada del proyecto.

Vale la pena señalar que Sarov usa el término PBI, no historia de usuario. La computadora no quiere nada, por lo que no debería ser el "quién" en la historia del usuario. Averigua quién realmente lo quiere o no uses una historia de usuario. Scrum no dice que todos los PBI deben ser historias de usuarios. Esto puede parecer dogmático, pero esta práctica realmente diluye el valor de las historias de los usuarios.

Las tareas pendientes de Sprint no son inherentemente historias de usuarios

Estás combinando historias de usuario y tareas. Los elementos de la Lista de Producto a menudo comienzan como historias de usuario en la Lista de Producto, pero Scrum no exige el formato de historia de usuario. Esos elementos del Product Backlog se importan al Sprint Backlog durante la Planificación del Sprint. Las historias a menudo se refinan aún más en ese punto, y las historias y tareas adicionales relacionadas con el trabajo planificado a menudo se generan a lo largo del Sprint.

Sin embargo, el punto clave es que las tareas no necesitan ser historias de usuario completas, incluso si su Product Backlog usa el formato. Continúe y use historias de usuario cuando tenga sentido, pero los detalles de implementación rara vez tienen sentido como una historia de usuario porque:

  1. El consumidor de valor suele ser el equipo, porque los detalles de implementación sirven al equipo o al sistema en lugar de a un usuario.
  2. No hay conversación fuera del equipo, porque el equipo es el consumidor de la tarea.
  3. A menudo no hay conversación para tener en absoluto. Por lo general, cuando algo se descompone al nivel de "analizaré X de Y", el equipo ya ha tenido las discusiones de planificación y diseño en torno a la implementación y ha diseñado las pruebas para el trabajo planificado.

Las historias de usuario son marcadores de posición de conversación y, por lo general, brindan un valor al consumidor, una descripción abreviada de la función y algo de contexto para guiar la implementación y las discusiones de seguimiento. ¡Las historias de usuario no son especificaciones! Por lo tanto, no restrinja demasiado su proceso tratando de calzar los detalles de implementación o las especificaciones en el formato de la historia del usuario. Por lo general, no vale la pena exprimir el jugo.

Acepto que la búsqueda diaria de bases de datos podría ser una tarea que forma parte de la historia de usuario solicitada.

Pero si, por alguna razón, no quiere o no puede trabajar en ambas tareas en el mismo sprint, podría ser útil centrarse en el valor (que sería) entregado.

La tarea de obtención de la base de datos no brinda ningún valor al usuario, pero brinda valor al PO al reducir el costo de implementar la historia del usuario.

Desglose de la historia de usuario: tarea técnica + función de usuario
RespuestasAquíPolítica de privacidad1y, 0v