Ágil - Guía rápida

Ágil - Primer

Agile es una metodología de desarrollo de software para construir un software de manera incremental usando iteraciones cortas de 1 a 4 semanas para que el proceso de desarrollo esté alineado con las necesidades cambiantes del negocio. En lugar de un desarrollo de un solo paso de 6 a 18 meses donde todos los requisitos y riesgos se predicen por adelantado, Agile adopta un proceso de retroalimentación frecuente en el que se entrega un producto viable después de una iteración de 1 a 4 semanas.

Agile Vs SDLC tradicional

Roles en ágil

Scrum Master

Un Scrum Master es un líder de equipo y facilitador que ayuda a los miembros del equipo a seguir prácticas ágiles para que puedan cumplir con sus compromisos. Las responsabilidades de un scrum master son las siguientes:

  • Para permitir una estrecha cooperación entre todos los roles y funciones.

  • Para eliminar cualquier bloque.

  • Para proteger al equipo de cualquier perturbación.

  • Trabajar con la organización para seguir el progreso y los procesos de la empresa.

  • Para garantizar que los procesos Agile Inspect & Adapt se aprovechen correctamente, lo que incluye

    • Stand-ups diarios,
    • Reuniones planificadas,
    • Manifestación,
    • Revisión,
    • Reuniones retrospectivas, y
    • Para facilitar las reuniones del equipo y el proceso de toma de decisiones.

Dueño del producto

Un propietario del producto es el que conduce el producto desde la perspectiva empresarial. Las responsabilidades o el propietario del producto son las siguientes:

  • Definir los requisitos y priorizar sus valores.
  • Para determinar la fecha de lanzamiento y los contenidos.
  • Asumir un papel activo en la planificación de iteraciones y en las reuniones de planificación de lanzamiento.
  • Para garantizar que el equipo esté trabajando en el requisito más valioso.
  • Representar la voz del cliente.
  • Aceptar las historias de usuarios que cumplen con la definición de criterios de aceptación definidos y realizados.

Equipo multidisciplinar

Cada equipo ágil debe ser un equipo autosuficiente con 5 a 9 miembros y una experiencia promedio de 6 a 10 años. Por lo general, un equipo ágil consta de 3 a 4 desarrolladores, 1 probador, 1 líder técnico, 1 propietario del producto y 1 scrum master.

Equipo multidisciplinar

El propietario del producto y el Scrum Master se consideran parte de Team Interface, mientras que otros miembros son parte de Technical Interface.

¿Cómo un equipo ágil planifica su trabajo?

Un equipo ágil trabaja en iteraciones para entregar historias de usuarios donde cada iteración es de 10 a 15 días. Cada historia de usuario se planifica en función de su prioridad y tamaño de la cartera de pedidos. El equipo usa su capacidad (cuántas horas están disponibles con el equipo para trabajar en las tareas) para decidir cuánto alcance tienen que planificar.

Planificación

Punto

Un punto define cuánto puede comprometerse un equipo. Un punto generalmente se refiere a 8 horas. Cada historia se estima en puntos.

Capacidad

La capacidad define cuánto puede comprometerse un individuo. La capacidad se estima en horas.

¿Qué es una historia de usuario?

Una historia de usuario es un requisito que define lo que el usuario requiere como funcionalidad. Una historia de usuario puede tener dos formas:

  • Como <Rol de usuario> quiero <Funcionalidad> para que <Valor empresarial>
  • Para <Valor comercial> como <Rol de usuario> quiero <Funcionalidad>

Durante la planificación del lanzamiento, se proporciona una estimación aproximada de una historia de usuario utilizando la escala relativa como puntos. Durante la planificación de la iteración, la historia se divide en tareas.

Relación de historias de usuario y tareas

  • La historia del usuario habla sobre lo que se debe hacer. Define lo que un usuario necesita.
  • La tarea habla sobre cómo se debe hacer. Define cómo se implementará una funcionalidad.
  • Las historias son implementadas por tareas. Cada historia es una colección de tareas.
  • La historia del usuario se divide en tareas cuando se planifica en la iteración actual.
  • Las tareas se estiman en horas, generalmente de 2 a 12 horas.
  • Las historias se validan mediante pruebas de aceptación.
Relación de historias de usuario y tareas

Cuando se hace una historia

