Agile - Guide rapide

Agile - Primer

Agile est une méthodologie de développement logiciel pour construire un logiciel de manière incrémentielle en utilisant de courtes itérations de 1 à 4 semaines afin que le processus de développement soit aligné avec les besoins changeants de l'entreprise. Au lieu d'un développement en un seul passage de 6 à 18 mois où toutes les exigences et les risques sont prédits à l'avance, Agile adopte un processus de rétroaction fréquente où un produit réalisable est livré après 1 à 4 semaines d'itération.

SDLC Agile vs traditionnel

Rôles dans Agile

Scrum Master

Un Scrum Master est un chef d'équipe et un facilitateur qui aide les membres de l'équipe à suivre des pratiques agiles afin qu'ils puissent respecter leurs engagements. Les responsabilités d'un Scrum Master sont les suivantes -

  • Pour permettre une coopération étroite entre tous les rôles et fonctions.

  • Pour supprimer tous les blocs.

  • Pour protéger l'équipe de toute perturbation.

  • Travailler avec l'organisation pour suivre les progrès et les processus de l'entreprise.

  • Pour garantir que les processus Agile Inspect & Adapt sont exploités correctement, ce qui comprend

    • Stand-up quotidiens,
    • Réunions prévues,
    • Démo,
    • La revue,
    • Réunions rétrospectives, et
    • Faciliter les réunions d'équipe et le processus de prise de décision.

Propriétaire du produit

Un Product Owner est celui qui conduit le produit du point de vue commercial. Les responsabilités ou le propriétaire d'un produit sont les suivants -

  • Définir les exigences et hiérarchiser leurs valeurs.
  • Pour déterminer la date de sortie et le contenu.
  • Pour jouer un rôle actif dans la planification des itérations et des réunions de planification des versions.
  • S'assurer que l'équipe travaille sur l'exigence la plus valorisée.
  • Représenter la voix du client.
  • Accepter les user stories qui répondent à la définition du fait et aux critères d'acceptation définis.

Équipe interfonctionnelle

Chaque équipe agile doit être une équipe autonome avec 5 à 9 membres et une expérience moyenne variant de 6 à 10 ans. En règle générale, une équipe agile comprend de 3 à 4 développeurs, 1 testeur, 1 responsable technique, 1 propriétaire de produit et 1 scrum master.

Équipe interfonctionnelle

Le Product Owner et Scrum master sont considérés comme faisant partie de Team Interface, tandis que les autres membres font partie de Technical Interface.

Comment une équipe agile planifie son travail?

Une équipe Agile travaille par itérations pour fournir des user stories où chaque itération dure de 10 à 15 jours. Chaque user story est planifiée en fonction de la priorité et de la taille de son backlog. L'équipe utilise sa capacité - combien d'heures sont disponibles avec l'équipe pour travailler sur des tâches - pour décider de l'étendue qu'elle doit planifier.

Planification

Point

Un point définit combien une équipe peut s'engager. Un point fait généralement référence à 8 heures. Chaque histoire est estimée en points.

Capacité

La capacité définit combien un individu peut s'engager. La capacité est estimée en heures.

Qu'est-ce qu'une User Story?

Une user story est une exigence qui définit ce qui est requis par l'utilisateur en tant que fonctionnalité. Une user story peut prendre deux formes:

  • En tant que <Rôle utilisateur>, je veux <Fonctionnalité> pour que <Valeur commerciale>
  • Afin de <Valeur commerciale> en tant que <Rôle utilisateur>, je veux <Fonctionnalité>

Lors de la planification des versions, une estimation approximative est donnée à une user story en utilisant l'échelle relative comme points. Lors de la planification des itérations, l'histoire est décomposée en tâches.

Relation entre les histoires d'utilisateurs et les tâches

  • L'histoire de l'utilisateur parle de ce qui doit être fait. Il définit ce dont un utilisateur a besoin.
  • La tâche explique comment cela doit être fait. Il définit comment une fonctionnalité doit être implémentée.
  • Les histoires sont implémentées par tâches. Chaque histoire est une collection de tâches.
  • La user story est divisée en tâches lorsqu'elle est planifiée dans l'itération en cours.
  • Les tâches sont estimées en heures, généralement de 2 à 12 heures.
  • Les histoires sont validées à l'aide de tests d'acceptation.
Relation entre les histoires d'utilisateurs et les tâches

Quand une histoire est finie

