Agile - Guida rapida

Agile è una metodologia di sviluppo software per creare un software in modo incrementale utilizzando brevi iterazioni da 1 a 4 settimane in modo che il processo di sviluppo sia allineato alle mutevoli esigenze aziendali. Invece di uno sviluppo a passaggio singolo da 6 a 18 mesi in cui tutti i requisiti e i rischi sono previsti in anticipo, Agile adotta un processo di feedback frequente in cui un prodotto realizzabile viene consegnato dopo 1 a 4 settimane di iterazione.

Ruoli in Agile

Maestro di mischia

Uno Scrum Master è un team leader e facilitatore che aiuta i membri del team a seguire pratiche agili in modo che possano rispettare i loro impegni. Le responsabilità di uno scrum master sono le seguenti:

  • Per consentire una stretta cooperazione tra tutti i ruoli e le funzioni.

  • Per rimuovere eventuali blocchi.

  • Per proteggere la squadra da qualsiasi disturbo.

  • Collaborare con l'organizzazione per tenere traccia dei progressi e dei processi dell'azienda.

  • Per garantire che i processi Agile Inspect & Adapt siano sfruttati correttamente, il che include

    • Stand-up quotidiani,
    • Riunioni pianificate,
    • Demo,
    • Review,
    • Riunioni retrospettive e
    • Per facilitare le riunioni del team e il processo decisionale.

Proprietario del prodotto

Un Product Owner è colui che guida il prodotto dal punto di vista del business. Le responsabilità o un Product Owner sono le seguenti:

  • Definire i requisiti e dare priorità ai loro valori.
  • Per determinare la data di rilascio e il contenuto.
  • Assumere un ruolo attivo nella pianificazione dell'iterazione e nelle riunioni di pianificazione del rilascio.
  • Per garantire che il team stia lavorando sul requisito più prezioso.
  • Per rappresentare la voce del cliente.
  • Accettare le user story che soddisfano la definizione di criteri di accettazione fatti e definiti.

Team interfunzionale

Ogni team agile dovrebbe essere un team autosufficiente con 5 a 9 membri del team e un'esperienza media che va dai 6 ai 10 anni. In genere, un team agile è composto da 3 a 4 sviluppatori, 1 tester, 1 responsabile tecnico, 1 proprietario del prodotto e 1 scrum master.

Il Product Owner e lo Scrum master sono considerati parte di Team Interface, mentre gli altri membri fanno parte di Technical Interface.

In che modo un team Agile pianifica il proprio lavoro?

Un team Agile lavora in iterazioni per fornire storie utente in cui ogni iterazione dura da 10 a 15 giorni. Ogni user story è pianificata in base alla priorità e alle dimensioni del backlog. Il team usa la sua capacità - quante ore sono disponibili con il team per lavorare sulle attività - per decidere quanto ambito deve pianificare.

Punto

Un punto definisce quanto un team può impegnarsi. Un punto di solito si riferisce a 8 ore. Ogni storia è valutata in punti.

Capacità

La capacità definisce quanto un individuo può impegnarsi. La capacità è stimata in ore.

Cos'è una User Story?

Una user story è un requisito che definisce ciò che è richiesto dall'utente come funzionalità. Una user story può essere in due forme:

  • In qualità di <Ruolo utente> desidero <Funzionalità> in modo che <Valore aziendale>
  • Per <Valore aziendale> come <Ruolo utente> voglio <Funzionalità>

Durante la pianificazione del rilascio, viene fornita una stima approssimativa di una user story utilizzando la scala relativa come punti. Durante la pianificazione dell'iterazione, la storia viene suddivisa in attività.

Relazione tra storie di utenti e attività

  • La storia dell'utente parla di ciò che deve essere fatto. Definisce ciò di cui un utente ha bisogno.
  • L'attività parla di come deve essere eseguita. Definisce come deve essere implementata una funzionalità.
  • Le storie sono implementate da compiti. Ogni storia è una raccolta di compiti.
  • La storia dell'utente è divisa in attività quando è pianificata nell'iterazione corrente.
  • Le attività sono stimate in ore, in genere da 2 a 12 ore.
  • Le storie vengono convalidate utilizzando test di accettazione.

Quando una storia è finita

La squadra decide cosa donesi intende. I criteri possono essere:

  • Tutte le attività (sviluppo, test) sono state completate.
  • Tutti i test di accettazione sono in corso e sono stati superati.
  • Nessun difetto è aperto.
  • Il proprietario del prodotto ha accettato la storia.
  • Fornibile all'utente finale.