El equipo decide qué significa hacer . Los criterios pueden ser:

  • Todas las tareas (desarrollo, prueba) se completan.
  • Todas las pruebas de aceptación se están ejecutando y se pasan.
  • Ningún defecto está abierto.
  • El dueño del producto ha aceptado la historia.
  • Se puede entregar al usuario final.

¿Qué son los criterios de aceptación?

Los criterios definen la funcionalidad, el comportamiento y el rendimiento requeridos por una característica para que el propietario del producto pueda aceptarla. Define lo que se debe hacer para que el desarrollador sepa cuándo se completa una historia de usuario.

¿Cómo se definen los requisitos?

Los requisitos se definen como

  • Una historia de usuario
  • Con criterios de aceptación, y
  • Tareas para implementar la historia.

Ágil - Manifiesto

En febrero de 2001, en el complejo de Snowbird en Utah, 17 desarrolladores de software se reunieron para discutir métodos de desarrollo livianos. El resultado de su reunión fue el siguiente Manifiesto Ágil para el desarrollo de software:

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:

  • Individuos e interacciones sobre procesos y herramientas
  • Software de trabajo sobre documentación completa
  • Colaboración del cliente sobre la negociación del contrato
  • Responde al cambio sobre el siguiente plan

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Doce principios del manifiesto ágil

  • Satisfacción del cliente : se da la máxima prioridad para satisfacer los requisitos de los clientes mediante la entrega temprana y continua de software valioso.

  • Cambio de bienvenida : los cambios son inevitables durante el desarrollo de software. Los requisitos siempre cambiantes deberían ser bienvenidos, incluso al final de la fase de desarrollo. Los procesos ágiles deberían funcionar para aumentar la ventaja competitiva de los clientes.

  • Entregue un software que funcione: entregue un software que funcione con frecuencia, desde unas pocas semanas hasta algunos meses, considerando una escala de tiempo más corta.

  • Colaboración : la gente de negocios y los desarrolladores deben trabajar juntos durante toda la vida de un proyecto.

  • Motivación : los proyectos deben construirse alrededor de individuos motivados. Proporcione un entorno para apoyar a los miembros individuales del equipo y confíe en ellos para que se sientan responsables de hacer el trabajo.

  • Conversación cara a cara: la conversación cara a cara es el método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él.

  • Mida el progreso según el software de trabajo: el software de trabajo es la clave y debería ser la medida principal del progreso.

  • Mantener un ritmo constante : los procesos ágiles apuntan hacia el desarrollo sostenible. El negocio, los desarrolladores y los usuarios deberían poder mantener un ritmo constante con el proyecto.

  • Monitoreo : preste atención regular a la excelencia técnica y al buen diseño para mejorar la agilidad.

  • Simplicidad : mantenga las cosas simples y use términos simples para medir el trabajo que no se ha completado.

  • Equipos autoorganizados : un equipo ágil debe ser autoorganizado y no depender en gran medida de otros equipos porque las mejores arquitecturas, requisitos y diseños surgen de los equipos autoorganizados.

  • Revise el trabajo regularmente : revise el trabajo realizado a intervalos regulares para que el equipo pueda reflexionar sobre cómo ser más efectivo y ajustar su comportamiento en consecuencia.

Ágil - Características

Iterativo / incremental y listo para evolucionar

La mayoría de los métodos de desarrollo ágil dividen un problema en tareas más pequeñas. No existe una planificación directa a largo plazo para ningún requisito. Normalmente, se planifican iteraciones que varían de un corto período de tiempo, por ejemplo, de 1 a 4 semanas. Se crea un equipo interfuncional para cada iteración que funciona en todas las funciones de desarrollo de software, como planificación, análisis de requisitos, diseño, codificación, pruebas unitarias y pruebas de aceptación. El resultado al final de la iteración es un producto que funciona y se muestra a las partes interesadas al final de una iteración.

Después de la demostración, se toman los comentarios de revisión y se planea incorporarlos al software de trabajo según sea necesario.

Comunicación cara a cara

Cada equipo ágil debe tener un representante del cliente, como el propietario del producto, en la metodología scrum. Este representante está autorizado para actuar en nombre de las partes interesadas y puede responder las consultas de los desarrolladores entre iteraciones.

Un radiador de información (pantalla física) normalmente está ubicado de manera prominente en una oficina, donde los transeúntes pueden ver el progreso del equipo ágil. Este radiador de información muestra un resumen actualizado del estado de un proyecto.

