Hae it-yrityksiä
osaamisalueittain:

Asiakkuudenhallinta CRM BI ja raportointi HR Tuotekehitys ja suunnittelu Toiminnanohjaus ERP Taloushallinto Markkinointi Webkehitys Mobiilikehitys Käyttöliittymäsuunnittelu Tietoturva Verkkokaupparatkaisut Ohjelmistokehitys Integraatiot Pilvipalvelut / SaaS Tekoäly (AI) ja koneoppiminen Lisätty todellisuus ja VR Paikkatieto GIS IoT Microsoft SAP IBM Salesforce Amazon Web Services Javascript React PHP WordPress Drupal
Contribyte » Bloggaus

Sprint Review – Pakollinen paha ja pelkkä demo?

BloggausMonissa yrityksissä valmentaessani olen törmännyt asiaan, joka häiritsee minua suuresti. Yritykset sanovat tekevänsä Agile-kehitystä ja käyttävät Scrum-menetelmää. Käytännössä tämä on kuitenkin tarkoittanut sitä, että heillä on 1–3 viikon iteraatiot (sprintti) ja mahdollisesti Daily standupit käytössä. Puhutaan User Storeista, mutta niiden määritelmä on hieman sekava ja monesti niitä ei edes ehditä tekemään tämän iteraation aikana valmiiksi. Myöskään muita seremonioita, kuten retrospektiiveja tai sprinttien katselmointeja, ei oikeasti hyödynnetä.

Tässä blogissa kerron oman näkemykseni siitä, mitä Sprint Review:n tulisi sisältää.



Sprint Review on paljon muutakin kuin Demo

Sprinttien katselmointi on ehkä yksi aliarvostetuimmista tapahtumista Scrum-käytännöissä, tai sitten se on vain väärin ymmärretty. Monesti tapahtumassa käydään läpi, mitä on saatu aikaiseksi, ja se demotaan – ja kenties retrotaan – mutta eipä sitten paljon muuta olekaan. Usein tämä pidetään myös ainoastaan tiimin sisäisenä tapahtumana.

Katselmoinnissa olisi tarkoitus käydä läpi mitä tiimi on saanut aikaiseksi, eli ”Done-asiat”, mutta myös ”NOT Done -asiat”, eli mitä ei saatu tehtyä. Tämän lisäksi pitäisi vähän tarkastella backlogista esimerkiksi nykyisen ja kenties tulevienkin releasejen sisältöä. Ollaanko budjetissa, aikataulussa, tai onko kenties tarvetta kasvattaa kapasiteettia? Onko olemassa jotain riskejä, joiden vuoksi joudutaan vaikka laittamaan koko kehitys jäihin? Entä ollaanko tässä juuri loppuneessa Sprintissä löydetty tai huomattu jotain, mikä kuuluisi lisätä backlogille? Onko joidenkin asioiden prioriteetti muuttunut? Entäpä riskitasot?

Avaan kohta näitä asioita hieman tarkemmin, jotta niiden tarpeellisuus tulisi esille.

Lähdetään kuitenkin ensin liikkeelle siitä, kenen pitäisi osallistua sprinttien katselmointiin.


Keiden pitäisi osallistua?

Tiimi itse, koska se on vastuussa tuotoksestaan. Tiimillä tosiaan tarkoitan koko tiimiä: tuoteomistaja/Product Owner, Scrum master ja kehitystiimi. Tämän lisäksi olisi hyvä että myös muut sidosryhmät, jotka ovat kiinnostuneita tiimin tuotoksista, tulisivat ainakin silloin tällöin kuulemaan miten työ edistyy. Esimerkiksi pilottiasiakkaat (silloin kun mahdollista), liiketoiminnan edustajat, mahdolliset muut tiimit tai käyttäjät voisivat tässä vaiheessa olla hyödyllisiä. Asiakas (sisäinen tai ulkoinen) on erittäin tärkeässä roolissa, koska hänelle ollaan toimittamassa tilattua työtä. Tämä on se paikka keskustella jatkosta, mihin halutaan mennä.


Budjetti, aikataulu ja sisältö

Sprintti-katselmoinnissa on tarkoitus tarkastella koko sprinttiä, jotta nähdään missä mennään. Erityisen tärkeää olisi keskittyä muun muassa budjettiin, aikatauluihin, riskeihin ja sisältöön.

Budjetti
Ollaanko edelleen budjetissa? Tämä on erityisen tärkeätä silloin kun asiakasprojektit tehdään agile-periaatteilla. Tekeminen ja budjetti pitää olla läpinäkyviä kaikille, koska silloin voidaan nopeasti vaikuttaa asioihin ja tehdä tarpeelliset päätökset. Näin vältytään suuremmilta yllätyksiltä myöhemmin. Uskallan väittää, että asiakas ja toteuttajat ovat tästä yhtä mieltä. Periaatteessa jokaisen sprintin jälkeen on mahdollista tehdä päätös, että lopetetaan kehitys. Jäljellä oleva raha voi myös vaikuttaa prioriteetteihin!

