En la primera parte de esta serie de dos post sobre cómo descomponer historias de usuario en tareas (te recomiendo aquí este post sobre historias de usuario), vimos algunos ejemplos típicos de tareas. En esta segunda parte os dejo algunas recomendaciones y buenas prácticas a tener en cuenta a la hora de hacer esa descomposión.
Buenas prácticas para descomponer historias de usuario en tareas
– A la hora de descomponer historias de usuario en tareas, intenta que el tamaño de las tareas sea de entre medio día hasta un máximo de 3 o 4 días de trabajo de un solo miembro del equipo. Tareas más pequeñas suelen conllevar grandes pérdidas de tiempo a la hora de gestionarlas. Por otro lado, las tareas de más de 3 o 4 días de trabajo, se pueden dividir en otras tareas, si es posible, con el fin de no ocupar demasiado tiempo y ser completadas de manera eficiente.
– Crear tareas que una vez completadas generen un producto entregable. Por ejemplo, en vez de tareas como “Construir la interfaz de usuario”, “Construir la lógica de negocio” o “Construir la capa de persistencia”, una división que se recomendaría para este tipo de funcionalidad seria “Implementar el módulo de inserción de un nuevo usuario”, “Implementar el módulo de actualización de un usuario”, o “Implementar el módulo de eliminación de un usuario”. Así cuando se complete una tarea se podrá generar un producto entregable. A su vez estas tareas no dependen de la finalización de otras para ser probadas.
– No dedicar excesivo tiempo a estudiar todos los detalles de cada tarea. Suele ocurrir que una vez definida la tarea, el siguiente paso sea su estimación, y que para ello el equipo quiera definir y conocer todos los detalles posibles de la misma. Aunque, efectivamente, este análisis ayuda a realizar estimaciones más precisas, puede demorar en gran medida el proceso de división de las historias de usuario en tareas.
– En el conjunto de tareas, a la hora de descomponer historias de usuario en tareas, deben estar incluidas tareas de pruebas y su posible automatización.
¿Alguien se anima a dejarnos algún ejemplo más, o recomendación, sobre descomponer historias de usuario en tareas? Lo vemos en los comentarios o por twitter (@jgarzas)
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
- Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
- Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025
Pingback: Bitacoras.com
Yo intentaría dividir las tareas por módulo, ya que algunas pe. incluyen administración y reportes.
Fuera de la descomposición también estaría la priorización.
Pingback: Historia de Usuario | Business World TI
100 x100 de acuerdo, llevar un control del flujo de tareas mediante aplicaciones que permitan guardar junto con la historia los problemas surgidos y solucines adoptadas, el tiempo de permanencia de la tarea y los recursos humanos y tecnicos implicados, así como acopiar metodologias o comentarios cortos que aumenten el conocimiento del aplicativo en desarrollo.
Al tener tareas que demoren más de un día, esto no afecta la medición de la velocidad del equipo?
Creo que a mi me pasó lo de descomponer mucho, el equipo estuvo cómodo con el resultado pero fue demorado. Pongo a continuación el ejemplo de la historia:
Como: Certificador de bonos pensionales
Quiero: emitir certificado de información laboral (F1) para bonos pensionales a los exempleados de EADE
Para: informar a la entidad responsable del pago de la pensión la información relevante para el cálculo del bono pensional
Criterios de Aceptación:
1. Información del certificado: seguir el formato entregado por el usuario.
2. que cuando se genere un duplicado, lo imprima y diga DUPLICADO en el reporte.
3. El archivo en PDF se nombrará de la siguiente forma: NombrePlantilla_numCedula_Fecha.PDF
EJ: F1_1234567_20150715.PDF
4. Si se genera tantas líneas que se den varias páginas del certificado, se debe repetir por cada página el encabezado que consiste del título, sección A, B y C.
5. El escudo del formato de ejemplo cambia el escudo de Colombia por el de logo de EPM.
6. La fecha en que entró en vigencia el Sistema General de pensiones para ese empleador debe ser parametrizable en la aplicación.
Las tareas en detalle total, no faltó ni una coma, creo nos quedaron con diseño incluido:
Tarea1:
* Crear Tabla Información General del exfuncionario con los siguientes campos:
• Tipo Identificación TAXC PK
• Número de identificación (AB) TAX PK
• Nombres (AA) ALPH
• Apellidos (AA) ALPH1
• Fecha de nacimiento (AAAAMMDD) (AE, AD, AC) DOB
• Trabajador migrante (BE) EV01 (S ó N)
• Otorgó indemnización sustituta (BF) EV02
• Pensionado por otra entidad (BG) EV03
• Hay indicios que fue pensionado por otra entidad (BH) EV04
• Consecutivo UKID
• Version Ejecutada VERS
• Entidad a la que perteneció KY PK
• Usuario USER
• Programa PID
• Maquina JOBN
• Fecha UPMJ
• Hora UPMT
* Crear UDC de entidad a quien certifica (EPM-NIT, EADE-NIT)
* Vista All Columns Tabla Información General del exfuncionario»
Tarea 2:
* Crear Tabla Información de las entidades de fondos de pensiones:
• Nit TAX PK
• Nombre de Entidad ALPH
• Tipo Entidad EV01
• Usuario USER
• Programa PID
• Maquina JOBN
• Fecha UPMJ
• Hora UPMT
* Crear UDC de tipo de entidad (Publico ó Privado)
Tarea3:
* Crear Tabla Información de la entidad certificadora:
• Nit Certificadora (D,N) TAX PK
• Razón Social (C,M) ALPH
• Dirección (E, O) ADD3
• Ciudad (F, P) CTY1
• Código DANE Ciudad (G,Q) AA02
• Departamento (H,R) DL01
• Código DANE Departamento (I, S) AA04
• Teléfono (J, V) PH1
• Fax (K, W) PH2
• Email (L, U) EMAL
• Sector (T) EV01
• Nit a quien certifico CTAX PK
• Usuario USER
• Programa PID
• Maquina JOBN
• Fecha UPMJ
• Hora UPMT
* Crear UDC de tipo de Sector(N:Nacional, D:Departamental o Distrital, M:Municipal)
»
Tarea4:
* Crear Tabla Informacion Vinculaciones laborales:
• Número de identificación TAX PK
• Fecha Inicio (AAAAMMDD) (AH, AG, AF) BGDATE PK
• Fecha Fin (AAAAMMDD) (AK, AJ, AI) ENDDATE PK
• Nit de Entidad empleadora (AL) CTAX PK
• Cargo (AM) CTDESC
• Fecha Inicio Interrupción (AAAAMMDD) (AP,AO,AN) TRDJ
• Fecha Fin Interrupción (AAAAMMDD) (AS, AR,AQ) ADDJ
• Días totales de Interrupción (AT) MATH80
• Usuario USER
• Programa PID
• Maquina JOBN
• Fecha UPMJ
• Hora UPMT
Tarea9:
* Creacion Plantilla Word y asociacion de campos de XML
:-O
Una tarea debe tener ese nivel de detalle técnico o es responsabilidad del equipo scrum?
Debe realizarse el análisis de base de datos por parte del product owner o es responsabilidad del equipo técnico?
Eso parece una descripción de diseño detallado.
Buenas tardes,
He estado leyendo sobre el tema de User Story Mapping y el orden no sería primero hacer las tareas de usuario que son acciones y después a partir de ellas hacer las historias de usuario manejables (o sea no épicas).
En plena ejecución de un sprint, el producto owner solicito cambiar una historia, por otra del back log (no priorizada), el equipo realizó la evaluación del impacto en esfuerzo y tiempo, y se realizó el cambio de la historia, al finalizar la fecha fin del sprint no se vio impactado, esto sería una practica de mucho riesgo?
No…
En mi caso tengo una HU dividida en 4 subtareas, de las cuales según la reunión con el grupo cada subtarea se estimo con 1 story points. Mi pregunta es: La suma de todas esas estimaciones es el total de mi HU completa??.