Bucle de retroalimentación

El levantamiento diario es una cultura común de cualquier desarrollo ágil; También se conoce como scrum diario . Es una especie de breve sesión en la que cada miembro del equipo se informa entre sí sobre el estado de lo que han hecho, qué hacer a continuación y cualquier problema que enfrenten.

Ágil - Stand-up diario

El stand-up diario, como su nombre lo indica, es una reunión de estado diaria entre todos los miembros de un equipo ágil. No solo proporciona un foro para actualizaciones periódicas, sino que también enfoca los problemas de los miembros del equipo para que puedan abordarse rápidamente. El stand-up diario es una práctica obligada, sin importar cómo se establezca un equipo ágil, independientemente de la ubicación de su oficina.

¿Qué es el Stand-up diario?

  • Un stand-up diario es una reunión de estado diaria entre todos los miembros del equipo y se lleva a cabo aproximadamente durante 15 minutos.

  • Cada miembro tiene que responder tres preguntas importantes:

    • ¿Qué hice ayer?
    • ¿Qué haré hoy?
    • Cualquier impedimento que enfrento ... / Estoy bloqueado debido a ...
  • El stand-up diario es para actualizar el estado, no para ninguna discusión. Para la discusión, los miembros del equipo deben programar otra reunión en un momento diferente.

  • Los participantes generalmente se paran en lugar de sentarse para que la reunión termine rápidamente.

¿Por qué es importante ponerse de pie?

Los beneficios de tener un stand-up diario en ágil son los siguientes:

  • El equipo puede evaluar el progreso a diario y ver si pueden cumplir según el plan de iteración.
  • Cada miembro del equipo informa a todos sobre sus compromisos para el día.
  • Proporciona visibilidad al equipo ante cualquier retraso u obstáculo.

¿Quién asiste a un stand-up?

  • El scrum master, el propietario del producto y el equipo de entrega deben asistir al stand-up diariamente.

  • Se alienta a las partes interesadas y los clientes a asistir a la reunión y pueden actuar como observadores, pero no se supone que participen en combates.

  • Es responsabilidad del scrum master tomar nota de las consultas de cada miembro del equipo y los problemas que enfrentan.

Equipos dispersos geográficamente

Los stand-ups se pueden hacer de múltiples maneras, en caso de que los miembros del equipo ágil estén operando desde diferentes zonas horarias:

  • Seleccione un miembro de forma rotativa, que pueda asistir a la reunión de equipos de pie ubicados en diferentes zonas horarias.

  • Tenga un stand-up separado por equipo, actualice el estado del stand-up en una herramienta como Rally, SharePoint, Wikis, etc.

  • Tenga preparada una amplia variedad de herramientas de comunicación, como llamadas de conferencia, videoconferencia, mensajería instantánea o cualquier otra herramienta de intercambio de conocimientos de terceros.

Ágil - Definición de Hecho

La definición de hecho para User Story, Iteration y Release se da a continuación.

Historia del usuario

Una historia de usuario es un requisito que se formula en unas pocas oraciones en el lenguaje cotidiano de un usuario y debe completarse dentro de una iteración. Una historia de usuario se realiza cuando

  • Todo el código relacionado se ha registrado.
  • Todos los casos de prueba de unidad han sido aprobados.
  • Todos los casos de prueba de aceptación han sido aprobados.
  • El texto de ayuda está escrito.
  • El propietario del producto ha aceptado la historia.

Iteración

Una iteración es una colección en tiempo real de historias / defectos de usuario para trabajar y aceptar en el lanzamiento de un producto. Las iteraciones se definen durante la reunión de planificación de iteración y se completan con una demostración de iteración y una reunión de revisión. Una iteración también se denomina sprint . Se realiza una iteración cuando

  • La copia de seguridad del producto está completa.
  • El rendimiento ha sido probado.
  • Las historias de usuario se han aceptado o movido a la siguiente iteración.
  • Los defectos se han corregido o pospuesto a la siguiente iteración.

Lanzamiento

Un lanzamiento es un hito importante que representa una entrega interna o externa de la versión probada y funcional del producto / sistema. Se realiza un lanzamiento cuando

  • El sistema está sometido a prueba de esfuerzo.
  • El rendimiento está ajustado.
  • Se realizan validaciones de seguridad.
  • Se prueba el plan de recuperación ante desastres.