Cosa sono i criteri di accettazione?

I criteri definiscono la funzionalità, il comportamento e le prestazioni richieste da una funzione in modo che possa essere accettata dal proprietario del prodotto. Definisce cosa deve essere fatto in modo che lo sviluppatore sappia quando una user story è completa.

Come vengono definiti i requisiti?

I requisiti sono definiti come

  • Una User Story,
  • Con criteri di accettazione e
  • Compiti per implementare la storia.

Nel febbraio 2001, presso il resort Snowbird nello Utah, 17 sviluppatori di software si sono incontrati per discutere metodi di sviluppo leggeri. Il risultato del loro incontro è stato il seguente Manifesto Agile per lo sviluppo del software:

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro, siamo arrivati ​​a valorizzare:

  • Individui e interazioni su processi e strumenti
  • Software funzionante su documentazione completa
  • Collaborazione con il cliente nella negoziazione del contratto
  • Rispondere al cambiamento seguendo un piano

Cioè, mentre c'è valore negli elementi a destra, diamo più valore agli elementi a sinistra.

Dodici Principi del Manifesto Agile

  • Customer Satisfaction - Viene data la massima priorità per soddisfare i requisiti dei clienti attraverso la consegna tempestiva e continua di software di valore.

  • Welcome Change- Le modifiche sono inevitabili durante lo sviluppo del software. I requisiti in continua evoluzione dovrebbero essere i benvenuti, anche nella fase avanzata dello sviluppo. I processi agili dovrebbero lavorare per aumentare il vantaggio competitivo dei clienti.

  • Deliver a Working Software - Consegnare frequentemente un software funzionante, da poche settimane a pochi mesi, considerando tempi più brevi.

  • Collaboration - Gli uomini d'affari e gli sviluppatori devono lavorare insieme durante l'intera vita di un progetto.

  • Motivation- I progetti dovrebbero essere costruiti attorno a individui motivati. Fornire un ambiente per supportare i singoli membri del team e fidarsi di loro in modo da farli sentire responsabili per portare a termine il lavoro.

  • Face-to-face Conversation - La conversazione faccia a faccia è il metodo più efficiente ed efficace per trasmettere informazioni ae all'interno di un team di sviluppo.

  • Measure the Progress as per the Working Software - Il software funzionante è la chiave e dovrebbe essere la misura principale del progresso.

  • Maintain Constant Pace- I processi agili mirano allo sviluppo sostenibile. L'azienda, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante con il progetto.

  • Monitoring - Prestare regolare attenzione all'eccellenza tecnica e al buon design per migliorare l'agilità.

  • Simplicity - Mantieni le cose semplici e usa termini semplici per misurare il lavoro che non è stato completato.

  • Self-organized Teams - Un team agile dovrebbe essere auto-organizzato e non dovrebbe dipendere pesantemente da altri team perché le migliori architetture, requisiti e progetti emergono da team auto-organizzati.

  • Review the Work Regularly - Rivedere il lavoro svolto a intervalli regolari in modo che il team possa riflettere su come diventare più efficace e adattare il proprio comportamento di conseguenza.

Iterativo / incrementale e pronto per l'evoluzione

La maggior parte dei metodi di sviluppo agili suddividono un problema in attività più piccole. Non esiste una pianificazione diretta a lungo termine per nessuna esigenza. Normalmente, sono pianificate iterazioni che durano per un breve periodo di tempo, ad esempio da 1 a 4 settimane. Per ogni iterazione viene creato un team interfunzionale che opera in tutte le funzioni di sviluppo software come pianificazione, analisi dei requisiti, progettazione, codifica, test di unità e test di accettazione. Il risultato alla fine dell'iterazione è un prodotto funzionante e viene dimostrato agli stakeholder alla fine di un'iterazione.

Dopo la demo, vengono presi i commenti di revisione e si prevede di incorporarli nel software funzionante secondo necessità.

Comunicazione faccia a faccia

Ogni team agile dovrebbe avere un rappresentante del cliente come un proprietario del prodotto nella metodologia di scrum. Questo rappresentante è autorizzato ad agire per conto degli stakeholder e può rispondere alle domande degli sviluppatori tra le iterazioni.

