AgileAMK-mallin avulla pyrimme tuottamaan verkko-kursseja ketterästi verkostoyhteistyönä. Mallia kehitetään Uutta avointa energiaa-hankkeessa. www.uusiavoinenergia.fi
Case Peikko Group: Tuottava myyntityö globaaleilla markkinoilla | CGI:n Micr...
UAE-hanke AgileAMK-malli 0.5 vsr
1. AgileAMK-malli 0.5
Leena Paaso (OAMK), Eeva Dahlberg (Novia), Mauri Kantola (Turun amk), Marja
Keränen (VirtuaaliAMK-verkosto), Teija Lehto (VirtuaaliAMK-verkosto), Jenni
Meriläinen (LAMK), Jarmo Mäntyvaara (Turun amk), Pekka Tervonen (KAMK),
Miia Törmänen (VirtuaaliAMK-verkosto)
Tämä teos on lisensoitu Creative Commons
Nimeä-JaaSamoin 4.0 Kansainvälinen -lisenssillä.
2. Taustaa 1/2
• Ketterä kehitys on alun perin joukko ohjelmistotuotantoprojekteissa käytettäviä
menetelmiä.
– Ketterille menetelmille yhteistä on toimivan tuotteen ensisijaisuus, suora viestintä ja nopea
muutoksiin reagointi (1)
– Ketterä kehitys tapahtuu tyypillisesti sprinteissä, joiden aikana projektin määrittely tarkentuu
– Vaatimusmäärittelyn apuna voidaan käyttää helposti ymmärrettäviä käyttäjätarinoita (2)
• AgileAMK-mallissa lähtökohtana ovat:
– Scrum, joka tarjoaa viitekehyksen monimutkaisten ongelmien ratkaisuun ja tuotteiden
kehitykseen, ottamatta kantaa toteutustapoihin tai –tekniikoihin
• Scrum koostuu kehitystiimeistä, tapahtumista, tuotoksista ja säännöistä. Jokainen elementti palvelee
tiettyä tarkoitusta ja on tärkeä osa Scrumin onnistumista
• Perustuu empirismiin, jonka mukaan tieto perustuu kokemukseen ja päätökset tehdään tosiasioiden
pohjalta. (3)
– Empiirisellä prosessinhallinnassa olennaista on: Läpinäkyvyys, tarkastelu ja sopeuttaminen.
Uutta avointa energiaa - hanke 2
3. Taustaa 2/2
– Kanban on tuotannon ajoitusjärjestelmä, joka auttaa määrittämään mitä pitää tuottaa, milloin,
ja kuinka paljon.
• Kanban tulee japanin kielestä ja tarkoittaa taulua tai mainoskylttiä, se onkin hyvin kuvaavaa, koska
käytännössä tehtävistä tehdään esim. kortteja joita siirretään työvaihe-taulusta toiseen (1)
– Scrum-ban ohjelmistotuotannon malli, joka perustuu Scrum- ja Kanban-menetelmiin.
• Siinä sovelletaan Scrumin päivittäisiä kokouksia ja muita käytäntöjä sekä Kanban-menetelmälle
ominaista on työvaiheiden visualisointia.
• Scrumin ja Kanbanin erot:
– Scrumissa sprintit ovat aikarajattuja, kun taas Kanbanissa työskenteleminen on jatkuvaa.
– Scrum painottaa monitaitoisia tiimejä, jotka pystyvät itsenäisesti kehittämään julkaistavan tuotteet. Kanban taas
mahdollistaa erikoistuneet, toiminnalliset tiimit. (2)
Uutta avointa energiaa - hanke 3
4. Uutta avointa energiaa - hanke 4
Ketterän kehityksen julistus
Arvostamme yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja
Arvostamme toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota
Arvostamme asiakasyhteistyötä enemmän kuin sopimusneuvotteluja
Arvostamme vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa
Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.
Ketterän kehityksen julistustus http://agilemanifesto.org/iso/fi/
6. Vaiheet askelittain
6
1 2 3 4 6 7Aika
Ideoidaan
asiakkaan
kanssa
Muodostetaan
Moocin
kehitysjono
Pidetään
sprintin
suunnittelu-
palaveri
Muodostetaan
Sprintin
kehitysjono
Pidetään
sprintin
katselmus
Pidetään
sprintin
jälkitarkastelu
Tuotanto
Käytettävyys
Saavutettavuus
Mitä
tehdään
Kuka
Laatu-
kortit
Tuotteen
omistaja
Tuotteen omistaja
Kehitystiimi
Tuotteen omistaja
Kehitystiimi
Asiakas
Pedagogiikka
Sisältö
(Tuotteen omistaja)
Kehitystiimi
Pedagogiikka
Sisältö
Käytettävyys
Saavutettavuus
Kehitystiimi
Tuotteen omistaja
AgileAMK-master
Kehitystiimi
AgileAMK-master
Pedagogiikka
Sisältö
Käytettävyys
Saavutettavuus
Tuotanto
Kehitystiimi
AgileAMK-master
Asiakas
Pedagogiikka
Sisältö
Käytettävyys
Saavutettavuus
5
Vaiheita 3 – 7 toistetaan kunnes Mooc on valmis.
Pitkän aikavälin
suunnitelma
Lyhyen aikavälin
suunnitelma
Tutkimus Lähtötasotesti AgileAMK-mallin
toimivuus
Tehtävät sis.
määrittely,
suunnittelu, toteutus,
testaus ja korjaus.
Päiväpalaverit
7. Termit
• Tuotteen kehitysjono kuvaa tuotekokonaisuuden ja näyttää mitä asiakkaalle lopulta toimitetaan
1. Asettaa projektin tavoitteet ja etenemisen näkyväksi sekä tiimille että asiakkaalle
2. Huomioidaan asiakkaan toiveet
3. Organisoi projektikokonaisuuden
Vaatimusmäärittelyn sijasta voidaan käyttää käyttäjätarinoita (User story) kuvaamaan tuotteen ominaisuuksia.
Käyttäjätarina kertoo kuka tekee, mitä tekee ja miksi
• Sprintti (engl. Sprint) eli kehitysjakso
– Sprintti on 1-4 viikon mittainen aikaraja, eräänlainen miniprojekti.
– Sprintin alussa pidetään sprintin suunnittelupalaveri, jossa: suunnitellaan sprintin tavoitteet ja tehtävät sekä saavutetaan yhteinen
ymmärrys vaatimuksista
– Tavoitteet pilkotaan tehtäviksi, joiden pohjalta luodaan sprintin tehtävälista
• Sprintin kehitysjono eli tehtävälista
– Sprintin kehitysjonoon kehitystiimi luo yksityiskohtaiset tehtävät ja arvioi jokaiseen tehtävään kuluvan ajan
• Suuret tehtävät pilkotaan pienimmiksi niin, että ne voidaan suorittaa yhden tai kahden päivän aikana.
• Tehtävät ja niiden määrä vaihtelevat sprintin tavoitteen mukaan.
– Sprintin lopuksi järjestetään Sprinttikatselmus, jossa kehitystiimi esittelee konkreettiset saavutukset
– Ennen seuraavan sprintin aloittamista pidetään sprintin retrospektiivi eli jälkitarkastelu, jossa tarkastellaan prosessin näkökulmasta mikä
sujui hyvin ja mitä voitaisiin parantaa jatkossa.
Uutta avointa energiaa - hanke 7
8. Toimintatavat 1/2
• Scrumia soveltaen AgileAMK-mallissa työskennellään toistavasti ja iteratiivisesti
– MOOC kehittyy valmiiksi useiden kehitysjaksojen aikana
– Ennustettavuus ja itseohjautuvuus lisääntyvät
– Riskit vähenevät, kun mahdolliset virheet havaitaan ajoissa ja muutoksiin voidaan reagoida nopeasti.
– Lyhyen aikavälin suunnittelu ja seurattavuus paranevat
– Yhteiset toimintamallit verkostolle ja ihmisille helpottavat ja selkiyttävät työskentelyä
• Säännölliset palaverit
– Sprintin suunnittelupalaveri
– Päiväpalaveri: kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraavalla päivälle/viikolle.
Mietitään mitä voidaan toteuttaa ennen seuraavaa palaveria.
• Palaverissa jokainen kehitystiimin jäsen kertoo vuorollaan
– Mitä olen tehnyt viime palaverin jälkeen
– Mitä aion tehdä ennen seuraavaa palaveria
– Onko työni etenemisellä esteitä.
• Palaveri on lyhyt n. 15 min
– Sprinttikatselmus
– Sprintin retrospektiivi eli jälkitarkastelu
Uutta avointa energiaa - hanke 8
9. Toimintatavat 2/2
• Työvaiheiden visualisointi
– Työvaiheiden visualisointiin on olemassa erilaisia ohjelmistoja, joissa näytetään kehitystiimin käyttäjätarinat, ohjelmistovirheet tai tehtävät
jaoteltuna eri vaiheisiin.
– Työvaiheet yksinkertaisimmilllaan:
• aloittamattomat
• käynnissä olevat
• tehdyt tehtävät tai käyttäjätarinat.
• Kehitystiimit voivat tarvittaessa lisätä vaiheita (esim. määritelty, suunniteltu, testattu, toimitettu)
– UAE-hankkeessa käytetään Trelloa, jonka avulla tehtävät jaotellaan eri vaiheisiin.
Uutta avointa energiaa - hanke 9
10. Tiimit
Tuotteen omistajan (engl. Product Owner)
• Hankkeen päätoteuttaja
• Määrittelee tuotteen vaatimukset
• Järjestää tuotteen kehitysjonon yhteistyössä
kehitystiimin kanssa
• On aina yksi henkilö
• tuntee tuotteen liiketoimintaa ja edustaa
asiakkaita ja käyttäjiä
• varmistaa, että tiimi toteuttaa spriteissä tuotteen
kannalta keskeisiä vaatimuksia
• hyväksyy sprittikatselmuksessa edellisen sprintin
version
• osallistuu sprintin suunnittelupalaveriin
varmistaakseen, että kehitystiimi ymmärtää
sprinttiin valittavat tuotteen kehitysjonon kohdat
riittävällä tarkkuudella
• auttaa kehitystiimiä ymmärtämään vaatimuksia
Kehitystiimi (engl. Development Team).
• Asiantuntija-tiimi
• koostuu ammattilaisista
• ainoastaan kehitystiimin jäsenet osallistuvat
tuoteversion kehitykseen
• ovat monitaitoisia sisältäen kaiken tarvittavan
osaamisen julkaisukelpoisen tuoteversion
kehittämiseksi
• kehitystiimin jäsenillä voi olla erityistä osaamista
tai erilaisia työn painopisteitä, mutta vastuu
kehityksestä kuuluu koko kehitystiimille
AgileAMK -master (engl. Scrum Master)
• Koordinaattori tai tiiminvetäjä
• vastaa siitä, että kaikki ymmärtävät ja käyttävät
AgileAMK-mallia
• poistaa työskentelyä haittaavia esteitä
• valmentaa ryhmää itseohjautuvuuteen
• vastaa siitä, että tiimin päivittäinen työskentely
on tuottavaa ja tarkkailee työn etenemistä
• Tiiminvetäjällä ei ole tiimin jäseniin suoraa
määräysvaltaa kuten perinteisellä esimiehellä,
vaan hän vaikuttaa tiimiin prosessin kautta
Uutta avointa energiaa - hanke 10
11. 1. Määrittely
2. Suunnittelu
3. Toteutus4. Testaus
5. Korjaus
Esim. nZEB-rakennus MOOC
Oppimisympäristö
Energiatehokkuus
vaatimukset
Rakennusten
energian käyttö
Energiatehokkaat
rakenteet
Arkkitehtuuri ja
energiatehokkuus
Talotekniikka
Uutta avointa energiaa - hanke 11
nZeb-rakennus
MOOC:n kehitysjono
Kuvaa tuotekokonaisuuden ja
näyttää mitä asiakkaalle toimitetaan
> Pitkän aikavälin suunnitelma
Sprintit
1-4vkoa
Päiväpalaverit
Sprintin kehitysjono
Materiaalien kerääminen
Tekstit ja linkit
Kuvat
Videot
Muut tiedostot
Oheismateriaali
Tehtävät
Testi
Arvioinnit
Opettajaa ohjaava mat.
Opiskelijaa ohjaava mat.
Paperiprototyyppi
Määritellään sprintin tavoite,
tehtävät, tehtävien kesto
ja aikataulu
> Lyhyen aikavälin suunnitelma
Valmis
opiskeltavissa
oleva Moocin osa
…..
Tehtävien kesto
1-2 vrk
Sprinttikatselmus
Sprintin
jälkitarkastelu
12. Lähteet
• Ketterät menetelmät, agile, LEAN ja scrum.
http://www.itewiki.fi/opas/ketterat-menetelmat-agile-lean-ja-scrum/ 1.12.2015
• Ken Schwaber ja Jeff Sutherland. 2014: The Scrum Guide™ Scrumin määritelmä ja pelisäännöt.
https://scrumwell.files.wordpress.com/2014/03/scrum-guide-2013-fi-v1-1.pdf 1.12.2015
• Sulautettujen järjestelmien ketterä käsikirja.
Lehtonen, Tuomivaara, Rantala, Känsälä, Mäkilä, Jokela, Könnölä, Kaisti, Suomi, Isomäki & Ylitolva.
15.10.2015
http://www.doria.fi/bitstream/handle/10024/99142/Sulautettujen_jarjestelmien_kettera_kasikirja
_Painos1.pdf?sequence=2
• Sivistystoimen työkalupakki palvelumuotoiluun: http://designresearch.aalto.fi/groups/encore/wp-
content/uploads/2013/11/Sivistystoimen_tyokalupakki_palvelumuotoiluun2.pdf 15.10.2015
• Kanban: https://fi.wikipedia.org/wiki/Kanban 15.10.2015
• Scrum: https://fi.wikipedia.org/wiki/Scrum 15.10.2015
• User Stories. Agile Alliance. http://guide.agilealliance.org/guide/user-stories.html 10.12.2015
• Ketterät menetelmät: Scrum Panu Leppäniemi, 2012
http://ohjelmistotuotanto.panuleppaniemi.com/agile-scrum/ 15.10.2015
Uutta avointa energiaa - hanke 12
Notas del editor
1) Ketterä ohjelmistokehitys https://fi.wikipedia.org/wiki/Ketter%C3%A4_ohjelmistokehitys
2) User Stories: http://guide.agilealliance.org/guide/user-stories.html (10.12.2015)
3) Ketterät menetelmät, agile, LEAN ja scrum. http://www.itewiki.fi/opas/ketterat-menetelmat-agile-lean-ja-scrum/ 1.12.2015
Kuva piirretty oheisen julkaisun pohjalta (s5.): http://www.doria.fi/bitstream/handle/10024/99142/Sulautettujen_jarjestelmien_kettera_kasikirja_Painos1.pdf?sequence=2
Tuotteen kehitysjono,
- kehitysjonosta vastaa Tuotteen omistaja, joka tässä tapauksessa on Hankkeen päätoteuttaja > voiko olla?
kuvaa tuotekokonaisuuden ja näyttää millaisista osakokonaisuuksista moduuleista ja opintomoduuleista esim. kurssi koostuu
Tuotteen kehitysjonon vaatimusmäärittelyssä voidaan käyttää apuna käyttäjätarinoita (userstory)
Sprintin kehitysjono:
sprintin kehitystiimi määrittelee kunkin sprintin tavoitteet, tehtävät ja tehtävien kestot kussakin sprintinsuunnittelupalaverissa.
Määritellään mikä on valmis; mikä on riittävä taso valmiille
Sprintin tehtävät:
määrittely, suunnittelu, toteutus ja testaus > Sprintin vaatimuksia vastaava valmis osakokonaisuus.
User Story (käyttäjätarina) kuvataan lopullisen Moocin ominaisuudet lauseena, jonka käyttäjä ymmärtää.
Ts. käyttäjätarina kuvaa kuka tekee ja mitä, sekä joskus myös miksi (eli mikä hyöty tästä toiminnosta seuraa).
Moocilla on siis useita käyttäjätarinoita, jotka koostamalla voi hahmottaa, minkälainen kurssi oikein on kyseessä.
Ketterät menetelmät: Scrum Panu Leppäniemi, 2012 http://ohjelmistotuotanto.panuleppaniemi.com/agile-scrum/ 15.10.2015
User Stories. Agile Alliance. http://guide.agilealliance.org/guide/user-stories.html 10.12.2015
Tässä vielä lainaus Scrum Guide 2013 - FI - Final 1.0 s.13: printin kehitysjono koostuu sprinttiin valituista tuotteen kehitysjonon kohdista sekä suunnitelmasta niiden toteuttamiseksi. Sprintin kehitysjono on kehitystiimin antama ennuste siitä, mitä toiminnallisuutta seuraavaan tuoteversioon tulee sisältymään sekä tarvittavasta työstä toiminnallisuuden toteuttamiseksi. Sprintin kehitysjono tekee näkyväksi kaiken työn, jonka kehitystiimi tunnistaa tarpeelliseksi saavuttaakseen sprintin tavoitteen.
Sprintin suunnittelupalaveri (engl. Sprint Planning Meeting) on palaveri, jossa suunnitellaan sprintin aikana tehtävä työ.
Sprintin suunnittelupalaverin pituus rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille.
Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa. Esimerkiksi kahden viikon sprintille varataan enintään neljä tuntia.
Päiväpalaveri (engl. Daily Scrum) on enintään 15 minuutin mittainen aikarajattu palaveri, jossa kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraaville 24 tunnille.
Tämä tapahtuu tarkastelemalla edellisen päiväpalaverin jälkeen tehtyä työtä ja ennustamalla, mitä voidaan toteuttaa ennen seuraavaa päiväpalaveria.
Päiväpalaverissa jokainen kehitystiimin jäsen kertoo vuorollaan:
Mitä olen tehnyt viime päiväpalaverin jälkeen,
Mitä aion tehdä ennen seuraavaa päiväpalaveria, ja
Onko työni etenemisellä esteitä.
Tuotteen kehitysjonon työstö (engl. Product Backlog Grooming) tarkoittaa yksityiskohtien, työmääräarvioiden ja kehitysjonon kohtien keskinäisen järjestyksen lisäämistä.
Kyseessä on toistuva prosessi, jossa tuotteen omistaja ja kehitystiimi lisäävät yhteistyössä yksityiskohtia tuotteen kehitysjonoon.
Työstön aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. Tuotteen omistaja voi kuitenkin milloin tahansa muulloinkin päivittää niitä.
Kehitystiimi vastaa kaikista työmääräarvioista. Tuotteen omistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään vaatimuksia ja tekemään kompromisseja, mutta työn tekijät antavat lopullisen työmääräarvion.
Sprinttikatselmus (engl. Sprint Review) on sprintin lopussa pidettävä epämuodollinen palaveri, jossa tarkastellaan kehitetty tuoteversio ja sopeutetaan tarvittaessa tuotteen kehitysjonoa.
Sprinttikatselmuksen aikana tiimi ja sidosryhmät selvittävät yhteistyössä, mitä sprintissä kehitettiin.
Perustuen tähän tietoon ja mahdollisiin sprintin aikana tuotteen kehitysjonoon tehtyihin muutoksiin osallistujat keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi.
Kehitystiimin esittämän tuotedemon tavoitteena on saada palautetta, edistää keskustelua ja luoda realistinen pohja seuraavan sprintin suunnittelupalaverille.
Sprinttikatselmus rajataan enintään neljään tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa, esimerkiksi kahden viikon sprintille enintään kaksi tuntia.
Sprintin retrospektiivi eli jälkitarkastelu (engl. Sprint Retrospective) antaa scrumtiimille tilaisuuden tarkastella työskentelyään ja tehdä suunnitelman kehitysprosessin parannuksille, jotka toteutetaan seuraavassa sprintissä.
Sprintin retrospektiivi pidetään sprinttikatselmuksen jälkeen ja ennen seuraavan sprintin suunnittelupalaveria. Palaveri rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa.
Sprintin suunnittelupalaveri (engl. Sprint Planning Meeting) on palaveri, jossa suunnitellaan sprintin aikana tehtävä työ.
Sprintin suunnittelupalaverin pituus rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille.
Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa. Esimerkiksi kahden viikon sprintille varataan enintään neljä tuntia.
Päiväpalaveri (engl. Daily Scrum) on enintään 15 minuutin mittainen aikarajattu palaveri, jossa kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraaville 24 tunnille.
Tämä tapahtuu tarkastelemalla edellisen päiväpalaverin jälkeen tehtyä työtä ja ennustamalla, mitä voidaan toteuttaa ennen seuraavaa päiväpalaveria.
Päiväpalaverissa jokainen kehitystiimin jäsen kertoo vuorollaan:
Mitä olen tehnyt viime päiväpalaverin jälkeen,
Mitä aion tehdä ennen seuraavaa päiväpalaveria, ja
Onko työni etenemisellä esteitä.
Tuotteen kehitysjonon työstö (engl. Product Backlog Grooming) tarkoittaa yksityiskohtien, työmääräarvioiden ja kehitysjonon kohtien keskinäisen järjestyksen lisäämistä.
Kyseessä on toistuva prosessi, jossa tuotteen omistaja ja kehitystiimi lisäävät yhteistyössä yksityiskohtia tuotteen kehitysjonoon.
Työstön aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. Tuotteen omistaja voi kuitenkin milloin tahansa muulloinkin päivittää niitä.
Kehitystiimi vastaa kaikista työmääräarvioista. Tuotteen omistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään vaatimuksia ja tekemään kompromisseja, mutta työn tekijät antavat lopullisen työmääräarvion.
Sprinttikatselmus (engl. Sprint Review) on sprintin lopussa pidettävä epämuodollinen palaveri, jossa tarkastellaan kehitetty tuoteversio ja sopeutetaan tarvittaessa tuotteen kehitysjonoa.
Sprinttikatselmuksen aikana tiimi ja sidosryhmät selvittävät yhteistyössä, mitä sprintissä kehitettiin.
Perustuen tähän tietoon ja mahdollisiin sprintin aikana tuotteen kehitysjonoon tehtyihin muutoksiin osallistujat keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi.
Kehitystiimin esittämän tuotedemon tavoitteena on saada palautetta, edistää keskustelua ja luoda realistinen pohja seuraavan sprintin suunnittelupalaverille.
Sprinttikatselmus rajataan enintään neljään tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa, esimerkiksi kahden viikon sprintille enintään kaksi tuntia.
Sprintin retrospektiivi eli jälkitarkastelu (engl. Sprint Retrospective) antaa scrumtiimille tilaisuuden tarkastella työskentelyään ja tehdä suunnitelman kehitysprosessin parannuksille, jotka toteutetaan seuraavassa sprintissä.
Sprintin retrospektiivi pidetään sprinttikatselmuksen jälkeen ja ennen seuraavan sprintin suunnittelupalaveria. Palaveri rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa.
Kuinka AgileAMK-mallia sovelletaan Moocin tuottamiseen:
Tuotteen kehitysjono
kuvaa tuotekokonaisuuden ja näyttää millaisista osakokonaisuuksista moduuleista ja opintomoduuleista esim. Lähes 0-energiaa –kurssi koostuu
Tuotteen kehitysjonon vaatimusmäärittelyssä voidaan käyttää apuna käyttäjätarinoita (userstory)
Sprintin kehitysjono:
sprintin kehitystiimi määrittelee kunkin sprintin tavoitteet, tehtävät ja tehtävien kestot kussakin sprintinsuunnittelupalaverissa.
Määritellään mikä on valmis; mikä on riittävä taso valmiille
Sprintin tehtävät:
määrittely, suunnittelu, toteutus ja testaus > Sprintin vaatimuksia vastaava valmis osakokonaisuus.