Ágil - Planificación de lanzamiento

El propósito de la planificación del lanzamiento es crear un plan para entregar un incremento al producto. Se realiza después de cada 2 a 3 meses.

Planeación de lanzamiento

¿Quien esta implicado?

  • Scrum Master : el scrum master actúa como facilitador para el equipo de entrega ágil.

  • Propietario del producto: el propietario del producto representa la vista general de la cartera de pedidos del producto.

  • Equipo ágil: el equipo de entrega ágil proporciona información sobre las posibilidades técnicas o cualquier dependencia.

  • Partes interesadas : las partes interesadas, como los clientes, los gerentes de programas, los expertos en la materia, actúan como asesores a medida que se toman decisiones en torno a la planificación del lanzamiento.

Prerrequisitos de planificación

Los requisitos previos de la planificación de lanzamiento son los siguientes:

  • Una cartera de productos clasificada, gestionada por el propietario del producto. En general, se toman de cinco a diez características que el propietario del producto considera que pueden incluirse en una versión

  • Aportaciones del equipo sobre capacidades, velocidad conocida o sobre cualquier desafío técnico.

  • Visión de alto nivel

  • Mercado y objetivo comercial

  • Reconocimiento de si se necesitan nuevos elementos de la cartera de productos

Materiales necesarios

La lista de materiales necesarios para la planificación del lanzamiento es la siguiente:

  • Agenda publicada, propósito
  • Rotafolios, pizarras, marcadores
  • Proyector, forma de compartir computadoras que requieren datos / herramientas necesarias durante la reunión de planificación
  • Datos de planificación

Datos de planificación

La lista de datos necesarios para planificar la publicación es la siguiente:

  • Iteraciones anteriores o resultados de planificación de lanzamiento
  • Comentarios de varias partes interesadas sobre el producto, las condiciones del mercado y los plazos
  • Planes de acción de versiones anteriores / iteraciones
  • Características o defectos a considerar
  • Velocidad de versiones anteriores / estimaciones.
  • Calendarios organizacionales y personales
  • Aportes de otros equipos y expertos en la materia para gestionar cualquier dependencia

Salida

El resultado de una planificación de lanzamiento puede ser el siguiente:

  • Plan de lanzamiento
  • Compromiso
  • Problemas, inquietudes, dependencias y suposiciones que se deben monitorear
  • Sugerencias para mejorar los planes de lanzamiento futuros

Agenda

La agenda de una planificación de liberación puede ser:

  • Ceremonia de apertura : mensaje de bienvenida, propósito de revisión y agenda, herramientas de organización e introducción a patrocinadores de negocios.

  • Visión del producto, hoja de ruta : muestra la imagen grande del producto.

  • Revise las versiones anteriores : debate sobre cualquier elemento que pueda afectar el plan.

  • Nombre / tema de la versión : inspeccione el estado actual de los temas de la hoja de ruta y realice los ajustes necesarios, si corresponde.

  • Velocidad : presente la velocidad de la versión actual y de versiones anteriores.

  • Programa de lanzamiento : revise los hitos clave y la decisión sobre los plazos para el lanzamiento y las iteraciones dentro del lanzamiento.

  • Problemas y preocupaciones : verifique cualquier problema o inquietud y regístrelos.

  • Revise y actualice la definición de Hecho : revise la definición de hecho y realice los cambios apropiados en función de la tecnología, la habilidad o los cambios en los miembros del equipo desde la última iteración / lanzamiento.

  • Historias y elementos a tener en cuenta : presente las historias y características de los usuarios de la cartera de productos que se considerarán para la programación en la versión actual.

  • Determine los valores de tamaño : si se desconoce la velocidad, planifique los valores de tamaño que se utilizarán en la planificación de la liberación.

  • El tamaño aproximado de las historias : el equipo de entrega determina el tamaño apropiado de las historias bajo consideración y las divide en varias iteraciones si una historia es demasiado grande. El propietario del producto y los expertos en la materia aclaran las dudas, elaboran los criterios de aceptación y hacen divisiones adecuadas de la historia. El scrum master facilita la colaboración.

  • Mapear historias a iteraciones : el equipo de entrega y el propietario del producto mueven las historias / defectos en las iteraciones según el tamaño y la velocidad. El scrum master facilita la colaboración.

  • Nuevas inquietudes o problemas : verifique cualquier problema nuevo basado en la experiencia previa y registre lo mismo.

  • Dependencias y suposiciones : compruebe las dependencias / suposiciones planificadas durante la planificación de la versión.

  • Comprometer : el scrum master solicita la planificación. El equipo de entrega y el propietario del producto lo señalan como el mejor plan y luego se comprometen a pasar al siguiente nivel de planificación, es decir, planificación de iteración.

  • Planificación de comunicación y logística : revise / actualice la planificación de comunicación y logística para el lanzamiento.

  • Estacionamiento : el estacionamiento de proceso significa que todos los elementos deben resolverse o establecerse como elementos de acción.

  • Distribuir elementos de acción y planes de acción : distribuya los elementos de acción entre sus propietarios, procese el plan de acción.

  • Retrospectiva : solicite comentarios de los participantes para que la reunión sea exitosa.

  • Cerrar : celebra el éxito.

