Product Owner
Määrittelee Product Goalin ja järjestää Product Backlogin kohteet tärkeysjärjestykseen.
Scrum on iteratiivinen (tuotetta kehitetään kierros kierrokselta) ja inkrementaalinen (tuotteeseen lisätään toimivia osia kierros kierrokselta) Agile-viitekehys monimutkaiseen tuotekehitykseen. Siinä Scrum Team työskentelee yhdessä yhteisen tavoitteen saavuttamiseksi ja tuottaa käyttökelpoisen osan tuotteesta säännöllisin väliajoin.
Scrumista on hyötyä erityisesti silloin, kun kaikkia vaatimuksia tai parasta toteutustapaa ei voida tietää etukäteen. Työ jaetaan lyhyisiin Sprinteihin, joiden aikana syntyy tarkasteltava osa tuotteesta. Säännöllisen palautteen avulla virheelliset oletukset ja muuttuneet tarpeet voidaan havaita ajoissa, Product Backlogia voidaan mukauttaa ja tärkein työ tehdä ensin. Näin vähennetään riskiä, että pitkän kehitystyön jälkeen valmistuu asiakkaan tarpeisiin huonosti sopiva tuote.
Scrum perustuu läpinäkyvyyteen, tarkasteluun ja mukauttamiseen. Scrum Team tarkastelee työnsä tuloksia säännöllisesti ja muuttaa suunnitelmiaan uuden tiedon perusteella. Tiimi on itseohjautuva: sen jäsenet päättävät yhdessä, kuka tekee mitäkin, milloin ja miten.
Tarvitaanko Scrumissa vaatimusmäärittelyä? Ohjelmistokehityksessä voidaan tunnistaa seuraavat keskeiset tehtäväalueet: määrittely, suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito. Eri ohjelmistokehityksen prosessimalleissa nämä tehtävät järjestetään ja toistetaan eri tavoin.
Scrum ei edellytä, että ennen kehityksen aloittamista kirjoitetaan kattava ja lopullinen vaatimusmäärittely. Scrumissa vaatimusmäärittelyyn liittyvää työtä tehdään jatkuvasti osana tuotteen kehittämistä.
Product Backlog toimii jatkuvasti tarkentuvana kuvauksena siitä, mitä tuotteelta tarvitaan. Se ei kuitenkaan automaattisesti korvaa kaikkea muuta vaatimusdokumentaatiota.
Product Backlog -kohteita voidaan täydentää esimerkiksi:
Scrum ei määrää, mitä kaavioita tehdään tai milloin. Tiimi voi käyttää UML-kaavioita vaatimusten tarkentamiseen ja ratkaisun suunnitteluun silloin, kun niistä on hyötyä.
Erillinen ja laajempi vaatimusmäärittely voi olla tarpeen esimerkiksi sopimusten, viranomaisvaatimusten tai monimutkaisen toimintaympäristön vuoksi.
Scrumissa olennaista ei siis ole se, onko olemassa yksi erillinen vaatimusmäärittelydokumentti, vaan se, että tuotteen tarvittavat vaatimukset ja tavoitteet ovat riittävän hyvin ymmärrettyjä, jotta tiimi pystyy suunnittelemaan, toteuttamaan ja testaamaan toimivan tuotteen.
Dokumentaatiota tehdään sen verran kuin tuotteen ymmärtäminen, toteuttaminen, testaaminen ja hyväksyminen edellyttävät.
Scrum Teamiin kuuluu kolme vastuualuetta:
Scrum Teamissa ei ole erillisiä alitiimejä tai hierarkioita. Kaikki jäsenet keskittyvät yhdessä Product Goalin saavuttamiseen.
Product Owner vastaa tuotteen arvon maksimoimisesta ja Product Backlogin tehokkaasta hallinnasta. Hän määrittelee Product Goalin, huolehtii Product Backlog -kohteiden selkeydestä ja järjestyksestä sekä varmistaa, että Product Backlog on kaikkien saatavilla ja ymmärrettävissä.
Product Owner toimii usein asiakkaan, työn tilaajan tai liiketoiminnan näkökulman edustajana Scrum Teamissa. Hän tekee kuitenkin tuotetta koskevat priorisointipäätökset ja vastaa tuotteen arvon maksimoimisesta.
Product Owner voi antaa osan työstä muiden tehtäväksi, mutta vastuu säilyy hänellä. Product Owner on yksi henkilö, ei ryhmä. Sidosryhmät voivat vaikuttaa Product Backlogiin keskustelemalla Product Ownerin kanssa.
Scrum Master vastaa siitä, että Scrum ymmärretään ja sitä käytetään Scrum Guiden mukaisesti. Hän auttaa Scrum Teamia ja organisaatiota ymmärtämään Scrumin teoriaa ja käytäntöjä.
Scrum Master auttaa tiimiä parantamaan toimintatapojaan, edistää työn etenemistä haittaavien esteiden poistamista ja varmistaa, että Scrum-tapahtumat järjestetään tarkoituksenmukaisesti. Hän ei ole tiimin esimies, vaan palveleva johtaja ja valmentaja, joka tukee tiimin itseohjautuvuutta ja tuloksellisuutta.
Kehittäjät ovat Scrum Teamin jäseniä, jotka rakentavat jokaisen Sprintin aikana käyttökelpoisen Incrementin eli aiempaa tuotetta täydentävän toimivan lisäyksen. Ryhmään voi kuulua esimerkiksi ohjelmoijia, testaajia, suunnittelijoita ja muiden tarvittavien alojen osaajia.
Kehittäjät laativat Sprint Backlogin, huolehtivat laadusta Definition of Donen mukaisesti, mukauttavat suunnitelmaansa päivittäin Sprint Goalin saavuttamiseksi ja kantavat yhdessä vastuun työn tuloksista.
Scrum Team työskentelee yhteisen Product Goalin saavuttamiseksi. Roolit täydentävät toisiaan, eikä Scrum Master toimi Product Ownerin ja kehittäjien välisenä viestinviejänä.
Määrittelee Product Goalin ja järjestää Product Backlogin kohteet tärkeysjärjestykseen.
Suunnittelevat työn, rakentavat tuotteen ja vastaavat laadusta Definition of Donen mukaisesti.
Tukee koko Scrum Teamia, auttaa Scrumin käytössä, valmentaa itseohjautuvuuteen ja edistää esteiden poistamista.
Scrumissa on kolme keskeistä artefaktia eli työn ja sen etenemisen näkyväksi tekevää kokonaisuutta:
Artefaktit tekevät työn, tavoitteet ja syntyvän arvon näkyviksi.
Product Backlog on järjestetty ja jatkuvasti tarkentuva luettelo tuotteen kehittämiseksi tarvittavista töistä. Scrum Team valitsee tuotetta koskevan työnsä Product Backlogista. Product Owner vastaa Product Backlogin järjestämisestä siten, että tärkeimmät ja eniten arvoa tuottavat kohteet ovat selkeästi nähtävissä.
Product Backlogissa kuvataan ennen kaikkea, mitä tuotteelta tarvitaan ja millaista hyötyä muutoksella tavoitellaan. Se ei kuvaa sitä, miten kehittäjät toteuttavat ratkaisun. Kohteet kuvataan ensisijaisesti asiakkaan tai loppukäyttäjän näkökulmasta. Ne voivat olla uusia ominaisuuksia, parannuksia, virheenkorjauksia tai muuta tuotteen kehittämiseksi tarvittavaa työtä.
Product Backlog -kohteita tarkennetaan työn aikana pilkkomalla ja kuvaamalla niitä yksityiskohtaisemmin. Ominaisuuksia voidaan kuvata esimerkiksi User Storyina, mutta Scrum ei edellytä tiettyä kuvaustapaa.
Product Goal kirjataan näkyväksi Product Backlogin yhteyteen. Se voidaan esittää esimerkiksi projektinhallintatyökalun tavoitekentässä, Product Backlogin alussa tai projektisuunnitelmassa, johon Backlogista viitataan. Scrum ei määrää käytettävää työkalua tai dokumenttimuotoa. Tärkeintä on, että Product Goal on Scrum Teamin ja sidosryhmien tiedossa ja että Product Backlogin kohteet tukevat sen saavuttamista.
User Story on lyhyt kuvaus käyttäjälle tuotettavasta arvosta. Se auttaa keskustelemaan tarpeesta käyttäjän näkökulmasta ja voidaan kirjoittaa muodossa: [Roolina] haluan [toiminnon], jotta voin [saavuttaa hyödyn].
(Esimerkiksi: Opiskelijana haluan ilmoittautua kurssille, jotta voin osallistua kurssille)
Hyvän User Storyn ominaisuuksia ovat:
Sprint Planningissa Scrum Team keskustelee ensin siitä, miksi Sprint on arvokas, ja muodostaa keskustelun perusteella Sprint Goalin. Tämän jälkeen kehittäjät valitsevat Product Backlogista Sprint Goalia tukevat kohteet, jotka he arvioivat saavansa valmiiksi Sprintin aikana. Product Owner auttaa ymmärtämään kohteiden arvon ja tärkeyden, mutta kehittäjät arvioivat Sprintiin mahtuvan työn määrän.
Kehittäjät suunnittelevat, miten valitut kohteet toteutetaan, ja voivat pilkkoa User Storyt selkeiksi ja riittävän pieniksi tehtäviksi eli taskeiksi. Sprint Goal, valitut Product Backlog -kohteet ja niiden toteuttamista koskeva suunnitelma muodostavat yhdessä Sprint Backlogin. Kehittäjät päivittävät Sprint Backlogia Sprintin aikana sitä mukaa, kun työ etenee ja siitä opitaan lisää.
User Story kuvaa, mitä käyttäjä tarvitsee ja mitä arvoa hänelle halutaan tuottaa. Se ei kuitenkaan kerro kehittäjille yksityiskohtaisesti, miten ominaisuus toteutetaan. Siksi kehittäjät pilkkovat jokaisen Sprintiin valitun User Storyn konkreettisiksi taskeiksi.
Taski voi olla esimerkiksi tarvittavan tietokantamuutoksen, käyttöliittymän tai testien toteuttaminen. Taskien pitäisi olla niin selkeitä ja pieniä, että niiden tekeminen ja eteneminen on helppo ymmärtää. Niitä voidaan näyttää tehtävä- tai Kanban-taululla, jotta työn tila näkyy koko Scrum Teamille.
Increment tarkoittaa tuotteen käyttökelpoista lisäystä. Sprintissä valmistunut työ yhdistetään aikaisemmin toteutettuun tuotteeseen siten, että kokonaisuus toimii ja täyttää Definition of Donen. Increment voi sisältää esimerkiksi uuden ominaisuuden, virheenkorjauksen tai olemassa olevan toiminnon parannuksen.
Jokainen Increment vie tuotetta lähemmäksi Product Goalia. Sprintin aikana voidaan valmistaa useita Incrementtejä, ja niitä voidaan toimittaa käyttäjille jo ennen Sprint Reviewta. Sprint Review ei siis ole julkaisun hyväksymisportti, vaan tilaisuus tarkastella tuloksia ja päättää seuraavista muutoksista yhdessä sidosryhmien kanssa.
Definition of Done on Scrum Teamin yhteinen kuvaus siitä, milloin työ täyttää tuotteelta vaadittavat laatuvaatimukset ja voidaan laskea osaksi Incrementiä. Jos organisaatiolla on yhteinen Definition of Done, Scrum Teamin on noudatettava sitä vähimmäisvaatimuksena. Muussa tapauksessa Scrum Team määrittelee tuotteelle sopivan Definition of Donen.
Tiimi voi sopia esimerkiksi, että Product Backlog -kohde on valmis, kun:
Scrum ei määrää tuotteen dokumentoinnin muotoa. Tiimi voi ylläpitää esimerkiksi arkkitehtuurin ja rajapintojen kuvauksia sekä asennus- ja ylläpito-ohjeita. Kun toteutus muuttaa näitä tietoja, tarvittavat dokumentit päivitetään osana samaa työtä. Näin dokumentaatio kuvaa toimivaa tuotetta ja tukee sen ylläpitoa ja jatkokehitystä myös myöhempien Sprinttien aikana.
Definition of Done koskee yhteisesti kaikkea valmistuvaa työtä. Sen lisäksi yksittäisellä User Storylla voi olla omat hyväksymiskriteerinsä, jotka kuvaavat juuri kyseiseltä ominaisuudelta vaadittavan toiminnan.
Tässä esimerkissä oppilasrekisterin kehitystarve etenee Product Goalista konkreettisiksi Product Backlog -kohteiksi, User Storyiksi ja lopulta kehittäjien taskeiksi.
Oppilasrekisterin Product Goal: Oppilaitoksella on ajantasainen ja luotettava oppilasrekisteri, jossa opiskelijat voivat hoitaa keskeiset opiskeluun liittyvät asiat ja henkilökunta ylläpitää opiskelija- ja suoritustietoja.
Sprint 1:n Sprint Goal: Oppilasrekisteri mahdollistaa uuden opiskelijan lisäämisen ja hänen osallistumisensa opetukseen.
Sprinttiin valitaan seuraavat Sprint Goalia tukevat User Storyt:
Esimerkissä kehittäjät arvioivat, että nämä kaksi User Storya voidaan saada valmiiksi Sprintin aikana. Muut User Storyt jäävät Product Backlogiin odottamaan myöhempää Sprint Planningia.
User Story 1: Ylläpitäjänä haluan lisätä ja päivittää opiskelijan tietoja, jotta voin pitää oppilasrekisterin ajan tasalla.
User Story 2: Opiskelijana haluan ilmoittautua kurssille, jotta voin osallistua kurssille.
Scrum etenee Sprinteissä. Jokaisen Sprintin aikana järjestetään Scrum-tapahtumia, joissa tiimi suunnittelee työtä, seuraa sen etenemistä, tarkastelee tuloksia ja kehittää toimintatapojaan.
Sprint on enintään kuukauden mittainen jakso, jonka aikana Scrum Team työskentelee Sprint Goalin saavuttamiseksi ja tuottaa arvoa. Uusi Sprint alkaa välittömästi edellisen päätyttyä. Sprintin aikana laatutavoitetta ei heikennetä eikä Sprint Goalia vaarantavia muutoksia tehdä, mutta työn laajuutta voidaan tarkentaa Product Ownerin kanssa uuden tiedon perusteella.
Sprint Planning käynnistää Sprintin. Scrum Team keskustelee ensin siitä, miksi Sprint on arvokas, ja muodostaa Sprint Goalin. Sen jälkeen kehittäjät valitsevat Product Backlogista tavoitetta tukevat kohteet ja suunnittelevat, miten työ toteutetaan. Tavoitetta ja valittavia kohteita voidaan tarkentaa keskustelun aikana rinnakkain.
Product Owner varmistaa, että osallistujat ovat valmiita keskustelemaan tärkeimmistä Product Backlog -kohteista ja auttaa ymmärtämään niiden arvon. Kehittäjät arvioivat, kuinka paljon työtä Sprintiin voidaan valita, ja päättävät, miten siitä rakennetaan Definition of Donen täyttävä Increment. Sprint Planningin tuloksena syntyy Sprint Backlog.
Daily Scrum on kehittäjille tarkoitettu 15 minuutin päivittäinen tapahtuma. Sen tarkoituksena on tarkastella etenemistä kohti Sprint Goalia ja mukauttaa Sprint Backlogia tarpeen mukaan. Kehittäjät valitsevat itse tarkoitukseen sopivan toteutustavan.
Keskustelussa voidaan käsitellä esimerkiksi edellisen päivän edistymistä, seuraavia tehtäviä ja työn esteitä. Scrum Master tai Product Owner osallistuu kehittäjänä silloin, kun hän työskentelee aktiivisesti Sprint Backlogin kohteiden parissa.
Sprint Review järjestetään Sprintin lopulla Sprintin tulosten tarkastelemiseksi ja seuraavista muutoksista päättämiseksi. Scrum Team esittelee keskeisille sidosryhmille, mitä Sprintissä saavutettiin, ja keskustelee heidän kanssaan tuotteen tilanteesta sekä toimintaympäristön muutoksista.
Sprint Reviewssa esitellään Sprintin aikana valmistuneet User Storyt ja niiden toteutukset. Product Owner ja sidosryhmät tarkastelevat tuloksia ja antavat niistä palautetta. Jos toteutus ei täytä sovittuja hyväksymiskriteerejä tai Definition of Donea, sitä ei katsota valmistuneeksi eikä osaksi Incrementiä. Keskeneräinen User Story palautetaan Product Backlogiin, jossa Product Owner arvioi sen tärkeyden uudelleen. Se voidaan valita jonkin myöhemmän Sprintin Sprint Backlogiin.
Sprint Review on yhteinen työskentelytilaisuus, ei pelkkä esitys. Keskustelun perusteella Product Backlogia voidaan mukauttaa uusia mahdollisuuksia ja tarpeita vastaavaksi.
Sprint Retrospectivessa Scrum Team tarkastelee edellistä Sprintiä ihmisten, vuorovaikutuksen, prosessien, työkalujen ja Definition of Donen näkökulmasta. Tiimi tunnistaa hyvin toimineet asiat, ongelmat ja niiden mahdolliset syyt.
Scrum Team valitsee hyödyllisimmät parannukset työn laadun ja tehokkuuden lisäämiseksi. Kiireellisimmät parannukset voidaan lisätä seuraavan Sprintin Sprint Backlogiin. Sprint Retrospective päättää Sprintin, minkä jälkeen seuraava Sprint käynnistyy Sprint Planningilla.
Sprint Reviewssa tarkastellaan Sprintin tuloksia, tuotteen tilannetta ja etenemistä kohti Product Goalia. Sprint Retrospectivessa puolestaan tarkastellaan Scrum Teamin työskentelyä. Reviewssa saatu palaute voi auttaa tiimiä myös Retrospectivessa, kun se pohtii, miten työn laatua ja toimintatapoja voidaan parantaa.
Alla oleva animaatio havainnollistaa Scrum-prosessin kokonaisuutta. Käynnistä animaatio painikkeella tai tutustu prosessiin vaihe vaiheelta tekstin avulla.
Valmiina aloittamaan: Product Backlog sisältää tuotteen tunnetut kehitystarpeet.
Product Backlog muodostetaan ja järjestetään. Product Backlogiin kirjataan tuotteen kehittämiseksi tarvittavat, sillä hetkellä tunnetut työt. Ominaisuuksia voidaan kuvata User Storyina, mutta listalla voi olla myös esimerkiksi virheenkorjauksia ja teknisiä parannuksia. Kaikkea ei tarvitse määritellä lopullisesti heti, sillä Product Backlog tarkentuu koko tuotteen elinkaaren ajan.
Product Owner vastaa siitä, että Product Backlog on järjestetty. Tärkeimmät ja eniten arvoa tuottavat kohteet sijoitetaan yleensä listan alkuun, jotta ne voidaan käsitellä ensimmäisinä.
User Storyjen työmäärä arvioidaan. User Story voidaan pisteyttää heti sen lisäämisen yhteydessä tai myöhemmin Product Backlogin tarkennuksessa. Story Pointit ovat suhteellinen arvio työn määrästä, monimutkaisuudesta ja epävarmuudesta: esimerkiksi kahdeksan pisteen Story arvioidaan selvästi suuremmaksi kuin kolmen pisteen Story. Pisteet eivät tarkoita työtunteja.
Kun tiimille kertyy kokemusta toteutuneista Sprinteistä, aiemmissa Sprinteissä valmistuneiden pisteiden määrä auttaa arvioimaan tiimin kapasiteettia. Sen perusteella kehittäjät voivat ennakoida, kuinka paljon työtä seuraavaan Sprintiin on realistista valita.
Sprint Planningissa määritellään tavoite ja valitaan Sprintin työ. Scrum Team keskustelee siitä, miksi Sprint on arvokas, ja muodostaa Sprint Goalin. Sen jälkeen kehittäjät valitsevat Product Backlogin tärkeimmistä kohteista Sprint Goalia tukevat User Storyt, jotka he arvioivat saavansa valmiiksi Sprintin aikana. Tavoitetta ja valintaa voidaan tarkentaa keskustelun aikana. Sprint Goal, valitut User Storyt ja toteutussuunnitelma muodostavat yhdessä Sprint Backlogin.
Kehittäjät pilkkovat User Storyt konkreettisiksi taskeiksi. Taski voidaan sopia tietyn kehittäjän vastuulle jo suunnittelussa, tai kehittäjä voi ottaa seuraavan sopivan taskin työn alle Sprintin aikana. Scrumissa kehittäjät päättävät itse työnjaosta ja voivat muuttaa suunnitelmaa työn edetessä.
Työtä seurataan Sprintin Task Boardilla. Kukin taski näkyy taululla korttina. Korttia siirretään työn etenemisen mukaan sarakkeesta toiseen, jolloin koko tiimi näkee Sprintin tilanteen. Daily Scrumissa kehittäjät tarkastelevat etenemistä kohti Sprint Goalia ja päivittävät suunnitelmaansa tarvittaessa.
Sprintin tulos tarkastetaan. Taski voidaan siirtää valmiiseen tilaan, kun se täyttää tiimin sopimat valmistumisen ehdot. User Story on valmis vasta, kun kaikki sen toteuttamiseen tarvittavat taskit on tehty ja kokonaisuus täyttää hyväksymiskriteerit sekä Definition of Donen. Product Owner ja sidosryhmät tarkastelevat Sprint Reviewssa syntynyttä Incrementiä ja antavat palautetta.
Jos User Story ei valmistu kokonaan, sitä ei lasketa osaksi Incrementiä. Keskeneräinen työ palautuu Product Backlogiin, jossa Product Owner järjestää sen uudelleen. Sitä ei siirretä automaattisesti seuraavaan Sprintiin, vaan Scrum Team voi valita sen uudelleen tulevassa Sprint Planningissa.
Seuraava Sprint alkaa. Sprint Retrospectivessa Scrum Team sopii toimintatapojensa parannuksista. Tämän jälkeen alkaa seuraavan Sprintin Sprint Planning, ja sama sykli toistuu päivittyneen Product Backlogin pohjalta.
Useissa projektinhallintatyökaluissa User Storyt esitetään omina riveinään ja niihin kuuluvat taskit kulkevat sarakkeissa työvaiheen mukaan. Sarakkeiden nimet ja määrä vaihtelevat työkaluittain, ja kehittäjät voivat yleensä muokata niitä projektin tarpeisiin. Task Board voi sisältää esimerkiksi seuraavat sarakkeet:
| Sarake | Mitä sarake tarkoittaa? |
|---|---|
| New / To do | Taski kuuluu Sprintiin, mutta sen tekemistä ei ole vielä aloitettu. |
| In progress | Taski on parhaillaan työn alla. Kortista tulisi näkyä, kuka siitä vastaa. |
| Ready for test | Toteutus on tekijän mielestä valmis tarkastettavaksi tai testattavaksi. |
| Closed / Done | Taski on tarkastettu ja täyttää sille sovitut valmistumisen ehdot. |
| Needs info | Työ ei voi edetä, koska taski vaatii lisätietoa tai jonkin esteen poistamista. |
Sarakkeiden nimet ja määrä eivät ole Scrumin määräämiä. Tiimi voi käyttää esimerkiksi erillisiä koodikatselmoinnin tai testauksen sarakkeita, jos ne tekevät todellisen työnkulun näkyvämmäksi. Tärkeintä on, että kaikki ymmärtävät tilat samalla tavalla ja että Done tarkoittaa aidosti valmista työtä.
Scrumissa tuotteen edistymistä tarkastellaan jokaisen Sprintin jälkeen suhteessa Product Goaliin. Sprint Reviewssa tarkastellaan valmistunutta Incrementiä, päivitetään Product Backlogia ja arvioidaan jäljellä olevaa työtä. Tuotteen valmistumisprosentti voidaan laskea esimerkiksi valmistuneiden ja jäljellä olevien Story Pointien perusteella, mutta luku on vain senhetkinen arvio, koska Product Backlogin sisältö ja arvioitu työmäärä voivat muuttua.
Edistymisen havainnollistamiseen voidaan käyttää erilaisia kaavioita. Sprintin Burn-down Chart näyttää, kuinka paljon Sprintiin valittua työtä on jäljellä. Koko tuotteen tai julkaisun etenemiseen Burn-up Chart on usein selkeämpi, koska se näyttää erikseen valmistuneen työn ja Product Backlogin arvioidun kokonaismäärän. Kaaviot ovat valinnaisia seurantatyökaluja eivätkä Scrumin edellyttämiä artefakteja.
Jäljellä oleva työ ei vähene aina tasaisesti. Esimerkissä eteneminen hidastuu Sprintin keskivaiheilla, mutta kaikki Sprintiin valittu työ valmistuu lopulta.
Valmistuneen työn määrä kasvaa jokaisessa Sprintissä. Kokonaismäärän portaat näyttävät, että Product Backlogin arvioitu laajuus muuttuu uuden tiedon myötä.
Kaavioiden luvut ovat kuvitteellisia. Story Pointit kuvaavat suhteellista työmäärää, eivät suoraan tuotteen arvoa tai tarkkaa valmistumisprosenttia.