L'équipe décide de ce qui est fait . Les critères peuvent être -

  • Toutes les tâches (développement, tests) sont terminées.
  • Tous les tests d'acceptation sont en cours et réussis.
  • Aucun défaut n'est ouvert.
  • Le propriétaire du produit a accepté l'histoire.
  • Livrable à l'utilisateur final.

Qu'est-ce que les critères d'acceptation?

Les critères définissent la fonctionnalité, le comportement et les performances requis par une fonctionnalité afin qu'elle puisse être acceptée par le propriétaire du produit. Il définit ce qui doit être fait pour que le développeur sache quand une user story est terminée.

Comment les exigences sont-elles définies?

Les exigences sont définies comme

  • Une histoire d'utilisateur,
  • Avec des critères d'acceptation, et
  • Tâches pour mettre en œuvre l'histoire.

Agile - Manifeste

En février 2001, à la station Snowbird dans l'Utah, 17 développeurs de logiciels se sont rencontrés pour discuter des méthodes de développement léger. Le résultat de leur réunion a été le Manifeste Agile suivant pour le développement de logiciels -

Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons pris de la valeur -

  • Individus et interactions sur les processus et les outils
  • Logiciel fonctionnel sur une documentation complète
  • Collaboration client sur négociation de contrat
  • Répondre au changement au sujet d'un plan

Autrement dit, bien qu'il y ait de la valeur dans les éléments de droite, nous valorisons davantage les éléments de gauche.

Douze principes du Manifeste Agile

  • Satisfaction du client - La plus haute priorité est accordée à la satisfaction des exigences des clients grâce à la livraison précoce et continue de logiciels précieux.

  • Changement de bienvenue - Les changements sont inévitables pendant le développement du logiciel. Les exigences en constante évolution devraient être les bienvenues, même tard dans la phase de développement. Les processus agiles devraient travailler pour augmenter l'avantage concurrentiel des clients.

  • Livrer un logiciel de travail - Livrez un logiciel de travail fréquemment, allant de quelques semaines à quelques mois, compte tenu de délais plus courts.

  • Collaboration - Les gens d'affaires et les développeurs doivent travailler ensemble pendant toute la durée de vie d'un projet.

  • Motivation - Les projets doivent être construits autour d'individus motivés. Fournissez un environnement pour soutenir les membres individuels de l'équipe et leur faire confiance afin qu'ils se sentent responsables de faire le travail.

  • Conversation en face à face - La conversation en face à face est la méthode la plus efficace pour transmettre des informations à et au sein d'une équipe de développement.

  • Mesurer la progression selon le logiciel de travail - Le logiciel de travail est la clé et devrait être la principale mesure de progrès.

  • Maintenir un rythme constant - Les processus agiles visent le développement durable. L'entreprise, les développeurs et les utilisateurs devraient pouvoir maintenir un rythme constant avec le projet.

  • Surveillance - Portez une attention régulière à l'excellence technique et à une bonne conception pour améliorer l'agilité.

  • Simplicité - Gardez les choses simples et utilisez des termes simples pour mesurer le travail qui n'est pas terminé.

  • Équipes auto-organisées - Une équipe agile doit être auto-organisée et ne doit pas dépendre fortement des autres équipes car les meilleures architectures, exigences et conceptions émergent des équipes auto-organisées.

  • Passez en revue le travail régulièrement - Passez en revue le travail effectué à intervalles réguliers afin que l'équipe puisse réfléchir à la façon de devenir plus efficace et d'ajuster son comportement en conséquence.

Agile - Caractéristiques

Itératif / incrémental et prêt à évoluer

La plupart des méthodes de développement agiles décomposent un problème en tâches plus petites. Il n'y a pas de planification directe à long terme pour toute exigence. Normalement, des itérations sont prévues qui varient sur une courte période de temps, par exemple, 1 à 4 semaines. Une équipe interfonctionnelle est créée pour chaque itération qui fonctionne dans toutes les fonctions de développement de logiciels comme la planification, l'analyse des exigences, la conception, le codage, les tests unitaires et les tests d'acceptation. Le résultat à la fin de l'itération est un produit de travail et il est démontré aux parties prenantes à la fin d'une itération.

Après la démonstration, les commentaires de révision sont pris et devraient être incorporés au logiciel de travail selon les besoins.

Communication face à face

Chaque équipe agile doit avoir un représentant client tel qu'un propriétaire de produit dans la méthodologie Scrum. Ce représentant est autorisé à agir au nom des parties prenantes et il peut répondre aux requêtes des développeurs entre les itérations.