Un radiatore di informazioni (display fisico) è normalmente posizionato ben visibile in un ufficio, dove i passanti possono vedere i progressi della squadra agile. Questo radiatore di informazioni mostra un riepilogo aggiornato dello stato di un progetto.

Ciclo di feedback

Lo stand-up quotidiano è una cultura comune di qualsiasi sviluppo agile; è anche conosciuto comedaily scrum. È una specie di breve sessione in cui ogni membro del team si riferisce a vicenda sullo stato di ciò che ha fatto, su cosa fare dopo e su eventuali problemi che sta affrontando.

Lo stand-up quotidiano, come suggerisce il nome, è un incontro quotidiano sullo stato di tutti i membri di un team agile. Non solo fornisce un forum per aggiornamenti regolari, ma mette anche a fuoco i problemi dei membri del team in modo che possano essere affrontati rapidamente. Lo stare in piedi quotidianamente è una pratica da non perdere, indipendentemente da come viene stabilito un team agile, indipendentemente dalla posizione dell'ufficio.

Cos'è il Daily Stand-up?

  • Uno stand-up quotidiano è una riunione quotidiana sullo stato di tutti i membri del team e si tiene all'incirca per 15 minuti.

  • Ogni membro deve rispondere a tre domande importanti:

    • Cosa ho fatto ieri?
    • Cosa farò oggi?
    • Qualsiasi impedimento che sto affrontando ... / Sono bloccato a causa di ...
  • Lo stand-up quotidiano è per l'aggiornamento dello stato, non per qualsiasi discussione. Per la discussione, i membri del team dovrebbero programmare un'altra riunione in un momento diverso.

  • I partecipanti di solito stanno in piedi invece di sedersi in modo che la riunione finisca rapidamente.

Perché alzarsi in piedi è importante?

I vantaggi di avere uno stand-up quotidiano in agile sono i seguenti:

  • Il team può valutare i progressi su base giornaliera e vedere se sono in grado di fornire secondo il piano di iterazione.
  • Ogni membro del team informa tutto sui suoi impegni per la giornata.
  • Fornisce visibilità alla squadra su eventuali ritardi o ostacoli.

Chi partecipa a uno stand-up?

  • Lo scrum master, il product owner e il delivery team dovrebbero partecipare quotidianamente allo stand-up.

  • Le parti interessate e i clienti sono incoraggiati a partecipare alla riunione e possono agire come osservatori, ma non dovrebbero partecipare agli stand-up.

  • È responsabilità dello scrum master prendere nota delle domande di ogni membro del team e dei problemi che stanno affrontando.

Squadre geograficamente disperse

Gli stand-up possono essere eseguiti in diversi modi, nel caso in cui i membri del team agile operino da fusi orari diversi -

  • Seleziona un membro a rotazione, che può partecipare alla riunione in piedi di squadre situate in diversi fusi orari.

  • Avere uno stand-up separato per squadra, aggiornare lo stato dello stand-up in uno strumento come Rally, SharePoint, Wiki, ecc.

  • Prepara un'ampia varietà di strumenti di comunicazione come teleconferenza, videoconferenza, messaggistica istantanea o qualsiasi altro strumento di condivisione delle conoscenze di terze parti.

La definizione di done per User Story, Iteration e Release sono forniti di seguito.

Storia dell'utente

Una user story è un requisito formulato in poche frasi nel linguaggio quotidiano di un utente e dovrebbe essere completato all'interno di un'iterazione. Una user story è finita quando

  • Tutto il codice relativo è stato archiviato.
  • Tutti i casi di unit test sono stati superati.
  • Tutti i casi di test di accettazione sono stati superati.
  • Il testo della guida è scritto.
  • Il Product Owner ha accettato la storia.

Iterazione

Un'iterazione è una raccolta temporizzata di storie / difetti degli utenti su cui lavorare e accettare all'interno del rilascio di un prodotto. Le iterazioni vengono definite durante la riunione di pianificazione dell'iterazione e completate con una demo di iterazione e una riunione di revisione. Un'iterazione è anche definita come asprint. Quando viene eseguita un'iterazione

  • Il backup del prodotto è completo.
  • Le prestazioni sono state testate.
  • Le storie degli utenti sono state accettate o spostate all'iterazione successiva.
  • I difetti sono stati corretti o rinviati alla successiva iterazione.

pubblicazione