Aikataulu
Ollaanko siinä aikataulussa kuin kuvitellaan? Aikataulu on monesti lukittu johonkin julkaisuun tai muuhun tärkeään päivämäärään, mutta sisältöön voidaan vaikuttaa. Tässä taas tullaan siihen tärkeään asiaan, että asiakaan pitää olla mukana mahdollisimman paljon alusta lähtien, ja että backlogin pitää olla ymmärrettävä ja priorisoitu. Jos aikataulua halutaan nopeuttaa, niin silloin pitää mahdollisesti miettiä, onko tarvetta ottaa lisää resursseja tiimiin. Resurssien lisäys pitää analysoida hyvin sen pohjalta, tuoko se sitä haluttua nopeutta kehitykseen vai ei. Varsinkin kehityksen loppuvaiheessa uudet henkilöt eivät tuota samaa lisäarvoa kuin muuta jäsenet. Tämä vaikuttaa myös budjettiin.

Jokainen sprintti on riskienhallintaa
Tiimille nousseita riskejä pyritään lieventämään tai poistamaan Sprintin aikana. Riskienhallintatoimenpiteitä ovat muun muassa tutkimus-storyt (”spike”), joiden avulla voidaan selvittää lisää vaatimuksen toteutusta tai sen tarpeellisuutta. Oli riskeihin liittyvät toimenpiteet mitkä tahansa, tulokset katsotaan katselmoinnissa yhdessä läpi, ja tehdään päätös sen suhteen, miten jatketaan. Tämä jää valitettavan usein tekemättä.

Sisältö elää – hyvä backlog muuttuu!
Backlog on elävä vaatimuslista, joka pitää olla tärkeysjärjestyksessä eli priorisoitu. Backlogille voi tulla koska vain uusia juttuja, mutta yhtä lailla sieltä voidaan koska vain ottaa asioita pois. Katselmoinnin aikana, varsinkin Demo-osiosta, voi asiakkaalle tulla ahaa-elämyksiä oikeasta toteutuksesta verrattuna siihen, mitä paperille (ppt mockup) oltiin kirjattu vaatimukseksi. Näin ollen katselmoinnit ovat ehkä tärkeimpiä palautesilmukoita niin asiakkaalle kuin tiimille. Palautteen perusteella pyritään vähentämään tarpeettoman teko ja keskittymään siihen oleelliseen, joka tuottaa arvoa.


Kuusi vinkkiä hyvään Sprint Review -tilaisuuteen!

Valmistaudu tähänkin tapahtumaan kunnolla. Kurinalaisuus on tärkeintä, mutta monesti myös se vaikein asia yrityksissä, jossa vanha kulttuuri tappaa uuden tekemisen mallia.

Tässä muutamia nostoja seuraavaan Sprintti-katselmukseen:

1. Huolehdi, että backlog on päivitetty ja priorisoitu ennen tapahtumaa
2. Tilaa kahvit ja ”perjantaipullat”
3. Pitäkää tapahtuma mahdollisimman vapaana, mutta hyvin fasilitoituna (tämä on tärkeää!)
4. Varsinkin jos haluat mukaan ydintiimin ulkopuolisia, muista lähettää kutsut tapahtumaan hyvissä ajoin! Pyri samaan asiakkaita ja käyttäjäkuntaa mukaan.
5. Älä kontrolloi liikaa – ”Vapauta” tiimi keskustelemaan suoraan asiakkaan tai loppukäyttäjien kanssa. Näin kehittäjät saavat paremman käsityksen mahdollisesti toteutustavasta.
6. Käytä aikaa siihen, että tiedätte mihin haluatte mennä!


Yhteenveto

Sprint Review:n tulisi olla muutakin kuin demo. Tämä on se arvokas hetki, jolloin voidaan katsoa mitä ollaan saatu aikaiseksi ja mihin halutaan seuraavaksi mennä. Onko tullut jotain uutta tietoa tarpeista, jotka vaikuttavat sisältöön tai koko kehitykseen. Tehdään päätökset yhdessä ja läpinäkyvästi. Jaetaan tietoa!

Pinterest
Contribyte logo

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Liiketoimintaprosessi

Tietohallinto

Erikoisosaaminen

Ketterät menetelmät
Ohjelmistokehitys

Toimialakokemus

IT

Tarjonnan tyyppi

Konsultointi
Koulutus

Omat tagit

Agile
demo
sprint reviw

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi

ite wikin yrityshaku »

It- ja ohjelmistoalan työpaikat

Kaikki it-alan työpaikat »

Premium-asiakkaiden viimeisimmät referenssit

ite wikin referenssihaku »

Tapahtumat & webinaarit

Kaikki it-alan tapahtumat »

Premium-asiakkaiden viimeisimmät bloggaukset

ite wikin julkaisuhaku »

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä
Loka 30
Suomalainen innovaatiotoimisto on kansainvälisesti palkittu ja kehittää digitaalisia palveluita maailman suurimmille firmoille - Näin Hellonin palvelumuotoiluprosessi eroaa it-toimittajien mallista
Hellon on kerännyt useita kansainvälisiä digitaalisen designin palkintoja
Loka 11
Digipalvelulain saavutettavuusvaatimuksia aletaan soveltaa uusiin verkkopalveluihin 28.6.2025 - Näin asetus vaikuttaa digitaalisten palveluiden kehityshankkeisiin
Digipalvelulaki sisältää kolme keskeistä vaatimusta saavutettavuudesta
Loka 10
Digitalisaatiokentän syksyn tapahtumia 2024
Ite wikin tapahtumasivu koostaa yhteen digitalisaatiokentän tapahtumat ja webinaarit
Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia