Tämä ohje toteuttaa Scrum-oppaan toimintamallin GitHub Projectsissa: Product Backlogiin kirjoitetaan User Storyt, Sprint Planningissa valitaan Sprintin tavoite ja Storyt, ja kehittäjät pilkkovat valitut Storyt taskeiksi. Sprintin aikana taskien etenemistä seurataan tehtävätaululla. Esimerkkinä käytetään oppaan oppilasrekisteriä.

Suositeltu rakenne: yksi GitHub Project koko tuotteelle, yksi issue jokaista User Storya varten, Sprint-niminen Iteration-kenttä Sprinttien ajoittamiseen ja Storyjen alle luotavat sub-issuet taskeille. Backlog, Sprintin Storyt ja Task Board ovat saman projektin eri näkymiä.

Ohje käyttää nykyistä GitHub Projectsia ja käyttöliittymän englanninkielisiä nimiä. Kenttien nimet ja suodattimet kannattaa kirjoittaa täsmälleen tässä esitetyssä muodossa. Valikkojen sijainti voi muuttua GitHubin päivityksissä.

User Storyn ja taskin välinen suhde rakennetaan sub-issueilla. Sprinttiin kuuluminen ilmoitetaan erikseen kummankin Sprint-kentässä. Näin Sprintissä voi olla useita Storyja, joista jokaisella on omat taskinsa.

GitHub Projects on muokattava työkalu, joten seuraavat kentät ja käytännöt ovat tämän oppaan valintoja. Scrum ei edellytä tiettyä työkalua, User Story -muotoa tai Story Pointien käyttöä.

1. Luo tuotteen koodille repository, esimerkiksi oppilasrekisteri.
2. Avaa välilehtiProjects ja valitse New project. Valitse tyhjä Table-projekti, anna nimeksi Oppilasrekisteri – Scrum ja valitse Create project.

Kirjoita projektin READMEhen esimerkiksi seuraavat tiedot:

## 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.

## Yhteiset käytännöt
- Product Owner: [nimi]
- Scrum Master: [nimi]
- Kehittäjät: [nimet]
- Sprintin pituus: 2 viikkoa
- Definition of Done: [linkki repositoryn docs/definition-of-done.md-tiedostoon]
- Sprint 1:n tavoite ja muistiot: [linkki docs/sprints/sprint-1.md-tiedostoon]

Tiimi voi kirjata Definition of Doneen esimerkiksi koodikatselmoinnin, läpäisevät testit, käyttöoikeuksien tarkistuksen, toimivan kokonaisuuden ja tarvittavan dokumentaation päivityksen. Storykohtaiset hyväksymiskriteerit kirjoitetaan lisäksi kunkin Storyn kuvaukseen.

Anna tiimille projektin muokkausoikeudet sekä tarvittavat oikeudet repositoryyn. Projektin käyttöoikeus ja repositoryn käyttöoikeus ovat erillisiä: tarkista molemmat. Sub-issueiden liittämiseen tarvitaan repositoryssa vähintään Triage-oikeus; tavalliseen koodin kehittämiseen tiimillä on yleensä Write-oikeus.

Avaa projektin Table-näkymä. Taulukon oikean reunan +-painikkeesta voit lisätä kentän: valitse Add field, klikkaa Create project field, valitse kenttätyyppi ja tallenna. Lisää kentät

• Sprint , tyyppi=Iteration, valitse aloituspäivä ja Sprintin kesto
• Backlog order , tyyppi=Number
• Story Points , tyyppi=Number

Olemassa olevia kenttiä muokataan projektin Settings-sivulla.

Status-kentän arvot

Avaa Settings → Status, nimeä tarvittaessa valmiit vaihtoehdot uudelleen ja lisää puuttuvat. Pidä nimet samoina kaikissa näkymissä. Halutessasi aseta Todo oletusarvoksi uusille kohteille.

Tässä ohjeessa Storyt ja taskit erotellaan repositoryn labeleilla. Tämä toimintatapa ei edellytä organisaatiokohtaisten Issue type -asetusten määrittämistä.

1. Avaa repositoryn Issues → Labels → New label. Luo labelit user-story ja task.
2. Valitse Issues → New issue. Anna Storylle kuvaava otsikko, esimerkiksi Opiskelijan tietojen ylläpito.
3. Kirjoita kuvaukseen käyttäjän tarve ja hyväksymiskriteerit alla olevan mallin mukaan.
4. Valitse label user-story ja lisää issue Projects-kohdassa projektiin Oppilasrekisteri – Scrum. Luo issue Create- tai Submit new issue -painikkeella.
5. Avaa projektin Table-näkymä. Aseta Storyn Status = Todo ja Backlog order = 10. Kehittäjät arvioivat Storyn koon, esimerkiksi Story points = 5. Jätä Sprint tyhjäksi.
6. Luo samalla tavalla muut Storyt ja anna niille järjestysluvut 20, 30, 40 ja 50. Product Owner vastaa järjestyksestä; kehittäjät vastaavat työmääräarvioista.

Kopioitava Storyn kuvaus

## User Story
Ylläpitäjänä haluan lisätä ja päivittää opiskelijan tietoja,
jotta voin pitää oppilasrekisterin ajan tasalla.

## Hyväksymiskriteerit
- [ ] Ylläpitäjä voi lisätä opiskelijan sovituilla pakollisilla tiedoilla.
- [ ] Ylläpitäjä voi muokata olemassa olevan opiskelijan tietoja.
- [ ] Virheellisiä tietoja ei tallenneta, ja käyttäjä saa selkeän virheilmoituksen.
- [ ] Muu kuin ylläpitäjä ei voi lisätä tai muuttaa opiskelijatietoja.
- [ ] Tallennetut muutokset näkyvät opiskelijan tiedoissa.

## Tarkennukset
Tallennettavat tiedot ja tarkistussäännöt: [linkki tai kuvaus]
Käyttöliittymäluonnos: [linkki]

## Valmistuminen
Hyväksymiskriteerit ja tuotteen yhteinen Definition of Done täyttyvät.

Luo lisäksi Storyt Kurssille ilmoittautuminen, Arvosanan tallentaminen, Omien suoritusten tarkastelu ja Opiskelutodistuksen muodostaminen. Kirjoita kuhunkin oma rooli, toiminto, hyöty ja testattavat hyväksymiskriteerit.

Backlogin tarkennus: lisää tarvittavat yksityiskohdat ja arviot ennen Storyn valintaa Sprinttiin. Jos Story on liian suuri yhteen Sprinttiin, jaa se pienemmiksi käyttäjälle arvoa tuottaviksi Storyiksi. Story Pointit ovat suhteellisia arvioita, eivät tunteja.

Jos issue on jo olemassa, lisää se projektin alareunan Add item -toiminnolla etsimällä repository ja issue tai liittämällä issuen URL. Pelkkä uusi otsikko projektin rivillä voi luoda draft issuen. Käytä Storylle varsinaista repositoryn issuea; muunna mahdollinen luonnos Convert to issue -toiminnolla.

Valitse tavoite ja Storyt Sprint Planningissa

1. Scrum Team keskustelee Sprintin arvosta ja muodostaa Sprint Goalin: Oppilasrekisteri mahdollistaa uuden opiskelijan lisäämisen ja hänen osallistumisensa opetukseen.
2. Kirjaa tavoite repositoryn docs/sprints/sprint-1.md-tiedostoon. Lisää päivämäärät, linkit valittuihin Storyihin ja linkki Definition of Doneen. Linkitä muistio projektin READMEhen.
3. Kehittäjät valitsevat tavoitetta tukevat Storyt kapasiteettinsa perusteella. Esimerkissä valitaan opiskelijan tietojen ylläpito ja kurssille ilmoittautuminen.
4. Aseta molempien Storyjen Sprint = Sprint 1 projektin taulukossa. Muut kolme Storya jäävät ilman Sprint-arvoa odottamaan myöhempää suunnittelua.
5. Pilko valitut Storyt seuraavan kohdan mukaisesti taskeiksi. Tavoite, Storyt ja taskit muodostavat Sprint Backlogin.

Yksi Project riittää kaikille Sprinteille. Uutta projektia ei tarvitse perustaa joka Sprintille. Tässä mallissa Sprintit toteutetaan Iteration-kentällä; samoja Sprinttejä ei tarvitse ylläpitää lisäksi Milestoneina.