Un rilascio è una pietra miliare importante che rappresenta una consegna interna o esterna di una versione funzionante e testata del prodotto / sistema. Un rilascio è fatto quando

  • Il sistema è sottoposto a stress test.
  • Le prestazioni sono ottimizzate.
  • Vengono eseguite le convalide di sicurezza.
  • Il piano di ripristino di emergenza viene testato.

Lo scopo della pianificazione del rilascio è creare un piano per fornire un incremento al prodotto. Viene eseguito ogni 2 o 3 mesi.

Chi è coinvolto?

  • Scrum Master - Lo scrum master funge da facilitatore per il team di consegna agile.

  • Product Owner - Il product owner rappresenta la visione generale del product backlog.

  • Agile Team - Il team di consegna agile fornisce approfondimenti sulla fattibilità tecnica o su eventuali dipendenze.

  • Stakeholders - Le parti interessate come clienti, gestori di programmi, esperti in materia agiscono come consulenti quando vengono prese le decisioni sulla pianificazione del rilascio.

Prerequisiti della pianificazione

I prerequisiti per la pianificazione del rilascio sono i seguenti:

  • Un product backlog classificato, gestito dal Product Owner. Generalmente vengono utilizzate da cinque a dieci funzioni che il proprietario del prodotto ritiene possano essere incluse in una versione

  • Il contributo del team su capacità, velocità nota o su qualsiasi sfida tecnica

  • Visione di alto livello

  • Obiettivo di mercato e di business

  • Riconoscimento se sono necessari nuovi elementi del backlog di prodotto

Materiali richiesti

L'elenco dei materiali necessari per la pianificazione del rilascio è il seguente:

  • Ordine del giorno pubblicato, scopo
  • Lavagne a fogli mobili, lavagne bianche, pennarelli
  • Proiettore, modo per condividere computer con dati / strumenti necessari durante la riunione di pianificazione
  • Dati di pianificazione

Dati di pianificazione

L'elenco dei dati necessari per fare la pianificazione del rilascio è il seguente:

  • Precedenti iterazioni o risultati della pianificazione del rilascio
  • Feedback di varie parti interessate su prodotto, condizioni di mercato e scadenze
  • Piani d'azione delle versioni / iterazioni precedenti
  • Caratteristiche o difetti da considerare
  • Velocità rispetto ai precedenti rilasci / stime.
  • Calendari organizzativi e personali
  • Input di altri team ed esperti in materia per gestire eventuali dipendenze

Produzione

L'output di una pianificazione del rilascio può essere il seguente:

  • Piano di rilascio
  • Commitment
  • Problemi, preoccupazioni, dipendenze e ipotesi che devono essere monitorati
  • Suggerimenti per migliorare le pianificazioni del rilascio futuro

Agenda

L'agenda di una pianificazione del rilascio può essere:

  • Opening ceremony - Messaggio di benvenuto, scopo della revisione e agenda, strumenti organizzativi e introduzione agli sponsor aziendali.

  • Product Vision, Roadmap - Mostra l'immagine grande del prodotto.

  • Review previous releases - Discussione su qualsiasi elemento che possa influire sul piano.

  • Release name / theme - Ispeziona lo stato attuale dei temi della roadmap e apporta le modifiche necessarie, se presenti.

  • Velocity - Presentare la velocità per la versione corrente e delle versioni precedenti.

  • Release schedule - Rivedi le tappe fondamentali e la decisione sui tempi per il rilascio e le iterazioni all'interno del rilascio.

  • Issues and concerns - Verificare eventuali dubbi o problemi e registrarli.

  • Review and Update the Definition of Done - Rivedere la definizione di done e apportare le modifiche appropriate in base alla tecnologia, alle abilità o ai cambiamenti nei membri del team dall'ultima iterazione / versione.

  • Stories and items to be considered - Presentare le storie degli utenti e le funzionalità del backlog del prodotto da considerare per la pianificazione nella versione corrente.

  • Determine sizing values - Se la velocità è sconosciuta, pianificare i valori di dimensionamento da utilizzare nella pianificazione del rilascio.

  • Coarse the size of stories- Il team di consegna determina la dimensione appropriata delle storie prese in considerazione e divide le storie in più iterazioni se una storia è troppo grande. Il product owner e gli esperti in materia chiariscono i dubbi, elaborano i criteri di accettazione e fanno le giuste suddivisioni della storia. Lo scrum master facilita la collaborazione.

  • Map stories to iterations- Il team di consegna e il proprietario del prodotto spostano le storie / i difetti nelle iterazioni in base alle dimensioni e alla velocità. Lo scrum master facilita la collaborazione.

  • New concerns or issues - Controlla eventuali nuovi problemi in base all'esperienza precedente e registra lo stesso.

  • Dependencies and assumptions - Verificare eventuali dipendenze / ipotesi pianificate durante la pianificazione del rilascio.

  • Commit- Lo scrum master richiede la pianificazione. Il team di consegna e il proprietario del prodotto lo segnalano come il piano migliore e quindi si impegnano a passare al livello successivo di pianificazione, ovvero la pianificazione dell'iterazione.

  • Communication and logistics planning - Rivedere / aggiornare la comunicazione e la pianificazione logistica per il rilascio.

  • Parking lot - Elabora parcheggio significa che tutti gli elementi devono essere risolti o impostati come elementi di azione.

  • Distribute Action items and action plans - Distribuire gli elementi di azione tra i loro proprietari, elaborare il piano d'azione.

  • Retrospect - Chiedere feedback ai partecipanti per rendere la riunione di successo.

  • Close - Festeggia il successo.

