Entonces, por lo que entiendo al leer los tutoriales en el sitio web de Atlasian, el administrador del proyecto completa el trabajo pendiente y puede contener entradas tan abstractas como quiera, con varios grados de importancia. La cartera de pedidos puede (y debe) cambiar constantemente para reflejar las necesidades del mercado y la retroalimentación que recibe el producto. En la planificación del sprint, el equipo analiza el backlog, discute los problemas, trata de estimarlos (ya sea con puntos de la historia, tiempo o lo que le guste al equipo). El equipo escoge del backlog lo que se debe hacer en este sprint (teniendo en cuenta el grado de importancia establecido por el manager). Los cambios adicionales en el backlog no afectarán este sprint. ¿Tengo razón? Parece que me estoy perdiendo algo. ¿Debería el equipo revisar todo lo que está pendiente y tratar de dar estimaciones aproximadas? ¿O detenerse cuando sienta que debería detenerse? Esta parte no me queda clara. ¿Cómo es exactamente que el equipo saca el trabajo del backlog al sprint?
el backlog es llenado por el gerente del proyecto
Scrum, tal como se define , no tiene un rol llamado "gestor de proyectos". Solo hay tres roles: Propietario del producto, Scrum Master y Equipo de desarrollo. El Propietario del Producto es responsable de mantener el Product Backlog.
y puede contener entradas tan abstractas como quiera, con varios grados de importancia
Eso es técnicamente cierto. El propietario del producto pone todo: características y funcionalidades, mejoras, correcciones y otros elementos de trabajo en la cartera de productos. Sin embargo, para que el equipo de desarrollo pueda tomar medidas, debe haber suficiente información en el elemento pendiente. El orden de los elementos en el Product Backlog indica su importancia: las historias más importantes deben estar en la "parte superior".
Para las historias más abstractas, el equipo de desarrollo trabaja con el propietario del producto para realizar mejoras. Los documentos de Scrum sugieren que esta actividad es aproximadamente el 10% de la capacidad del Equipo de Desarrollo. Es decir, en un equipo de 5 que trabajan una semana estándar de 40 horas, puede esperar como máximo 20 horas de refinamiento. El refinamiento puede ser discusiones, creación de esquemas, creación de prototipos u otras cosas para aclarar la intención. El equipo de desarrollo quiere que los elementos que se encuentran en la parte superior de la cartera de pedidos se entiendan bien en la planificación del Sprint.
La cartera de pedidos puede (y debe) cambiar constantemente para reflejar las necesidades del mercado y la retroalimentación que recibe el producto.
Sí, el propietario del producto puede reordenar los artículos en la cartera de productos. Sin embargo, puede haber dependencias técnicas en algunas de las historias. El equipo de desarrollo debe tener información sobre el orden de trabajo para garantizar la calidad del producto desde una perspectiva técnica.
En la planificación del sprint, el equipo analiza el backlog, discute los problemas, trata de estimarlos (ya sea con puntos de la historia, tiempo o lo que le guste al equipo). El equipo elige del backlog lo que se debe hacer en este sprint (teniendo en cuenta el grado de importancia establecido por el gerente).
El refinamiento debe ser una actividad continua para comprender los próximos cambios, ya que estos pueden guiar el diseño y la implementación del resto del sistema. Pero como regla general, la reunión de planificación de Sprint intenta determinar qué trabajo se puede hacer en el próximo Sprint y cómo hacer ese trabajo.
El equipo no solo debe elegir al azar de la lista de productos, sino que, en general, debe ir de arriba hacia abajo. Puede haber algunas excepciones: algunos elementos que no se comprenden bien o las dependencias técnicas en historias de menor prioridad son dos ejemplos.
La cantidad de trabajo seleccionado del Product Backlog y colocado en el Sprint Backlog se basa en el equipo. Si el mismo equipo ha estado ejecutando el proyecto usando Scrum por un tiempo, los desempeños previos de Sprint son una buena base. Es complicado hacerlo bien en los Sprints iniciales para un nuevo proyecto o un equipo que tiene nuevas personas en él.
Los cambios adicionales en el backlog no afectarán este sprint.
El Equipo de Desarrollo posee el Sprint Backlog. Siempre hay espacio para colaborar con el Product Owner para cambiar el Sprint. Por ejemplo, si se requiere corregir un error de mayor prioridad, se puede cambiar un error de menor prioridad o una nueva característica. Sin embargo, dado que Scrum (y los métodos ágiles) tienen que ver con el rendimiento sostenible, no querrá agregar trabajo al azar; querrá asegurarse de que las cosas que se agregan también tengan elementos eliminados.
El Dueño del Producto mantiene el Product Backlog aislado del Sprint Backlog, y los cambios no afectarán al Sprint actual.
¿Debería el equipo revisar todo lo que está pendiente y tratar de dar estimaciones aproximadas? ¿O detenerse cuando sienta que debería detenerse?
Los miembros del equipo de desarrollo que participan en las actividades de perfeccionamiento (que deberían ser la mayoría, si no todos, del equipo) deberían poder obtener estimaciones aproximadas del esfuerzo necesario para realizar el trabajo. Sin embargo, una vez que los Elementos del Backlog se comprenden lo suficiente, el equipo solo necesita determinar que su Sprint está cargado a una capacidad adecuada. No necesitan estimar cada artículo. También pueden refinar las estimaciones a medida que aprenden más sobre el espacio del problema.
¿Cómo es exactamente que el equipo saca el trabajo del backlog al sprint?
Es metódico: el equipo comienza en la parte superior del Product Backlog y llena el Sprint Backlog hasta que alcanza su capacidad. Lo hacen una vez al comienzo del Sprint.
nvoigt
alan larimer