Un radiateur d'information (affichage physique) est normalement placé bien en vue dans un bureau, où les passants peuvent voir les progrès de l'équipe agile. Ce radiateur d'information présente un résumé à jour de l'état d'un projet.

Boucle de rétroaction

Le stand-up quotidien est une culture courante de tout développement agile; il est également connu sous le nom de mêlée quotidienne . C'est une sorte de brève session où chaque membre de l'équipe se fait un rapport sur l'état d'avancement de ce qu'il a fait, que faire ensuite et sur les problèmes auxquels il est confronté.

Agile - Stand-up quotidien

Le stand-up quotidien, comme son nom l'indique, est une réunion de mise à jour quotidienne entre tous les membres d'une équipe agile. Il fournit non seulement un forum pour les mises à jour régulières, mais met également l'accent sur les problèmes des membres de l'équipe afin qu'il puisse être rapidement résolu. Le stand-up quotidien est une pratique incontournable, quelle que soit la manière dont une équipe agile est établie quel que soit l'emplacement de son bureau.

Qu'est-ce que le stand-up quotidien?

  • Un stand-up quotidien est une réunion de statut quotidienne entre tous les membres de l'équipe et il se déroule en gros pendant 15 minutes.

  • Chaque membre doit répondre à trois questions importantes -

    • Ce que j'ai fait hier?
    • Que vais-je faire aujourd'hui?
    • Tout obstacle auquel je fais face ... / Je suis bloqué en raison de ...
  • Le stand-up quotidien est pour la mise à jour du statut, pas pour toute discussion. Pour la discussion, les membres de l'équipe doivent planifier une autre réunion à une heure différente.

  • Les participants se lèvent généralement au lieu de s'asseoir pour que la réunion se termine rapidement.

Pourquoi le stand-up est important?

Les avantages d'avoir un stand-up quotidien en agile sont les suivants -

  • L'équipe peut évaluer les progrès sur une base quotidienne et voir si elles peuvent livrer selon le plan d'itération.
  • Chaque membre de l'équipe informe tout sur ses engagements pour la journée.
  • Il offre une visibilité à l'équipe sur tout retard ou obstacle.

Qui assiste à un stand-up?

  • Le maître de mêlée, le propriétaire du produit et l'équipe de livraison doivent assister quotidiennement au stand-up.

  • Les parties prenantes et les clients sont encouragés à assister à la réunion et ils peuvent agir en tant qu'observateurs, mais ils ne sont pas censés participer aux stand-up.

  • Il est de la responsabilité du Scrum Master de prendre note des requêtes de chaque membre de l'équipe et des problèmes auxquels ils sont confrontés.

Équipes géographiquement dispersées

Les stand-ups peuvent être effectués de plusieurs manières, au cas où les membres de l'équipe agiles opèrent à partir de différents fuseaux horaires -

  • Sélectionnez un membre par rotation, qui peut assister à la réunion debout d'équipes situées dans différents fuseaux horaires.

  • Avoir un stand-up séparé par équipe, mettre à jour le statut du stand-up dans un outil tel que Rally, SharePoint, Wikis, etc.

  • Ayez à disposition une grande variété d'outils de communication comme les conférences téléphoniques, les vidéoconférences, les messageries instantanées ou tout autre outil de partage de connaissances tiers.

Agile - Définition de Terminé

La définition de done pour User Story, Iteration et Release est donnée ci-dessous.

Histoire de l'utilisateur

Une user story est une exigence formulée en quelques phrases dans le langage courant d'un utilisateur et qui doit être complétée dans une itération. Une user story est réalisée lorsque

  • Tous les codes associés ont été enregistrés.
  • Tous les cas de tests unitaires ont été réussis.
  • Tous les cas de test d'acceptation ont été réussis.
  • Le texte d'aide est écrit.
  • Le propriétaire du produit a accepté l'histoire.

Itération

Une itération est une collection chronologique d'histoires utilisateur / défauts à traiter et à accepter dans la version d'un produit. Les itérations sont définies lors de la réunion de planification des itérations et complétées par une démonstration de l'itération et une réunion de révision. Une itération est également appelée sprint . Une itération est effectuée lorsque

  • La sauvegarde du produit est terminée.
  • Les performances ont été testées.
  • Les user stories ont été acceptées ou déplacées vers la prochaine itération.
  • Les défauts ont été corrigés ou reportés à la prochaine itération.

Libération