Ágil - Planificación de iteraciones

El objetivo de la planificación de iteración es que el equipo complete el conjunto de elementos de la cartera de productos de primer nivel. Este compromiso tiene un límite de tiempo basado en la duración de la iteración y la velocidad del equipo.

Planificación de iteraciones

¿Quien esta implicado?

  • Scrum Master : el scrum master actúa como facilitador para el equipo de entrega ágil.

  • Propietario del producto: el propietario del producto se ocupa de la vista detallada de la cartera de productos y sus criterios de aceptación.

  • Equipo ágil: la entrega ágil define sus tareas y establece las estimaciones de esfuerzo necesarias para cumplir con el compromiso.

Prerrequisitos de planificación

  • Los elementos en la cartera de productos están dimensionados y tienen un punto de historia relativo asignado.
  • El propietario del producto ha asignado una clasificación a los elementos de la cartera.
  • Los criterios de aceptación se han establecido claramente para cada elemento de la cartera.

Proceso de planificación

Los siguientes son los pasos involucrados en la planificación de la iteración:

  • Determine cuántas historias pueden caber en una iteración.
  • Divide estas historias en tareas y asigna cada tarea a sus dueños.
  • Cada tarea recibe estimaciones en horas.
  • Estas estimaciones ayudan a los miembros del equipo a verificar cuántas horas de tarea tiene cada miembro para la iteración.
  • A los miembros del equipo se les asignan tareas considerando su velocidad o capacidad para que no se sobrecarguen.

Cálculo de velocidad

Un equipo ágil calcula la velocidad en base a iteraciones pasadas. La velocidad es un número promedio de unidades requeridas para terminar historias de usuarios en una iteración. Por ejemplo, si un equipo obtuvo 12, 14, 10 puntos de historia en cada iteración durante las últimas tres iteraciones, el equipo puede tomar 12 como velocidad para la siguiente iteración.

La velocidad planificada le dice al equipo cuántas historias de usuarios se pueden completar en la iteración actual. Si el equipo termina rápidamente las tareas asignadas, entonces se pueden obtener más historias de usuarios. De lo contrario, las historias también se pueden mover a la siguiente iteración.

Capacidad de tarea

La capacidad de un equipo se deriva de los siguientes tres hechos:

  • Número de horas de trabajo ideales en un día.
  • Días disponibles de persona en la iteración
  • Porcentaje de tiempo que un miembro está disponible exclusivamente para el equipo.

Supongamos que un equipo tiene 5 miembros, comprometidos a trabajar a tiempo completo (8 horas al día) en un proyecto y nadie está de permiso durante una iteración, entonces la capacidad de la tarea para una iteración de dos semanas será:

5 × 8 × 10 = 400 horas

Pasos de planificación

  • El propietario del producto describe el elemento mejor clasificado de la cartera de productos.
  • El equipo describe las tareas necesarias para completar el elemento.
  • Los miembros del equipo son dueños de las tareas.
  • Los miembros del equipo estiman el tiempo para terminar cada tarea.
  • Estos pasos se repiten para todos los elementos en la iteración.
  • Si un individuo está sobrecargado con tareas, entonces su tarea se distribuye entre otros miembros del equipo.

Agile: cartera de productos

Una cartera de productos es una lista de elementos a realizar. Los elementos se clasifican con descripciones de características. En un escenario ideal, los elementos deben desglosarse en historias de usuarios.

