Estamos trabajando en un equipo Agile Scrum. Mencionan que es una buena práctica trabajar primero en las tareas de PBI mediante Sprint Backlog Priority en el desarrollo de código.
A veces,
¿Cuáles son las reglas para trabajar en Sprint Story PBI en orden? ¿Es una regla estricta o se puede ajustar? Obviamente, el elemento PBI prioritario tiene la mayor importancia, sin embargo, ¿se pueden acomodar las cosas durante el cronograma?
A diferencia del Product Backlog, que es una "lista ordenada de lo que se necesita para mejorar el producto", la Guía Scrum no especifica si el Sprint Backlog está ordenado o, si lo está, cómo se ordena. En cambio, describe el Sprint Backlog como un "plan por y para los desarrolladores" y una "imagen altamente visible y en tiempo real del trabajo que los desarrolladores planean realizar durante el Sprint para lograr el Sprint Goal".
Dado que el Sprint Backlog es creado y mantenido por y para los Desarrolladores, entonces los Desarrolladores pueden elegir si ordenarlo y cómo hacerlo.
Al elegir el trabajo, los desarrolladores tienen muchas cosas que considerar. Tal vez sea mejor hacer un trabajo rápido al principio del Sprint. Otro enfoque es asumir primero el trabajo más riesgoso para permitir que los problemas potenciales surjan temprano. Otro enfoque más es asumir el trabajo más importante. Independientemente del orden, los desarrolladores deben considerar el Sprint Goal al elegir en qué trabajar. La máxima prioridad del equipo para el Sprint es lograr el Sprint Goal.
¿Cuáles son las reglas para trabajar en Sprint Story PBI en orden?
No hay ninguno.
Todas las cosas que menciona son razones sensatas por las que es posible que no vaya en estricto orden de prioridad.
Sin embargo, es posible que desee discutir algunas de estas razones en sus retrospectivas. ¿Es posible que, al cambiar el enfoque que adopta el equipo, pueda hacer que estas excepciones sean menos frecuentes?
Mencionan que es una buena práctica trabajar primero en las tareas de PBI mediante Sprint Backlog Priority en el desarrollo de código.
No hay prioridad de acumulación de sprint. Así que no, esta no es la mejor práctica.
Sin embargo, hay un objetivo de sprint . Este es el foco del sprint. Y como tal, probablemente debería estar trabajando en un PBI que sea necesario para alcanzar ese objetivo. Si no lo hace, no se está enfocando en lo correcto.
Sin embargo, el orden en el que se trabajan los PBI depende del equipo de desarrollo, por lo que puede mencionarlo en la retrospectiva para obtener una directiva más abstracta o discutirlo rápidamente en el stand-up diario cuando realiza una nueva tarea para el día, en esa situación específica.
El equipo solo debe agregar a un sprint las cosas que cree que se pueden completar al final del sprint. Estos son generalmente elementos de alta prioridad en la cartera de productos. Dado que la expectativa es que todo estará terminado al final del sprint, no debería haber necesidad de priorizar dentro de un sprint, excepto quizás si hay riesgos o dependencias que hacen que sea prudente hacer las cosas más temprano que tarde. El propio equipo puede decidir si se debe priorizar algo por encima de cualquier otra cosa.
Cuando los equipos adoptan un sistema de extracción, puede haber una convención sobre qué artículos deben recogerse a continuación. Estas convenciones suelen ser informales y subjetivas porque algunos miembros del equipo pueden sentirse más capacitados para trabajar en algunos elementos que en otros.
Mencionan que es una buena práctica trabajar primero en las tareas de PBI mediante Sprint Backlog Priority en el desarrollo de código.
La cartera de pedidos del sprint es un subconjunto de la cartera de pedidos del producto recogida por el equipo durante la sesión de planificación del sprint en función de las prioridades establecidas por el propietario del producto, cuyo trabajo es garantizar que el equipo trabaje en aquellos PBI que se considera que agregan más valor.
Cuando algunas de las primeras historias prioritarias son difíciles y necesito tiempo para pensar/tomar un descanso (mentalmente, me gusta alternar entre tareas difíciles y fáciles cuando estoy atascado), hace que sea más fácil para la cabeza, puedo volver y trabajar en la historia con la mente fresca
Aquí parece estar planeando realizar múltiples tareas y, en general, se ha demostrado científicamente que las multitareas especialmente realizadas en más de 2 tareas son menos eficientes. Si realmente puede administrar múltiples tareas y con una mente "fresca", ¡buena suerte y siga adelante e inténtelo! No creo que Scrum tenga recomendaciones estrictas aquí.
¿Cuáles son las reglas para trabajar en Sprint Story PBI en orden?
Como ya mencionaron otras personas, Scrum en sí mismo no impone ninguna regla propia. El backlog de Sprint es "propiedad" del equipo: es su compromiso y, por lo tanto, usted y otras personas en un equipo pueden decidir el orden en el que se secuencian y desarrollan esos PBI, lo que mejor se adapta a su estilo de trabajo, como equipo. Dado que el equipo autoorganizado se ha "comprometido" para entregar la acumulación de sprint, el resto de la gente del equipo (SM y PO y otras partes interesadas clave) "confiarán" en que las cosas se harán.
Obviamente, el elemento PBI prioritario tiene la mayor importancia, sin embargo, ¿se pueden acomodar las cosas durante el cronograma?
"Programación" es la duración de su sprint (que suele ser de 1 a 4 semanas) y durante la planificación del sprint, el PO y el equipo de desarrollo han "acordado" cuáles son los PBI prioritarios para este sprint. Entonces, mientras el trabajo "comprometido" sea entregado por el equipo, se logrará el objetivo del sprint.
¿Qué quieres decir con "historias de usuario duras"? ¿Más grande o más complejo de lo habitual?
Tenemos aquí dos Backlogs: el primero son PBI, mientras que el segundo son Sprint Backlog Items. Inicialmente, los PBI deben organizarse y ordenarse de acuerdo con la prioridad comercial. Creo que aquí, debe comprometerse con las prioridades del usuario final como se describe en los PBI, donde cada PBI debe ser una característica del usuario; esta característica puede ser una historia de usuario o épica.
Antes de cambiar algunos elementos de PBI a elementos de Sprint Backlog, debe analizar y comprender cada PBI. Aquí puede hacer una estimación precisa de qué tan difícil es este elemento y cuánto tiempo se necesita para HACERLO.
Puede ser una tarea difícil asignar cada función de usuario a un elemento en PBI, pero a medida que comprenda estas funciones, podrá determinar los elementos que deben cambiarse de PBI a elementos de Sprint Backlog y esto también depende de la duración del sprint.
No existe una regla sobre cómo comenzar a implementar los elementos del Sprint Backlog. De todos modos, debes terminar tu sprint con elementos DONE. Usted y su equipo seleccionan el orden de acuerdo con más cosas, como la lógica de implementación.
Mire el sprint como un hito único y divídalo en tareas relacionadas con su equipo. Al usuario final no le importa la cantidad de dureza de la historia, ni con sus esfuerzos, puede pensar en las cosas de otra manera.
Trate de no medir el artículo por difícil o fácil. Tienes que mirar el sprint como un todo, porque el sprint contiene elementos que pueden ser fáciles o difíciles, pero aún así deben caber dentro de un sprint, y esto depende de una planificación y estimación precisas.
Estoy un poco perplejo por esta situación.
En mi organización, una historia no ingresa al Sprint Backlog hasta que ya está escrita y todos los criterios de aceptación se verifican y firman. Así que siempre estoy trabajando en los elementos de PBI, preparándolos para el próximo Sprint. Por lo general, estoy al menos un Sprint por delante; de esa manera nunca tenemos este problema.
¡Espero que ayude!
MCW