Une version est un jalon majeur qui représente une livraison interne ou externe d'une version fonctionnelle et testée du produit / système. Une libération est effectuée lorsque

  • Le système est testé sous contrainte.
  • La performance est réglée.
  • Des validations de sécurité sont effectuées.
  • Le plan de reprise après sinistre est testé.

Agile - Planification des versions

Le but de la planification des versions est de créer un plan pour fournir un incrément au produit. Elle se fait tous les 2 à 3 mois.

Planification des versions

Qui est impliqué?

  • Scrum Master - Le Scrum Master agit comme un facilitateur pour l'équipe de livraison agile.

  • Product Owner - Le Product Owner représente la vue générale du backlog de produit.

  • Équipe Agile - L'équipe de livraison Agile fournit des informations sur les possibilités techniques ou les dépendances.

  • Parties prenantes - Les parties prenantes telles que les clients, les gestionnaires de programme, les experts en la matière agissent en tant que conseillers lors de la prise de décisions concernant la planification de la publication.

Conditions préalables à la planification

Les conditions préalables à la planification des versions sont les suivantes -

  • Un backlog produit classé, géré par le Product Owner. Généralement, cinq à dix fonctionnalités sont prises, ce que le propriétaire du produit estime pouvoir inclure dans une version.

  • Contribution de l'équipe sur les capacités, la vitesse connue ou tout défi technique

  • Vision de haut niveau

  • Objectif de marché et d'affaires

  • Reconnaissance de la nécessité de nouveaux éléments de backlog de produits

Matériaux nécessaires

La liste des documents requis pour la planification des versions est la suivante -

  • Ordre du jour affiché, objectif
  • Tableaux à feuilles mobiles, tableaux blancs, marqueurs
  • Projecteur, moyen de partager des ordinateurs ayant des données / outils nécessaires lors de la réunion de planification
  • Données de planification

Données de planification

La liste des données requises pour effectuer la planification des versions est la suivante -

  • Itérations précédentes ou résultats de la planification des versions
  • Commentaires de diverses parties prenantes sur le produit, les conditions du marché et les délais
  • Plans d'action des versions / itérations précédentes
  • Caractéristiques ou défauts à considérer
  • Vitesse des versions / estimations précédentes.
  • Calendriers organisationnels et personnels
  • Contributions d'autres équipes et d'experts en la matière pour gérer toutes les dépendances

Production

Le résultat d'une planification de version peut être le suivant -

  • Plan de sortie
  • Engagement
  • Problèmes, préoccupations, dépendances et hypothèses à surveiller
  • Suggestions pour améliorer les planifications de versions futures

Ordre du jour

L'ordre du jour d'une planification de libération peut être -

  • Cérémonie d'ouverture - Message de bienvenue, objectif de l'examen et ordre du jour, outils d'organisation et présentation aux sponsors commerciaux.

  • Vision du produit, feuille de route - Affichez la vue d'ensemble du produit.

  • Revoir les versions précédentes - Discussion sur tout élément pouvant avoir un impact sur le plan.

  • Nom / thème de la version - Inspectez l'état actuel des thèmes de la feuille de route et effectuez les ajustements requis, le cas échéant.

  • Velocity - Présente la vélocité de la version actuelle et des versions précédentes.

  • Calendrier de publication - Passez en revue les étapes clés et la décision sur les délais de publication et les itérations dans la version.

  • Problèmes et préoccupations - Vérifiez toutes les préoccupations ou problèmes et enregistrez-les.

  • Revoir et mettre à jour la définition de Terminé - Revoir la définition de Terminé et apporter les changements appropriés en fonction de la technologie, des compétences ou des changements dans les membres de l'équipe depuis la dernière itération / version.

  • Histoires et éléments à prendre en compte - Présentez les histoires d'utilisateurs et les fonctionnalités du backlog de produit à prendre en compte pour la planification dans la version actuelle.

  • Déterminer les valeurs de dimensionnement - Si la vitesse est inconnue, planifier les valeurs de dimensionnement à utiliser dans la planification de la version.

  • Grossesse de la taille des histoires - L'équipe de livraison détermine la taille appropriée des histoires à l'étude et divise les histoires en plusieurs itérations si une histoire est trop grande. Le propriétaire du produit et les experts en la matière clarifient les doutes, élaborent les critères d'acceptation et effectuent les fractionnements appropriés de l'histoire. Le Scrum Master facilite la collaboration.

  • Mapper les histoires aux itérations - L'équipe de livraison et le propriétaire du produit déplacent les histoires / défauts dans les itérations en fonction de la taille et de la vitesse. Le Scrum Master facilite la collaboration.

  • Nouvelles préoccupations ou problèmes - Vérifiez tous les nouveaux problèmes en fonction de votre expérience antérieure et enregistrez-les.

  • Dépendances et hypothèses - Vérifiez toutes les dépendances / hypothèses prévues lors de la planification de la version.

  • Commit - Le Scrum Master appelle à la planification. L'équipe de livraison et le propriétaire du produit le signalent comme le meilleur plan, puis s'engagent à passer au prochain niveau de planification, à savoir la planification des itérations.

  • Planification de la communication et de la logistique - Examiner / mettre à jour la planification de la communication et de la logistique pour la publication.

  • Parking - Le traitement du parking signifie que tous les éléments doivent être résolus ou définis comme éléments d'action.

  • Distribuer les éléments d'action et les plans d'action - Répartissez les éléments d'action entre leurs propriétaires, traitez le plan d'action.

  • Rétrospective - Sollicitez les commentaires des participants pour assurer le succès de la réunion.

  • Fermer - Célébrez le succès.