¿Por qué es importante la acumulación de productos?

  • Está preparado para que se puedan dar estimaciones a todas y cada una de las características.
  • Ayuda a planificar la hoja de ruta para el producto.
  • Ayuda a re-clasificar las características para que se pueda agregar más valor al producto.
  • Ayuda a determinar qué priorizar primero. El equipo clasifica el elemento y luego crea valor.

Características de la cartera de productos

  • Cada producto debe tener una cartera de productos que puede tener un conjunto de características grandes a muy grandes.

  • Varios equipos pueden trabajar en una sola cartera de productos.

  • La clasificación de características se realiza en función del valor comercial, el valor técnico, la gestión de riesgos o la adecuación estratégica.

  • Los elementos de mayor clasificación se descomponen en historias más pequeñas durante la planificación del lanzamiento para que puedan completarse en futuras iteraciones.

Ágil - Términos útiles

Criterios de aceptación

Son las condiciones establecidas por el propietario del producto o el cliente para aceptar que una función sea válida y cumpla con sus requisitos.

Preparación de pedidos pendientes

Es un proceso continuo en el que el gerente de producto o el cliente administran el trabajo atrasado del producto al recibir comentarios de equipos ágiles. Este proceso implica priorizar los elementos de la cartera, dividirlos en elementos más pequeños, planificarlos para futuras iteraciones, crear nuevas historias, actualizar los criterios de aceptación o elaborar criterios de aceptación en detalles.

Capacidad

Es la cantidad de trabajo que un equipo puede tomar para completar en una iteración.

Característica

Una mejora realizada a un producto o capacidad de valor para las partes interesadas que se puede desarrollar en un lanzamiento.

Iteración

Un elemento de trabajo basado en un tema que puede completarse dentro de un cuadro de tiempo y aceptarse dentro del lanzamiento de un producto. El trabajo de iteración se define durante la planificación de la iteración y termina con una reunión de demostración y revisión. También se denomina Sprint.

Incremento

Un incremento es el estado cambiante de un producto a medida que se desarrolla gradualmente. Normalmente está representado por hitos o número de iteraciones fijas.

Dueño del producto

El propietario del producto es miembro del equipo de entrega ágil, responsable de recopilar y clasificar los requisitos comerciales en la cartera de productos. El propietario de un producto comunica lo que se debe hacer en una versión / iteración. Él / ella establece los compromisos y es responsable de proteger al equipo de cualquier cambio en los requisitos durante una iteración.

Pila de Producto

Conjunto de requisitos de productos funcionales y no funcionales.

Elementos de la cartera de productos

Pueden ser historias de usuarios, defectos, características que serán desarrolladas por el equipo ágil.

Puntos

Una unidad común utilizada para establecer el tamaño relativo de historias de usuarios, características o cualquier otro elemento de cartera.

Lanzamiento

Un cronograma donde se trabaja para respaldar la entrega de incrementos comprobables a un software. En scrum, una versión consta de múltiples iteraciones.

Requisito

Una especificación de un producto de software para satisfacer un contrato o funcionalidad establecidos. Las historias de usuario y los elementos de la cartera son tipos de requisitos.

Puntos de historia

Una unidad utilizada por el equipo ágil para estimar los tamaños relativos de las historias y características de los usuarios.

pique

Igual que la iteración.

Caja de tiempo

Una duración de tiempo fija en la que se desarrollará un producto entregable. Normalmente, junto con la fijación de la fecha de inicio y finalización de un timebox, también se fija el número de recursos.

Tarea

Es una unidad de trabajo que contribuye a completar una historia de usuario dentro de una iteración. Las historias de los usuarios se descomponen en múltiples tareas y cada tarea se puede dividir entre los miembros del equipo que los marcan como propietarios de las tareas. Los miembros del equipo pueden asumir la responsabilidad de cada tarea, actualizar las estimaciones, registrar el trabajo realizado o las tareas pendientes según lo deseado.

Historia del usuario

Un criterio de aceptación enumerado para cumplir ciertos requisitos de un usuario. Normalmente se escribe desde la perspectiva de un usuario final.

Velocidad

Una medida para ponderar el trabajo aceptado en una iteración o timebox. Normalmente es la suma de puntos de historia aceptados en una iteración.