Lo scopo della pianificazione dell'iterazione è che il team completi la serie di elementi del backlog di prodotto di alto livello. Questo impegno è definito nel tempo in base alla durata dell'iterazione e alla velocità del team.

Chi è coinvolto?

  • Scrum Master - Lo scrum master funge da facilitatore per il team di consegna agile.

  • Product Owner - Il product owner si occupa della visualizzazione dettagliata del product backlog e dei relativi criteri di accettazione.

  • Agile Team - La consegna agile definisce i loro compiti e imposta le stime dello sforzo richiesto per adempiere all'impegno.

Prerequisiti della pianificazione

  • Gli elementi nel backlog del prodotto sono dimensionati e hanno un relativo story point assegnato.
  • La classificazione è stata assegnata agli elementi del portfolio dal proprietario del prodotto.
  • I criteri di accettazione sono stati chiaramente indicati per ogni elemento del portafoglio.

Processo di pianificazione

Di seguito sono riportati i passaggi coinvolti nella pianificazione dell'iterazione:

  • Determina quante storie possono adattarsi a un'iterazione.
  • Suddividi queste storie in attività e assegna ciascuna attività ai rispettivi proprietari.
  • A ogni attività vengono fornite stime in ore.
  • Queste stime aiutano i membri del team a controllare quante ore di attività ogni membro ha per l'iterazione.
  • Ai membri del team vengono assegnati compiti in base alla loro velocità o capacità in modo che non siano sovraccaricati.

Calcolo della velocità

Un team agile calcola la velocità in base alle iterazioni passate. La velocità è un numero medio di unità necessarie per completare le storie degli utenti in un'iterazione. Ad esempio, se una squadra ha preso 12, 14, 10 story point in ciascuna iterazione per le ultime tre iterazioni, la squadra può prendere 12 come velocità per l'iterazione successiva.

La velocità pianificata indica al team quante storie utente possono essere completate nell'iterazione corrente. Se il team termina rapidamente le attività assegnate, è possibile inserire più storie utente. In caso contrario, le storie possono essere spostate anche all'iterazione successiva.

Capacità dell'attività

La capacità di una squadra deriva dai seguenti tre fatti:

  • Numero di ore di lavoro ideali in un giorno
  • Giorni di persona disponibili nell'iterazione
  • Percentuale di tempo in cui un membro è disponibile esclusivamente per il team.

Supponiamo che un team abbia 5 membri, impegnati a lavorare a tempo pieno (8 ore al giorno) su un progetto e nessuno sia in congedo durante un'iterazione, quindi la capacità dell'attività per un'iterazione di due settimane sarà:

5 × 8 × 10 = 400 ore

Fasi di pianificazione

  • Il Product Owner descrive l'elemento con il punteggio più alto del backlog del prodotto.
  • Team descrive le attività richieste per completare l'elemento.
  • I membri del team possiedono i compiti.
  • I membri del team stimano il tempo necessario per completare ogni attività.
  • Questi passaggi vengono ripetuti per tutti gli elementi nell'iterazione.
  • Se un individuo è sovraccarico di compiti, il suo compito viene distribuito tra gli altri membri del team.

Un product backlog è un elenco di elementi da fare. Gli articoli sono classificati con le descrizioni delle caratteristiche. In uno scenario ideale, gli elementi dovrebbero essere suddivisi in storie utente.