Agile - Planification des itérations

L'objectif de la planification des itérations est que l'équipe complète l'ensemble des éléments de backlog de produit les mieux classés. Cet engagement est encadré en fonction de la durée de l'itération et de la vitesse de l'équipe.

Planification des itérations

Qui est impliqué?

  • Scrum Master - Le Scrum Master agit comme un facilitateur pour l'équipe de livraison agile.

  • Product Owner - Le Product Owner traite de la vue détaillée du backlog du produit et de ses critères d'acceptation.

  • Équipe Agile - La livraison Agile définit leurs tâches et définit les estimations d'effort requises pour remplir l'engagement.

Conditions préalables à la planification

  • Les éléments du carnet de produits sont dimensionnés et un point d'histoire relatif est affecté.
  • Le classement a été attribué aux éléments du portefeuille par le propriétaire du produit.
  • Les critères d'acceptation ont été clairement énoncés pour chaque élément du portefeuille.

Processus de planification

Voici les étapes de la planification des itérations -

  • Déterminez combien d'histoires peuvent tenir dans une itération.
  • Divisez ces histoires en tâches et attribuez chaque tâche à leurs propriétaires.
  • Chaque tâche reçoit des estimations en heures.
  • Ces estimations aident les membres de l'équipe à vérifier le nombre d'heures de tâche dont chaque membre dispose pour l'itération.
  • Les membres de l'équipe se voient attribuer des tâches en fonction de leur vitesse ou de leur capacité afin de ne pas être surchargés.

Calcul de vitesse

Une équipe agile calcule la vitesse en fonction des itérations passées. La vélocité est le nombre moyen d'unités requises pour terminer les user stories dans une itération. Par exemple, si une équipe a pris 12, 14, 10 points d'histoire à chaque itération pour les trois dernières itérations, l'équipe peut prendre 12 comme vitesse pour l'itération suivante.

La vitesse planifiée indique à l'équipe combien d'histoires utilisateur peuvent être terminées dans l'itération en cours. Si l'équipe termine rapidement les tâches assignées, alors plus de user stories peuvent être récupérées. Sinon, les stories peuvent être déplacées aussi vers la prochaine itération.

Capacité de tâche

La capacité d'une équipe découle des trois faits suivants:

  • Nombre d'heures de travail idéales dans une journée
  • Jours de personne disponibles dans l'itération
  • Pourcentage de temps pendant lequel un membre est exclusivement disponible pour l'équipe.

Supposons qu'une équipe compte 5 membres, engagés à travailler à plein temps (8 heures par jour) sur un projet et que personne ne soit en congé pendant une itération, alors la capacité de tâche pour une itération de deux semaines sera -

5 × 8 × 10 = 400 heures

Étapes de planification

  • Le Product Owner décrit l'élément de backlog de produit le mieux classé.
  • L'équipe décrit les tâches requises pour terminer l'élément.
  • Les membres de l'équipe sont propriétaires des tâches.
  • Les membres de l'équipe estiment le temps nécessaire pour terminer chaque tâche.
  • Ces étapes sont répétées pour tous les éléments de l'itération.
  • Si une personne est surchargée de tâches, sa tâche est répartie entre les autres membres de l'équipe.

Agile - Backlog produit

Un backlog de produit est une liste d'éléments à effectuer. Les articles sont classés avec des descriptions de fonctionnalités. Dans un scénario idéal, les éléments devraient être décomposés en user stories.

