Soy bastante nuevo en Scrum y estoy trabajando con un grupo de colegas en un proyecto para aprender más sobre él. Para resumir, nuestro proyecto es simplemente crear un sitio web para turistas de nuestro país donde puedan simplemente crear o usar cursos en una ciudad determinada.
Lo que hicimos fue pensar en las historias de los usuarios (realmente no hicimos ninguna investigación de UX, así que solo considera estas historias como válidas) que son relevantes para lo que queremos hacer. Por ejemplo, considere la siguiente historia:
Como turista, quiero crear cursos de acuerdo a mis requerimientos.
Este es solo un ejemplo, tenemos alrededor de otras 15 historias. Y como somos nuevos en este proceso, definimos tareas de historias que vimos que encajaban más con la historia. Por ejemplo, necesitamos crear una página de inicio de sesión/registro, pero no pudimos crear una historia para ella, así que la incluimos en la historia más relevante. Así que hay pocas historias con tareas extra. Y dado que seguimos este enfoque, en realidad estimamos las tareas y no las historias (¿algo un truco?). Ahora, el problema al que nos enfrentamos es que necesitamos usar una herramienta Scrum para ayudarnos a visualizar nuestro trabajo, elegimos TargetProcess, que es gratuito. En esta herramienta, obviamente, se asignan puntos de historia a las historias, mientras que a las tareas se les asigna una estimación por horas, y cada tarea es parte de una historia. Ahora bien, si necesitamos trabajar en una tarea, no podemos hacerlo a menos que traslademos toda la historia al Sprint Backlog. Entonces, si una historia tiene solo una tarea planificada en el sprint y el resto no, eso crearía un problema en la creación de nuestros gráficos de trabajo pendiente. Así que mi pregunta aquí es ¿qué podemos hacer para que esto funcione?
Parece que sus historias de usuario son demasiado gruesas y no lo suficientemente independientes.
Recomendaría que trabaje con su acumulación y desglose sus historias de usuario haciéndolas mucho más pequeñas y al mismo tiempo siendo completamente independiente o lo más independiente posible.
Debe tomar entre 1 y 3 días para que se complete una historia de usuario. Si es más grande que esto, es probable que necesites descomponerlo.
Este es un gran recurso para desglosar las historias de los usuarios: http://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flowchart.pdf
En mi experiencia, las tareas de estimación de tiempo no son tan útiles. Concéntrese en crear y estimar pequeñas historias independientes y las tareas son opcionales según el desarrollador que retome la historia.
Las tareas son las actividades técnicas que realizará 1 desarrollador o un par de desarrolladores para cumplir con los criterios de aceptación de la historia. Las tareas nunca deberían tardar días en completarse.
Bienvenida a la comunidad, Amina.
Si bien no se prescribe explícitamente en la Guía de Scrum, la forma en que elige dividir el trabajo durante el refinamiento es una parte integral de la construcción de su solución de manera iterativa e incremental.
Hay una serie de modelos para ayudar con esta parte del rompecabezas. Uno de los modelos más utilizados es el modelo INVEST de desglose de historias de usuarios. El modelo INVEST establece:
Una buena historia de usuario debe ser:
"Yo" independiente (de todos los demás)
"N" negociable (no es un contrato específico para funciones)
"V" valorable (o vertical)
"E" stimable (a una buena aproximación)
Centro comercial "S" (para que quepa dentro de una iteración)
"T" estable (en principio, aunque todavía no hay una prueba para ello)
Quizás esto ya sea parte de tu proceso, pero también es importante tener criterios de aceptación realmente claros para cada historia. Este criterio de aceptación debe provenir de su propietario del producto y negociarse con el equipo una vez que crean que el criterio se ha disparado más allá de un pequeño esfuerzo. En última instancia, el equipo gestiona su trabajo, pero tener criterios de aceptación sólidos por parte de un propietario del producto es el primer paso para capacitarlos para que sean dueños de dicho trabajo.
Tener criterios de aceptación sólidos no solo ayuda a administrar la historia, sino también a administrar las tareas necesarias para completar la historia, lo que suena como el problema que está tratando de resolver. Siempre que sus historias estén bien INVERTIDAS y tengan buenos criterios de aceptación, su equipo debería poder encontrar costuras lógicas en las historias (por lo tanto, tareas) para ayudar a manejar este problema mucho mejor.