Diferencia entre revisiones de «Glosario de Scrum»
(Página creada con 'Traducir el glosrio de términos. ==== Gráfico de Burndown ==== Los gráficos de Burndown muestran el trabajo restante en el tiempo. El trabajo restante es el eje Y y el tiem…') |
(→Miembro del equipo) |
||
(No se muestran 9 ediciones intermedias del mismo usuario) | |||
Línea 1: | Línea 1: | ||
− | + | El siguiente glosario de términos de [[Scrum]] es una traducción de [http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms Glossary of Scrum terms], publicado en inglés por Victor Szalvay de la Scrum Alliance. | |
==== Gráfico de Burndown ==== | ==== Gráfico de Burndown ==== | ||
Línea 16: | Línea 16: | ||
Los libros de Scrum recomiendan que esta reunión sea lo primero que ocurra a la mañana, ni bien lleguen todos los miembros del equipo. | Los libros de Scrum recomiendan que esta reunión sea lo primero que ocurra a la mañana, ni bien lleguen todos los miembros del equipo. | ||
− | == Ver también == | + | ==== Impedimentos ==== |
− | * | + | Un impedimento es cualquier cosa que le impida al equipo desempeñarse lo más eficientemente posible. Cada miembro del equip puede anunciar un impedimento durante la Reunión diaria de Scrum. El ScrumMaster está a cargo de resolver los impedimentos. Los ScrumMaster a menudo organizan reuniones paralelas cuando no se puede resolver un impedimento en la reunión diaria de Scrum. |
+ | |||
+ | ==== Backlog del producto ==== | ||
+ | El Backlog del Producto (o "backlog") contiene los requerimientos del sistema, expresados como una lista priorizada de elementos del backlog del producto. Esto incluye requerimientos del cliente funcionales y no-funcionales, y también requerimientos técnicos generados por el equipo. Aunque existen muchas entradas al backlog del producto, el Dueño del Producto es el único responsable por priorizar los elementos del backlog. | ||
+ | |||
+ | Durante la reunión de planificación del sprint, los elementos del backlog se mueven del backlog del producto hacia un sprint, basándose en las prioridades establecidas por el Dueño del Producto. | ||
+ | |||
+ | ==== Elemento del backlog del producto ==== | ||
+ | En Scrum, un elemento del backlog del producto ("PBI", "elemento del backlog", o "elemento") es una unidad de trabajo lo suficientemente pequeña para que el equipo pueda completarla en un sprint (iteración). Los elementos del backlog se descomponen en una o más tareas. | ||
+ | |||
+ | Ver también unidad de estimación de esfuerzo del backlog. | ||
+ | |||
+ | ==== Esfuerzo para un elemento del backlog del producto ==== | ||
+ | Algunas personas estiman es esfuerzo de los elementos del backlog del producto en días ideales, aunque otras personas prefieren unidades de estimación menos concretas. Las unidades alternativas pueden ser puentos de historia, puntos de función, o "tamaños de remera" (1 para pequeño, 2 para medio, etc.). La ventaja de estas unidades más vagas es que son explícitas en distinguir que el esfuerzo de los elementos del backlog del producto no son estimaciones de duración. También, las estimaciones a este nivel son aproximaciones burdas que nunca deben confundirse con horas de trabajo reales. | ||
+ | |||
+ | Nótese que las tareas del sprint son distintas de los elementos del backlog del sprint, y el esfuerzo restante de las tareas siempre se estima en horas. | ||
+ | |||
+ | ==== Gráfico de burndown del producto ==== | ||
+ | En Scrum, el gráfico de burndown del producto es una vista "general" del progreso del proyecto. Muestra cuánto trabajo restante hay al comienzo de cada sprint. El alcance de este gráfico abarca todas las entregas; sin embargo, un gráfico de burndown de entrega se limita a una única entrega. | ||
+ | |||
+ | ==== Rol de Dueño del Producto ==== | ||
+ | En Scrum, hay una única persona que tiene la autoridad final representando los intereses del cliente, priorizando el backlog y respondiendo preguntas sobre los requerimientos. | ||
+ | |||
+ | Esta persona debe estar disponible para el equipo en cualquier momento, especialmente durante la reunión de planificación del sprint y durante la reunión de demo del sprint. | ||
+ | |||
+ | Los desafíos de ser un Dueño del producto: | ||
+ | # Resistir la tentanción de "gestionar" al equipo. El equipo puede no organizarse de la forma esperada. Esto resulta especialmente dificil si algunos miembros del equipo piden la intervención sobre temas que el equipo debería resolver por si mismos. | ||
+ | # Resistir la tentación de agregar más trabajo importante después de iniciado un Sprint. | ||
+ | # Estar dispuesto a tomar decisiones difíciles durante la reunión de planificación del sprint. | ||
+ | # Balancear los intereses opuestos de interesados externos. | ||
+ | |||
+ | ==== Entrega ==== | ||
+ | Una entrega es la transición de un incremento potencialmente productivo del producto en algo que los clientes usen rutinariamente. Las entregas suelen ocurrir cuando uno o más sprints resultan en que el producto tiene suficiente valor como para superar el costo de desplegarlo. | ||
+ | |||
+ | "El producto se entrega al cliente o a las obligaciones del mercado. La entrega balancea funcionalidad, costo, y requerimientos de calidad contra la fecha comprometida". (Schwaber/Beedle, Agile Software Development with Scrum, p. 80). | ||
+ | |||
+ | ==== Gráfico de burndown de la entrega ==== | ||
+ | En Scrum, el gráfico de burndown de la entrega brinda una visión "general" sobre el progreso de la entrega. Muestra cuánto trabajo queda hacer al principio de cada sprint, para una única entrega. El alcance de este gráfico es una única entrega; sin embargo, un gráfico de burndown del producto abarca todas las entregas. | ||
+ | |||
+ | |||
+ | ==== Roles de Scrum ==== | ||
+ | Hay tres roles en cualquier proyecto de Scrum: | ||
+ | * Dueño del producto | ||
+ | * ScrumMaster | ||
+ | * Equipo | ||
+ | |||
+ | ==== Rol de ScrumMaster ==== | ||
+ | El ScrumMaster es una facilitador para el equipo y para el Dueño del Producto. En vez de gestionar al equipo, el ScrumMaster trabaja para asistir tanto al equipo como al Dueño del Producto de la siguiente forma: | ||
+ | * Quitar las barreras entre el desarrollo y el dueño del producto, de manera que el dueño del producto pueda dirigir directamente el desarrollo. | ||
+ | * Enseñarle al dueño del producto cómo maximizar el retorno de inversión (ROI), y cumplir sus objetivos usando Scrum. | ||
+ | * Mejorar la vida del equipo de desarrollo, facilitando la creatividad y la toma de decisiones. | ||
+ | * Mejorar la productividad del equipo de desarrollo de cualquier forma posible. | ||
+ | * Mejorar las prácticas de desarrollo y herramientas para que cada incremento de funcionalidad sea potencialmente productiva. | ||
+ | * Mananter información actualizada y visible para todos sobre el progreso del equipo. | ||
+ | |||
+ | Fuente: Agile Project Management with Scrum, Ken Schwaber | ||
+ | |||
+ | ==== Sprint ==== | ||
+ | Una iteración de trabajo durante la cual se implementa un incremento de la funcionalidad del producto. Según el libro, una iteración dura 30 días. Esto es más largo que en otros métodos ágiles para tener en cuenta el hecho de que un incremento funcional del producto tiene que producirse en cada sprint. | ||
+ | |||
+ | El sprint comienza con una reunión de planificación del sprint de un día. Durante el Scrum ocurren muchas reuniones diarias de Scrum (una por día). Al final del sprint ocurre una reunión de demo del sprint, seguida de una reunión de retrospectiva del sprint. | ||
+ | |||
+ | Durante el sprint, el equipo no debe ser interrumpido con pedidos adicionales. Al garantizar que no se interrumpa al equipo permite hacer compromisos reales que se pueden cumplir. | ||
+ | |||
+ | En la práctica, algunos equipos eligen flexibilizar esta regla declarando que algunos miembros están un "80% disposnibles", dejando así tiempo para atender bugs de "máxima prioridad" y emergencias. Sin embargo, esto genera consecuencias no deseables y debe evitarse siempre que sea posible. | ||
+ | |||
+ | ==== Backlog del sprint ==== | ||
+ | Define el trabajo de un sprint, representado por un conjunto de tareas que deben completarse para cumplir los objetivos del sprint, y por un conjunto de elementos seleccionados del backlog del producto. | ||
+ | |||
+ | ==== Gráfico de burndown del sprint ==== | ||
+ | Un gráfico de burndown del sprint muestra el total de horas de tareas restantes por día. Esto nos muestra dónde está el equipo respecto a completar las tareas correspondientes a los elementos del backlog del producto que cumplen el objetivo del sprint. El eje X representa los días del sprint, el eje Y es el esfuerzo restante (usualmente en horas ideales). | ||
+ | |||
+ | Para motivar al equipo, el gráfico de burndown del sprint debe mostrarse abiertamente. También actuá como un radiador de información muy efectivo. La alternativa manual a esto es un tablero física, como una pizarra. | ||
+ | |||
+ | Idealmente el gráfico va descendiendo hasta el cero al final del sprint. Si los miembros del equipo informan de forma realista las horas restantes, la línea debería subir y bajar caóticamente. Esto demuestra porqué el concepto de "porcentaje de terminado" de la gestión tradicional no funciona. | ||
+ | |||
+ | ==== Objetivos del sprint ==== | ||
+ | Los objetivos del sprint son el resultado de la negociación entre el Dueño del producto y el equipo de desarrollo. | ||
+ | |||
+ | Los objetivos útiles son aquellos específicos y mediables. En vez de "mejorar la escalabilidad", debemos decir "manejar cinco veces más de usuarios que en la versión 0.8". | ||
+ | |||
+ | Scrum se enfoca en objetivos que resultan en un producto demostrable. El Dueño del Producto tiene el derecho a esperar un producto demostrable (sin importar qué tan pequeño sea) a partir del primer sprint. En el desarrollo iterativo, los sprints siguientes incrementarán la robustez y cantidad de las características. | ||
+ | |||
+ | El equipo tiene que comprometerse a objetivos que todos puedan ver si se cumplieron (o no) al final del sprint. En la reunión de demo, se demuestra el sprint y el equipo le pregunta al dueño del producto si siente que se cumplieron los objetivos. | ||
+ | |||
+ | Aunque algunos elementos del backlog del producto específicos pueden no estar terminados al final del sprint, debería ser un hecho muy inusual que el equipo no cumpla con el objetivo del sprint. Scrum requiere que se notifique cuanto antes al dueño del producto cuando se hace descubre que no podrán cumplirse los objetivos. | ||
+ | |||
+ | ==== Reunión de planificación del sprint ==== | ||
+ | La reunión de planificación del sprint es una negociación entre el equipo y el dueño del producto sobre lo que el equipo hará durante el siguiente sprint. | ||
+ | |||
+ | El dueño del producto y todos los miembros del equipo acuerdan un conjunto de objetivos para el sprint, el cual se usa para determinar los elementos del backlog del producto comprometidos. A menudo se definen nuevos elementos del backlog durante esta reunión. Esta parte de la reunión de planificación del sprint está acotada a 4 horas. | ||
+ | |||
+ | Usualmente el equipo deja libre al dueño del producto de la reunión, y comienza a descomponer los elementos del backlog en tareas. El dueño del producto sigue estando disponible en esta fase para renegociar o para responder preguntas que afecten las estimaciones. Esta parte de la reunión está acotada a 4 horas. Algunos equipos insertan tareas "recordatorias" (con estimaciones groseras) para los elementos del backlog del producto que no esperan comenzar hasta más tarde en el sprint. | ||
+ | |||
+ | ==== Reunión de retrospectiva del sprint ==== | ||
+ | La reunión de retrospectiva del sprint se realiza al final de cada sprint, después de la reunión de demo del sprint. El equipo y el ScrumMaster se juntan para discutir lo que salió bien y lo que necesita mejorarse en el próximo sprint. El dueño del producto no asiste a esta reunión. | ||
+ | |||
+ | La retrospectiva del sprint está acotdada a 3 horas. | ||
+ | |||
+ | Kelley Louie (Certified Scrum Practitioner) escribe: "La reunión de retrospectiva del sprint es una paret integral del proceso de inspección-y-adaptación. sino, el equipo nunca podrá mejorar su salida general y no podrá enfocarse en el rendimiento general del equipo. El ScrumMaster tiene que prestar atención a este reunión y trabajar en resolver los impedimentos que puedan estar retrasando al equipo". | ||
+ | |||
+ | ==== Tarea del sprint ==== | ||
+ | En Scrum, una tarea del sprint (o tarea) es una unidad de trabajo generalmente entre 4 y 16 horas. Los miembros del equipo se asignan voluntariamente las tareas. Actualizan la estimación de horas restantes de forma diaria, influenciando así el gráfico de burndown del sprint. Las tareas están contenidas dentro de elementos del backlog. | ||
+ | |||
+ | Scrum fomenta dividir una tarea en muchas si el estimado excede las 12 horas. | ||
+ | |||
+ | ==== Equipo ==== | ||
+ | El equipo (o "Equipo de Scrum") está compuesto idealmente de 7 más/menos dos personas. | ||
+ | |||
+ | Para los proyectos de desarrollo de software, los miembros del equipo suelen ser una mezcla de ingenieros de software, arquitectos, programadores, analistas, expertos de QA, testers, diseñadores de interfaz de usuario, etc. A menudo esto se llama "equipos de proyectos multi-disciplinarios". Las prácticas ágiles también fomentan a miembros del equipo multi-disciplinarios. | ||
+ | |||
+ | Durante un sprint, el equipo se auto-organiza para cumplir los objetivos del sprint. El equipo tiene autonomia para elegir cómo cumplir las metas, y es responsable por eso. El ScrumMaster actúa como guardían para asegurarse que el equipo esté protegido del dueño del producto. | ||
+ | |||
+ | Scrum también promueve ubicar al equipo completo en una misma habitación. | ||
+ | |||
+ | ==== Miembro del equipo ==== | ||
+ | Un miembro del equipo es cualquier persona que está trabajando en las tareas del sprint para cumplir el objetivo del sprint. | ||
+ | |||
+ | ==== Velocidad ==== | ||
+ | En Scrum, la velocidad es cuánto esfuerzo del backlog del producto el equipo puede manejar en un sprint. Esto puede estimarse viendo los sprint pasados, asumiendo que la composición del equipo y la duración del sprint se mantienen constante. También puede establecerse sprint-a-sprint, usando una planificación basada en compromisos. | ||
+ | |||
+ | Una vez establecida, la velocidad puede usarse para planificar proyectos y predecir entregas y fechas de terminación del producto. | ||
+ | |||
+ | ¿Cómo puede ser que el cálculo de la velocidad tenga sentido cuando los elementos del backlog son estimados de forma grosera? La regla de los números grandes tiende a promediar las imperfecciones de las estimaciones. | ||
[[Category: Scrum]] | [[Category: Scrum]] |
Revisión actual del 19:17 14 dic 2009
El siguiente glosario de términos de Scrum es una traducción de Glossary of Scrum terms, publicado en inglés por Victor Szalvay de la Scrum Alliance.
Contenido
- 1 Gráfico de Burndown
- 2 Reunión diaria de Scrum
- 3 Impedimentos
- 4 Backlog del producto
- 5 Elemento del backlog del producto
- 6 Esfuerzo para un elemento del backlog del producto
- 7 Gráfico de burndown del producto
- 8 Rol de Dueño del Producto
- 9 Entrega
- 10 Gráfico de burndown de la entrega
- 11 Roles de Scrum
- 12 Rol de ScrumMaster
- 13 Sprint
- 14 Backlog del sprint
- 15 Gráfico de burndown del sprint
- 16 Objetivos del sprint
- 17 Reunión de planificación del sprint
- 18 Reunión de retrospectiva del sprint
- 19 Tarea del sprint
- 20 Equipo
- 21 Miembro del equipo
- 22 Velocidad
Gráfico de Burndown
Los gráficos de Burndown muestran el trabajo restante en el tiempo. El trabajo restante es el eje Y y el tiempo es el eje X. El trabajo restante debería subir y bajar y eventualmente tener una tendencia descendente.
Los libros de Scrum definen un Gráfico de Burndown de Sprint como el lugar en donde ver el progreso diario, y un Gráfico de Burndown del Producto en donde ver el progreso mensual (por sprint).
Reunión diaria de Scrum
Una reunión diaria de 15 minutos en donde cada miembro del equipo responde 3 preguntas:
- ¿Qué hice desde la última reunión de Scrum? (por ejemplo, ayer)
- ¿Qué voy a hacer para la próxima reunión de Scrum? (por ejemplo, mañana)
- ¿Qué me impide realizar mi trabajo lo más eficientemente posible?
El ScrumMaster se asegura que los participantes organicen reuniones aparte para cualquier discusión que exceda a estas tres preguntas.
Los libros de Scrum recomiendan que esta reunión sea lo primero que ocurra a la mañana, ni bien lleguen todos los miembros del equipo.
Impedimentos
Un impedimento es cualquier cosa que le impida al equipo desempeñarse lo más eficientemente posible. Cada miembro del equip puede anunciar un impedimento durante la Reunión diaria de Scrum. El ScrumMaster está a cargo de resolver los impedimentos. Los ScrumMaster a menudo organizan reuniones paralelas cuando no se puede resolver un impedimento en la reunión diaria de Scrum.
Backlog del producto
El Backlog del Producto (o "backlog") contiene los requerimientos del sistema, expresados como una lista priorizada de elementos del backlog del producto. Esto incluye requerimientos del cliente funcionales y no-funcionales, y también requerimientos técnicos generados por el equipo. Aunque existen muchas entradas al backlog del producto, el Dueño del Producto es el único responsable por priorizar los elementos del backlog.
Durante la reunión de planificación del sprint, los elementos del backlog se mueven del backlog del producto hacia un sprint, basándose en las prioridades establecidas por el Dueño del Producto.
Elemento del backlog del producto
En Scrum, un elemento del backlog del producto ("PBI", "elemento del backlog", o "elemento") es una unidad de trabajo lo suficientemente pequeña para que el equipo pueda completarla en un sprint (iteración). Los elementos del backlog se descomponen en una o más tareas.
Ver también unidad de estimación de esfuerzo del backlog.
Esfuerzo para un elemento del backlog del producto
Algunas personas estiman es esfuerzo de los elementos del backlog del producto en días ideales, aunque otras personas prefieren unidades de estimación menos concretas. Las unidades alternativas pueden ser puentos de historia, puntos de función, o "tamaños de remera" (1 para pequeño, 2 para medio, etc.). La ventaja de estas unidades más vagas es que son explícitas en distinguir que el esfuerzo de los elementos del backlog del producto no son estimaciones de duración. También, las estimaciones a este nivel son aproximaciones burdas que nunca deben confundirse con horas de trabajo reales.
Nótese que las tareas del sprint son distintas de los elementos del backlog del sprint, y el esfuerzo restante de las tareas siempre se estima en horas.
Gráfico de burndown del producto
En Scrum, el gráfico de burndown del producto es una vista "general" del progreso del proyecto. Muestra cuánto trabajo restante hay al comienzo de cada sprint. El alcance de este gráfico abarca todas las entregas; sin embargo, un gráfico de burndown de entrega se limita a una única entrega.
Rol de Dueño del Producto
En Scrum, hay una única persona que tiene la autoridad final representando los intereses del cliente, priorizando el backlog y respondiendo preguntas sobre los requerimientos.
Esta persona debe estar disponible para el equipo en cualquier momento, especialmente durante la reunión de planificación del sprint y durante la reunión de demo del sprint.
Los desafíos de ser un Dueño del producto:
- Resistir la tentanción de "gestionar" al equipo. El equipo puede no organizarse de la forma esperada. Esto resulta especialmente dificil si algunos miembros del equipo piden la intervención sobre temas que el equipo debería resolver por si mismos.
- Resistir la tentación de agregar más trabajo importante después de iniciado un Sprint.
- Estar dispuesto a tomar decisiones difíciles durante la reunión de planificación del sprint.
- Balancear los intereses opuestos de interesados externos.
Entrega
Una entrega es la transición de un incremento potencialmente productivo del producto en algo que los clientes usen rutinariamente. Las entregas suelen ocurrir cuando uno o más sprints resultan en que el producto tiene suficiente valor como para superar el costo de desplegarlo.
"El producto se entrega al cliente o a las obligaciones del mercado. La entrega balancea funcionalidad, costo, y requerimientos de calidad contra la fecha comprometida". (Schwaber/Beedle, Agile Software Development with Scrum, p. 80).
Gráfico de burndown de la entrega
En Scrum, el gráfico de burndown de la entrega brinda una visión "general" sobre el progreso de la entrega. Muestra cuánto trabajo queda hacer al principio de cada sprint, para una única entrega. El alcance de este gráfico es una única entrega; sin embargo, un gráfico de burndown del producto abarca todas las entregas.
Roles de Scrum
Hay tres roles en cualquier proyecto de Scrum:
- Dueño del producto
- ScrumMaster
- Equipo
Rol de ScrumMaster
El ScrumMaster es una facilitador para el equipo y para el Dueño del Producto. En vez de gestionar al equipo, el ScrumMaster trabaja para asistir tanto al equipo como al Dueño del Producto de la siguiente forma:
- Quitar las barreras entre el desarrollo y el dueño del producto, de manera que el dueño del producto pueda dirigir directamente el desarrollo.
- Enseñarle al dueño del producto cómo maximizar el retorno de inversión (ROI), y cumplir sus objetivos usando Scrum.
- Mejorar la vida del equipo de desarrollo, facilitando la creatividad y la toma de decisiones.
- Mejorar la productividad del equipo de desarrollo de cualquier forma posible.
- Mejorar las prácticas de desarrollo y herramientas para que cada incremento de funcionalidad sea potencialmente productiva.
- Mananter información actualizada y visible para todos sobre el progreso del equipo.
Fuente: Agile Project Management with Scrum, Ken Schwaber
Sprint
Una iteración de trabajo durante la cual se implementa un incremento de la funcionalidad del producto. Según el libro, una iteración dura 30 días. Esto es más largo que en otros métodos ágiles para tener en cuenta el hecho de que un incremento funcional del producto tiene que producirse en cada sprint.
El sprint comienza con una reunión de planificación del sprint de un día. Durante el Scrum ocurren muchas reuniones diarias de Scrum (una por día). Al final del sprint ocurre una reunión de demo del sprint, seguida de una reunión de retrospectiva del sprint.
Durante el sprint, el equipo no debe ser interrumpido con pedidos adicionales. Al garantizar que no se interrumpa al equipo permite hacer compromisos reales que se pueden cumplir.
En la práctica, algunos equipos eligen flexibilizar esta regla declarando que algunos miembros están un "80% disposnibles", dejando así tiempo para atender bugs de "máxima prioridad" y emergencias. Sin embargo, esto genera consecuencias no deseables y debe evitarse siempre que sea posible.
Backlog del sprint
Define el trabajo de un sprint, representado por un conjunto de tareas que deben completarse para cumplir los objetivos del sprint, y por un conjunto de elementos seleccionados del backlog del producto.
Gráfico de burndown del sprint
Un gráfico de burndown del sprint muestra el total de horas de tareas restantes por día. Esto nos muestra dónde está el equipo respecto a completar las tareas correspondientes a los elementos del backlog del producto que cumplen el objetivo del sprint. El eje X representa los días del sprint, el eje Y es el esfuerzo restante (usualmente en horas ideales).
Para motivar al equipo, el gráfico de burndown del sprint debe mostrarse abiertamente. También actuá como un radiador de información muy efectivo. La alternativa manual a esto es un tablero física, como una pizarra.
Idealmente el gráfico va descendiendo hasta el cero al final del sprint. Si los miembros del equipo informan de forma realista las horas restantes, la línea debería subir y bajar caóticamente. Esto demuestra porqué el concepto de "porcentaje de terminado" de la gestión tradicional no funciona.
Objetivos del sprint
Los objetivos del sprint son el resultado de la negociación entre el Dueño del producto y el equipo de desarrollo.
Los objetivos útiles son aquellos específicos y mediables. En vez de "mejorar la escalabilidad", debemos decir "manejar cinco veces más de usuarios que en la versión 0.8".
Scrum se enfoca en objetivos que resultan en un producto demostrable. El Dueño del Producto tiene el derecho a esperar un producto demostrable (sin importar qué tan pequeño sea) a partir del primer sprint. En el desarrollo iterativo, los sprints siguientes incrementarán la robustez y cantidad de las características.
El equipo tiene que comprometerse a objetivos que todos puedan ver si se cumplieron (o no) al final del sprint. En la reunión de demo, se demuestra el sprint y el equipo le pregunta al dueño del producto si siente que se cumplieron los objetivos.
Aunque algunos elementos del backlog del producto específicos pueden no estar terminados al final del sprint, debería ser un hecho muy inusual que el equipo no cumpla con el objetivo del sprint. Scrum requiere que se notifique cuanto antes al dueño del producto cuando se hace descubre que no podrán cumplirse los objetivos.
Reunión de planificación del sprint
La reunión de planificación del sprint es una negociación entre el equipo y el dueño del producto sobre lo que el equipo hará durante el siguiente sprint.
El dueño del producto y todos los miembros del equipo acuerdan un conjunto de objetivos para el sprint, el cual se usa para determinar los elementos del backlog del producto comprometidos. A menudo se definen nuevos elementos del backlog durante esta reunión. Esta parte de la reunión de planificación del sprint está acotada a 4 horas.
Usualmente el equipo deja libre al dueño del producto de la reunión, y comienza a descomponer los elementos del backlog en tareas. El dueño del producto sigue estando disponible en esta fase para renegociar o para responder preguntas que afecten las estimaciones. Esta parte de la reunión está acotada a 4 horas. Algunos equipos insertan tareas "recordatorias" (con estimaciones groseras) para los elementos del backlog del producto que no esperan comenzar hasta más tarde en el sprint.
Reunión de retrospectiva del sprint
La reunión de retrospectiva del sprint se realiza al final de cada sprint, después de la reunión de demo del sprint. El equipo y el ScrumMaster se juntan para discutir lo que salió bien y lo que necesita mejorarse en el próximo sprint. El dueño del producto no asiste a esta reunión.
La retrospectiva del sprint está acotdada a 3 horas.
Kelley Louie (Certified Scrum Practitioner) escribe: "La reunión de retrospectiva del sprint es una paret integral del proceso de inspección-y-adaptación. sino, el equipo nunca podrá mejorar su salida general y no podrá enfocarse en el rendimiento general del equipo. El ScrumMaster tiene que prestar atención a este reunión y trabajar en resolver los impedimentos que puedan estar retrasando al equipo".
Tarea del sprint
En Scrum, una tarea del sprint (o tarea) es una unidad de trabajo generalmente entre 4 y 16 horas. Los miembros del equipo se asignan voluntariamente las tareas. Actualizan la estimación de horas restantes de forma diaria, influenciando así el gráfico de burndown del sprint. Las tareas están contenidas dentro de elementos del backlog.
Scrum fomenta dividir una tarea en muchas si el estimado excede las 12 horas.
Equipo
El equipo (o "Equipo de Scrum") está compuesto idealmente de 7 más/menos dos personas.
Para los proyectos de desarrollo de software, los miembros del equipo suelen ser una mezcla de ingenieros de software, arquitectos, programadores, analistas, expertos de QA, testers, diseñadores de interfaz de usuario, etc. A menudo esto se llama "equipos de proyectos multi-disciplinarios". Las prácticas ágiles también fomentan a miembros del equipo multi-disciplinarios.
Durante un sprint, el equipo se auto-organiza para cumplir los objetivos del sprint. El equipo tiene autonomia para elegir cómo cumplir las metas, y es responsable por eso. El ScrumMaster actúa como guardían para asegurarse que el equipo esté protegido del dueño del producto.
Scrum también promueve ubicar al equipo completo en una misma habitación.
Miembro del equipo
Un miembro del equipo es cualquier persona que está trabajando en las tareas del sprint para cumplir el objetivo del sprint.
Velocidad
En Scrum, la velocidad es cuánto esfuerzo del backlog del producto el equipo puede manejar en un sprint. Esto puede estimarse viendo los sprint pasados, asumiendo que la composición del equipo y la duración del sprint se mantienen constante. También puede establecerse sprint-a-sprint, usando una planificación basada en compromisos.
Una vez establecida, la velocidad puede usarse para planificar proyectos y predecir entregas y fechas de terminación del producto.
¿Cómo puede ser que el cálculo de la velocidad tenga sentido cuando los elementos del backlog son estimados de forma grosera? La regla de los números grandes tiende a promediar las imperfecciones de las estimaciones.