1. Avaa Sprint 1:een valittu Opiskelijan tietojen ylläpito -issue.
2. Valitse kuvauksen alapuolelta Create sub-issue. Kirjoita otsikko, esimerkiksi Toteuta opiskelijatietojen tallennus ja päivitys.
3. Kirjoita taskin konkreettinen sisältö ja valmistumisen ehdot. Lisää label task, sama Project ja sovittu Assignee. Valitse Create.
4. Aseta taskille projektissa Sprint = Sprint 1 ja Status = Todo. Jätä Story points ja Backlog order tyhjiksi.
5. Toista kaikille taskeille. Voit käyttää Create more sub-issues -valintaa. Jos taski on jo olemassa, käytä Storyn sub-issue-valikon Add existing issue -toimintoa.

Tarkista jokaisesta taskista kolme asiaa: se on oikean Storyn sub-issue, se on lisätty samaan Projectiin ja sillä on sama Sprint-arvo kuin Storylla. Parent-suhde, projektijäsenyys ja Sprint-arvo ovat erillisiä tietoja; tarkista ne myös Storyn Sprintiä vaihdettaessa.

Story 1: opiskelijan tietojen ylläpito

• Määrittele opiskelijan tiedot ja tarkistussäännöt.
• Luo tai päivitä opiskelijatietojen tietokantataulu.
• Toteuta opiskelijan lisäys- ja muokkauslomake.
• Toteuta tietojen tallennus ja päivittäminen palvelimella.
• Rajaa toiminto ylläpitäjälle.
• Kirjoita testit lisäykselle, päivitykselle ja virheellisille tiedoille.

Story 2: kurssille ilmoittautuminen

• Näytä opiskelijalle kurssit, joille voi ilmoittautua.
• Lisää ilmoittautumistoiminto käyttöliittymään.
• Tallenna ilmoittautuminen tietokantaan.
• Estä saman opiskelijan ilmoittautuminen samalle kurssille kahdesti.
• Näytä vahvistus onnistuneesta ilmoittautumisesta.
• Testaa onnistuva ilmoittautuminen ja virhetilanteet.

Kopioitava taskin kuvaus

## Tehtävä
Toteuta opiskelijatietojen tallennus ja päivittäminen palvelimella.

## Valmistumisen ehdot
- [ ] Pakolliset tiedot ja tietojen muoto tarkistetaan palvelimella.
- [ ] Uusi opiskelija voidaan tallentaa ja olemassa oleva päivittää.
- [ ] Virheellinen syöte ei muuta tietokannan tietoja.
- [ ] Tallennusta ja päivitystä koskevat testit menevät läpi.
- [ ] Muutokset on katselmoitu ja yhdistetty yhteiseen koodiin.

## Riippuvuudet ja tarkennukset
Tarvitsee opiskelijatietojen tietokantataulun: [linkki taskiin]

Markdownin - [ ] -tarkistuslista sopii taskin sisäisiin ehtoihin. Task Boardilla seurattava taski tehdään kuitenkin omaksi sub-issueksi, jotta sillä on oma tila ja tekijä. Älä anna taskille lisäksi user-story-labelia.

Luo projektin yläreunan New view -painikkeella seuraavat näkymät ja nimeä niiden välilehdet. Aseta näkymän ulkoasu View-valikosta ja kirjoita suodatin hakukenttään. Kun muutat suodatinta tai asetuksia, tallenna näkymän muutokset Save-toiminnolla.

Product Backlog -näkymän asetukset

Näytä kentät Title, Labels, Status, Backlog order, Story points ja Sprint. Aseta Sort → Backlog order nousevaksi. Product Owner muuttaa järjestyslukuja tarpeen mukaan. Sprint-kenttä näyttää, mitkä Storyt on jo valittu Sprinttiin.

Sprintin Storyt -näkymän asetukset

Näytä Title, Status, Sprint, Story points ja Sub-issue progress. Esimerkiksi 4/6 suljettua taskia kertoo taskien tilanteesta. Se ei vielä osoita Storyn hyväksymiskriteerien tai Definition of Donen täyttymistä.

Sprintin Task Board -näkymän asetukset

1. Aseta ulkoasuksi Board ja View → Column field → Status.
2. Aseta View → Group by → Parent issue. Storyt muodostavat vaakasuuntaiset ryhmät ja niiden taskit näkyvät Status-sarakkeissa.
3. Valitse View → Fields ja näytä korteissa ainakin Assignees, Parent issue ja Sprint.
4. Näytä kaikki sovitut Status-sarakkeet, myös Done ja Needs info. Tallenna asetukset.

Jos Parent issue ei löydy valikosta, ota kenttä ensin näkyviin Table-näkymän Hidden fields -listasta. Taski, jolla ei ole parentia, pitää liittää oikeaan Storyyn.

Ennen Sprintin alkamista ja aiempien Sprinttien tarkastelu

@current tarkoittaa päivämäärien perusteella nykyistä aikajaksoa. Jos Sprint 1 ei ole vielä alkanut, käytä suunnittelussa täsmällistä suodatinta is:issue label:task sprint:"Sprint 1". Story-näkymässä vaihda labeliksi user-story. Myös päättynyttä Sprinttiä tarkastellaan sen nimellä; nykyisen Sprintin näkymä siirtyy aikataulun mukaan seuraavaan jaksoon.

Näkymä ei siirrä tai kopioi issueita. Se näyttää suodattimen mukaisen osan saman projektin kohteista. Task Boardin label:task-suodatus pitää Story-kortit poissa taskien joukosta. Älä lisää is:open-suodatinta Sprintin näkymiin, jos haluat nähdä myös suljetut Done-taskit ja Storyt.

1. Kehittäjä ottaa sovitun taskin työn alle, asettaa itsensä Assignees-kenttään ja siirtää kortin Todo → In progress. Kortin siirtäminen muuttaa taskin Status-arvoa.
2. Kirjaa kysymykset ja ratkaisut taskin kommentteihin. Esteen kohdalla käytä Needs info -tilaa ja kerro, mitä tarvitaan työn jatkamiseksi.
3. Daily Scrumissa kehittäjät tarkastelevat Task Boardia suhteessa Sprint Goaliin, sopivat seuraavista töistä ja päivittävät toteutussuunnitelmaa.
4. Tee koodimuutoksesta pull request ja viittaa siinä taskiin, esimerkiksi Refs #42. Siirrä taski Ready for test -tilaan, kun se on valmis sovittuun katselmointiin ja testaukseen.
5. Kun taskin valmistumisen ehdot täyttyvät, sulje taski valmiina ja varmista Status = Done. Päivitä parent-Storyn tila erikseen vastaamaan kokonaisuuden tilannetta.

Pull requestin automaattinen sulkeminen: esimerkiksi Closes #42 voi sulkea taskin, kun PR yhdistetään repositoryn oletushaaraan. Käytä sitä vain, jos yhdistäminen tarkoittaa tiimin käytännössä taskin valmistumista. Jos testaus jatkuu yhdistämisen jälkeen, käytä Refs #42 ja sulje taski myöhemmin. Taskin PR:ssä ei pidä sulkea parent-Storya, ellei koko Story samalla täytä kaikkia valmistumisen ehtoja.

Tarkista projektin automaatiot

Avaa projektin … → Workflows. GitHubin oletusautomaatio voi asettaa suljetun issuen Status-arvoksi Done. Tarkista, että se käyttää tässä oppaassa määriteltyä Done-arvoa. Voit käyttää myös uusien kohteiden Todo-tilan asettamista. Muokkaa valittua työnkulkua Edit-toiminnolla ja tallenna Save and turn on workflow.

Pelkkä kortin siirtäminen Doneen ei välttämättä sulje issuea: siihen tarvitaan erillinen automaatio tai issuen sulkeminen käsin. Tässä ohjeessa taski suljetaan, kun se on valmis, ja sulkeminen päivittää tilan Doneksi. Näin myös Storyn Sub-issue progress päivittyy suljettujen taskien perusteella.

Automaatiot eivät tarkista hyväksymiskriteerejä tai Definition of Donea. Älä määritä kaikkia Storyja automaattisesti seuraavaan Sprinttiin.

Milloin User Story on valmis?

Storyn voi sulkea valmiina ja siirtää Doneen vasta, kun kaikki tarvittavat taskit ovat valmiit, Storyn hyväksymiskriteerit on todennettu ja kokonaisuus täyttää yhteisen Definition of Donen. Esimerkiksi valmis tietokantataulu ilman toimivaa ja testattua käyttöliittymää ei tee opiskelijatietojen Storya valmiiksi.

Pelkkä taskien 100 % -edistyminen ei riitä. Kehittäjät tarkistavat toimivan kokonaisuuden; Storyn sulkemista ei jätetä taskilaskurin varaan. Valmistuneen Storyn ja sen taskien Sprint-arvot jätetään paikoilleen, jotta toteutuneen Sprintin työt voidaan löytää myöhemmin.

Sprint Review

Esittele toimiva Increment Product Ownerille ja sidosryhmille. Tarkastelkaa tulosta suhteessa Sprint Goaliin ja Product Goaliin. Kirjaa palaute Sprintin muistioon ja lisää uudet tarpeet Product Backlogiin. Review ei ole valmistumisen hyväksymisportti: Definition of Donen täyttävä työ voi valmistua ja olla toimitettavissa jo Sprintin aikana.

Keskeneräisen Storyn palauttaminen Backlogiin

1. Kirjaa Sprintin muistioon Storyn linkki, alkuperäinen pistearvio, valmistunut työ ja jäljelle jäänyt työ. Tämä säilyttää tiedon Sprintin alkuperäisestä valinnasta myös kenttiä muutettaessa.
2. Pidä keskeneräinen Story avoimena. Tyhjennä sen Sprint-kenttä, jotta se näkyy jälleen Odottavat Storyt -näkymässä.
3. Tyhjennä myös sen keskeneräisten taskien Sprint-arvot. Säilytä niiden todellinen Status; jo aloitettua työtä ei tarvitse merkitä aloittamattomaksi.
4. Jätä valmiit taskit suljetuiksi ja niiden Sprint-arvoksi päättynyt Sprint. Ne säilyvät saman Storyn sub-issueina.
5. Product Owner järjestää Storyn uudelleen. Jos kehittäjät valitsevat sen myöhemmin Sprint Planningissa, aseta uusi Sprint Storylle ja vain sen jäljellä oleville taskeille.

Esimerkki: kurssille ilmoittautumisen Story jää kesken Sprint 1:ssä. Tietokantataski valmistui, mutta kaksoisilmoittautumisen esto ja testit puuttuvat. Story palaa odottavaan Backlogiin. Jos se valitaan Sprint 2:een, nämä keskeneräiset taskit saavat Sprint 2 -arvon; valmis tietokantataski säilyttää Sprint 1 -arvon.

GitHubissa tässä mallissa Sprintin päättyminen tarkoittaa aikajakson päättymistä ja tiimin tekemää tarkastelua. Projektia ei suljeta eikä Iterationia poisteta Sprintin lopuksi.

Sprint Retrospective ja seuraavan Sprintin suunnittelu

Kirjaa Sprintin muistioon, mikä työskentelyssä toimi ja mitä parannetaan. Sopikaa konkreettisesta parannuksesta ja ottakaa se tarvittaessa seuraavan Sprintin toteutussuunnitelmaan. Seuraava Sprint alkaa uudella Sprint Goalilla ja kehittäjien tekemällä Storyjen valinnalla.

Story Pointien seuranta

Laske Sprintin valmistuneiksi pisteiksi vain kokonaan valmistuneiden Storyjen pisteet. Jos viiden pisteen Story jää kesken, Sprint 1:een ei kirjata siitä osapisteitä. Älä summaa taskien pisteitä Storyn pisteiden lisäksi. Historiasta voidaan arvioida kapasiteettia, mutta pisteet eivät mittaa yksittäisen kehittäjän suoritusta tai tuotettua arvoa.

Säilytä Sprintin muistiossa valitut ja valmistuneet Storyt sekä toteutuneet pisteet. Pelkkä nykyisten kenttien suodatus ei säilytä alkuperäistä Sprint-suunnitelmaa, jos keskeneräisten Storyjen Sprint-arvoa muutetaan.