Perché il Product Backlog è importante?

  • È preparato in modo che sia possibile fornire stime a ciascuna funzionalità.
  • Aiuta a pianificare la roadmap del prodotto.
  • Aiuta a riorganizzare le funzionalità in modo che sia possibile aggiungere più valore al prodotto.
  • Aiuta a determinare a cosa dare la priorità per primo. Il team classifica l'oggetto e quindi crea valore.

Caratteristiche del Product Backlog

  • Ogni prodotto dovrebbe avere un backlog di prodotto che può avere una serie di funzionalità da grandi a molto grandi.

  • Più team possono lavorare su un singolo prodotto arretrato.

  • La classificazione delle funzionalità viene eseguita in base al valore aziendale, al valore tecnico, alla gestione del rischio o all'adeguatezza strategica.

  • Gli elementi con il punteggio più alto vengono scomposti in storie più piccole durante la pianificazione del rilascio in modo che possano essere completati nelle iterazioni future.

Criteri di accettazione

Sono le condizioni stabilite dal proprietario del prodotto o dal cliente per accettare che una caratteristica sia valida e aderente ai loro requisiti.

Gestione degli arretrati

È un processo continuo in cui il product manager o il cliente gestisce il backlog del prodotto ottenendo feedback da team agili. Questo processo comporta l'assegnazione di priorità agli elementi del portfolio, la suddivisione in elementi più piccoli, la pianificazione per iterazioni future, la creazione di nuove storie, l'aggiornamento dei criteri di accettazione o l'elaborazione di criteri di accettazione nei dettagli.

Capacità

È la quantità di lavoro che un team può richiedere per completare in un'unica iterazione.

Caratteristica

Un miglioramento apportato a un prodotto o capacità di valore per gli stakeholder che può essere sviluppato in una versione.

Iterazione

Un elemento di lavoro basato su un tema che può essere completato entro un intervallo di tempo e accettato all'interno del rilascio di un prodotto. Il lavoro di iterazione viene definito durante la pianificazione dell'iterazione e termina con la demo e la riunione di revisione. È anche definito Sprint.

Incremento

Un incremento è il cambiamento di stato di un prodotto che subisce uno sviluppo graduale. Normalmente è rappresentato da pietre miliari o numero di iterazioni fisse.

Proprietario del prodotto

Il product owner è un membro del team di consegna Agile, responsabile della raccolta e della classificazione dei requisiti aziendali nel backlog del prodotto. Un product owner comunica cosa deve essere fatto in una release / iterazione. Stabilisce gli impegni ed è responsabile di proteggere il team da qualsiasi cambiamento nei requisiti durante un'iterazione.

Backlog di prodotto

Insieme di requisiti di prodotto funzionali e non funzionali.

Elementi del Product Backlog

Possono essere storie di utenti, difetti, funzionalità che devono essere sviluppate dal team agile.

Punti

Un'unità comune utilizzata per impostare la dimensione relativa delle storie degli utenti, delle funzionalità o di qualsiasi altro elemento del portfolio.

pubblicazione

Una casella temporale in cui si lavora per supportare la consegna di incrementi verificabili a un software. In Scrum, una versione consiste in più iterazioni.

Requisiti

Una specifica di un prodotto software per soddisfare un contratto o una funzionalità dichiarati. Le storie degli utenti e gli elementi del portfolio sono tipi di requisiti.

Punti della storia

Un'unità utilizzata dal team Agile per stimare le dimensioni relative delle storie degli utenti e delle funzionalità.

Sprint

Come l'iterazione.

Timebox

Un periodo di tempo fisso in cui deve essere sviluppato un deliverable. Normalmente, oltre a fissare la data di inizio e di fine di una casella degli orari, viene anche fissato il numero di risorse.

Compito

È un'unità di lavoro che contribuisce al completamento di una user story all'interno di un'iterazione. Le storie degli utenti vengono scomposte in più attività e ciascuna attività può essere suddivisa tra i membri del team contrassegnandoli come proprietari delle attività. I membri del team possono assumersi la responsabilità di ogni attività, aggiornare le stime, registrare il lavoro svolto o fare ciò che desiderano.

Storia dell'utente

Un criterio di accettazione elencato per soddisfare determinati requisiti di un utente. Normalmente è scritto dal punto di vista di un utente finale.

Velocità

Una misura per pesare il lavoro accettato in un'iterazione o in una casella temporale. Normalmente è la somma dei punti della storia accettati in un'iterazione.