Pourquoi l'arriéré de produits est important?

  • Il est préparé afin que des estimations puissent être données pour chaque élément.
  • Il aide à planifier la feuille de route du produit.
  • Il aide à re-classer les fonctionnalités afin que plus de valeur puisse être ajoutée au produit.
  • Il aide à déterminer ce qui doit être priorisé en premier. L'équipe classe l'élément, puis crée de la valeur.

Caractéristiques du backlog produit

  • Chaque produit doit avoir un backlog de produit qui peut avoir un ensemble de fonctionnalités grandes à très grandes.

  • Plusieurs équipes peuvent travailler sur un seul backlog de produit.

  • Le classement des fonctionnalités est effectué en fonction de la valeur commerciale, de la valeur technique, de la gestion des risques ou de l'aptitude stratégique.

  • Les éléments les mieux classés sont décomposés en histoires plus petites lors de la planification de la version afin de pouvoir être complétés dans les futures itérations.

Agile - Termes utiles

Critères d'acceptation

Ce sont les conditions fixées par le propriétaire du produit ou le client afin d'accepter qu'une fonctionnalité soit valide et conforme à ses exigences.

Toilettage de l'arriéré

Il s'agit d'un processus continu dans lequel le chef de produit ou le client gère le backlog de produit en obtenant les commentaires des équipes agiles. Ce processus implique de hiérarchiser les éléments du portefeuille, de les diviser en éléments plus petits, de les planifier pour de futures itérations, de créer de nouvelles histoires, de mettre à jour les critères d'acceptation ou d'élaborer des critères d'acceptation en détail.

Capacité

C'est la quantité de travail qu'une équipe peut prendre pour terminer en une seule itération.

Fonctionnalité

Une amélioration apportée à un produit ou une capacité de valeur pour les parties prenantes qui peut être développée dans une version.

Itération

Un élément de travail basé sur un thème qui peut être terminé dans un délai et accepté dans la version d'un produit. Le travail d'itération est défini lors de la planification des itérations et se termine par une réunion de démonstration et de révision. Il est également appelé Sprint.

Incrément

Un incrément est l'état changeant d'un produit au fur et à mesure de son développement progressif. Il est normalement représenté par des jalons ou un nombre d'itérations fixes.

Propriétaire du produit

Le propriétaire du produit est un membre de l'équipe de livraison Agile, chargé de collecter et de classer les exigences commerciales dans le carnet de produit. Un propriétaire de produit communique ce qui doit être fait dans une version / itération. Il / elle fixe les engagements et est responsable de protéger l'équipe de tout changement des besoins lors d'une itération.

Carnet de produit

Ensemble d'exigences fonctionnelles et non fonctionnelles du produit.

Éléments du carnet de produit

Il peut s'agir de user stories, de défauts, de fonctionnalités à développer par l'équipe agile.

Points

Unité commune utilisée pour définir la taille relative des user stories, des fonctionnalités ou de tout autre élément de portefeuille.

Libération

Une boîte de temps où le travail est effectué pour soutenir la livraison de l'incrément testable à un logiciel. Dans Scrum, une version se compose de plusieurs itérations.

Exigence

Une spécification d'un produit logiciel pour satisfaire un contrat ou une fonctionnalité déclaré. Les user stories et les éléments de portfolio sont des types d'exigences.

Points d'histoire

Une unité utilisée par l'équipe agile pour estimer la taille relative des user stories et des fonctionnalités.

Sprint

Identique à l'itération.

Timebox

Une durée fixe dans laquelle un livrable doit être développé. Normalement, en plus de fixer la date de début et de fin d'une boîte de temps, le nombre de ressources est également fixé.

Tâche

Il s'agit d'une unité de travail qui contribue à l'achèvement d'une user story au sein d'une itération. Les user stories sont décomposées en plusieurs tâches et chaque tâche peut être divisée entre les membres de l'équipe en les marquant comme propriétaire des tâches. Les membres de l'équipe peuvent prendre la responsabilité de chaque tâche, mettre à jour les estimations, consigner le travail effectué ou à faire selon les besoins.

Histoire de l'utilisateur

Un critère d'acceptation répertorié pour répondre à certaines exigences d'un utilisateur. Il est normalement écrit du point de vue d'un utilisateur final.

Rapidité

Une mesure pour pondérer le travail accepté dans une itération ou une zone de temps. Normalement, c'est la somme des points d'histoire acceptés dans une itération.