Estoy tratando de entender el siguiente problema: dentro de un marco SAFe, un equipo de desarrollo agrega historias de usuarios después del compromiso, aunque ese compromiso no se haya cumplido. La justificación es que si estas nuevas historias de usuarios no se completan, las épicas/características más grandes estarán en peligro.
Como nota al margen, este equipo dedica una cantidad excesiva de tiempo a la planificación durante la planificación de la iteración.
Mi pregunta es: ¿Deberían contarse estas nuevas historias de usuario como tareas?
Mi confusión es sobre el principio de "solo lo suficiente para comenzar" durante la planificación de la iteración. Como en cada historia, debe tener la información suficiente para que los miembros del equipo comiencen a trabajar en ellas. Si durante el curso de la colaboración se descubren nuevas dependencias o trabajo, ¿eso constituye una nueva historia de usuario?
Mi opinión es que estos deberían enumerarse como tareas, y si hay ambigüedad, eso debería tenerse en cuenta en la estimación.
Cualquier pensamiento, idea o comentario es bienvenido.
Su pregunta es bastante amplia y toca varios problemas, pero lo bueno es que todo está relacionado con los elementos pendientes de una forma u otra.
Estoy tratando de entender el siguiente problema: dentro de un marco SAFe, un equipo de desarrollo agrega historias de usuarios después del compromiso, aunque ese compromiso no se haya cumplido. La justificación es que si estas nuevas historias de usuarios no se completan, las épicas/características más grandes estarán en peligro.
Independientemente del marco, las historias de usuario siempre deben ser priorizadas y seleccionadas por la persona o el equipo del producto en función de la prioridad empresarial. Las historias de usuario son de naturaleza amplia e idealmente tienen propiedades INVEST . Habiendo dicho eso, durante la reunión de planificación, el equipo de desarrollo puede por todos los medios influir en el producto/persona/s de negocios para seleccionar algunos requisitos de baja prioridad por razones técnicas. Entonces, la pregunta es, ¿por qué el equipo de desarrollo no mencionó este razonamiento relacionado con la "epopeya más grande" durante la reunión de planificación?
Sin embargo, tenga en cuenta que el equipo de desarrollo es libre de agregar, eliminar y editar sus propias tareas técnicas para cumplir con el objetivo de la iteración. Además, es normal que el equipo negocie, durante la iteración, con la gente del producto para hacer cambios en las historias. Sin embargo, en mi opinión, hay algo mal con sus reuniones de planificación si esto sucede con frecuencia y afecta a más de un puñado de historias.
Como nota al margen, este equipo dedica una cantidad excesiva de tiempo a la planificación durante la planificación de la iteración.
Debes asegurarte de que se refina el producto y experimentar con el zumbador bul**** o simplemente con un temporizador como el que se muestra a continuación colocándolo en la pantalla grande: http://oss.jahed.io/agility/timer.html
Mi pregunta es: ¿Deberían contarse estas nuevas historias de usuario como tareas?
Las historias de usuario son diferentes de las tareas. Como se mencionó anteriormente, las historias de usuarios están escritas por o con la gente del producto. Las tareas son actividades detalladas que se deben completar para completar una historia de usuario en particular. Las tareas generalmente son escritas por o con los desarrolladores. Incluso están escritos en diferentes formatos y estilos. Puede llamar a las historias de usuario y las tareas como quiera, siempre que comprenda la diferencia (en serio, no se le ocurran nombres nuevos para los elementos pendientes).
Mi confusión es sobre el principio de "solo lo suficiente para comenzar" durante la planificación de la iteración. Como en cada historia, debe tener la información suficiente para que los miembros del equipo comiencen a trabajar en ellas. Si durante el curso de la colaboración se descubren nuevas dependencias o trabajo, ¿eso constituye una nueva historia de usuario?
El trabajo justo o emergente son conceptos ágiles clave que minimizan el despilfarro y aumentan el enfoque de un equipo en la entrega de los elementos más valiosos primero. Sin embargo, esto no significa que los desarrolladores comiencen sin un plan detallado. Junto con el refinamiento de la cartera de pedidos, también lea sobre la Definición de Listo (DoR). La idea básica es que los elementos del backlog que las personas del producto quieren que se realicen durante la próxima iteración estén lo suficientemente detallados y cumplan con el DoR acordado por el equipo. Habiendo dicho eso, tenga en cuenta que el equipo no podrá descomponer cada historia de usuario durante la reunión de planificación. Deberían descomponer suficientes historias para los primeros días. El resto de las historias de usuario se descompondrán regularmente a medida que avanza el sprint. Asegúrese de que las siguientes historias de usuario más valiosas ya estén descompuestas y listas para su implementación antes de que se completen las historias de usuario actuales. Imagine mini reuniones de planificación que se llevan a cabo casi todos los días, según la duración de la iteración.
Tomas Owens
Tomas Owens
Josué
Josué
Tomas Owens
Josué
nathan cooper
alan larimer