Sprintin suunnittelun agendamalli insinööritiimeille

Miksi sprintit ylikuormittuvat

Sprintin suunnittelussa on yksi rakenteellinen epäonnistuminen, jota mallit eivät estä: tiimit valitsevat sprintin backlogin ennen kuin kukaan tarkistaa kapasiteetin. Tuloksena on sprintti, joka näytti saavutettavalta valkotaululla ja romahtaa keskiviikkoon mennessä, kun kaksi insinööriä on poissa puolet viikosta, yhden tiketin laajuus kolminkertaistuu ja kolmella kohdalla oli mainitsematon riippuvuus palveluun, jota alustatiimi kirjoittaa uusiksi.

Korjaus on yksinkertainen ja lähes koskaan tehty: sitoudu kapasiteettiin ennen sitoutumista työhön. Alla oleva malli avataan kapasiteettikatsauksella juuri tästä syystä.

Agenda (kopioi ja liitä)

Kesto: 2 tuntia 2 viikon sprintille; 1 tunti 1 viikon sprintille
Muoto: fasilitoitu, backlog näkyvissä koko tiimille

Osa 1 — Sprintin tavoite (10 min)

Yksi lause: miltä onnistunut sprintti näyttää ulkopuolelta?
Tavoitteen tulisi olla riittävän konkreettinen, että kuka tahansa tiimin jäsen voisi sprintin lopussa arvioida, osuttiinko siihen
Hylkää tavoitteet, jotka ovat vain lista tikettejä ("saa valmiiksi auth-refaktorointi ja laskutussivu") — se on backlog, ei tavoite

Osa 2 — Kapasiteettikatsaus (15 min)

Listaa jokainen tiimin jäsen nimeltä
Kunkin osalta: suunniteltu PTO, päivystysvuoro, toistuvat palaverit, tunnetut ulkoiset sitoumukset
Ilmaise kapasiteetti käytettävissä olevina story pointeina tai päivinä — ei henkilömääränä
Tämä luku on katto; älä valitse enempää työtä kuin se tukee

Osa 3 — Backlogin valinta (45 min)

Käy läpi korkeimman prioriteetin kohdat jalostetusta backlogista
Kunkin ehdokkaan osalta: onko tiimillä tarpeeksi sen aloittamiseen, vai onko avoimia kysymyksiä, joihin tarvitaan vastaus ennen sprintin alkua? Avoimet kysymykset kuuluvat jalostusjonoon, ei sprinttiin
Lopeta valitseminen, kun osut 80 %:iin kapasiteetista; jäljelle jäävä 20 % imee ylivuodon ja suunnittelemattoman työn

Osa 4 — Hyväksymiskriteerit (20 min)

Jokaiselle valitulle kohdalle: esitä kriteeri, joka tekee siitä valmiin
Jos tiimi ei osaa esittää kriteeriä 60 sekunnissa, tiketti ei ole tarpeeksi jalostettu — siirrä se takaisin backlogiin
Kirjoita se tikettiin nyt, huoneessa; älä luota siihen, että "lisätään myöhemmin"

Osa 5 — Riskit ja riippuvuudet (15 min)

Mikä voisi estää sprintin tavoitteen toteutumisen ja mitä tiimi ei hallitse?
Nimeä riippuvuuden omistaja; nosta se esiin nyt, kun on aikaa ratkaista se ennen sprintin puoltaväliä
Ratkaisemattomille riippuvuuksille nimetään tiimistä vastuuhenkilö, joka seuraa niitä

Päätös (15 min)

Vahvista, että sprintin tavoite on yhä validi valitun työn valossa
Nimeä sprintin yhteenvedon muistiinpanija tai vahvista automaattisen raportin asetukset
Vahvista seuraava suunnittelupäivä

Mitä useimmat sprintin suunnittelumallit sivuuttavat

Suosituimmat sprintin suunnittelumallit keskittyvät backlogin jalostukseen ja määritelmään valmiista. Molemmat ovat tärkeitä. Kumpikaan ei puutu siihen suunnitteluvirheeseen, joka tuottaa eniten sprinttiepäonnistumisia: työn valitsemiseen tarkistamatta käytettävyyttä.

Viiden insinöörin tiimillä täydellä kapasiteetilla on noin 200 story pointia käytettävissä per 2 viikon sprintti. Viiden hengen tiimillä, jossa kaksi insinööriä on PTO:lla, yksi päivystysvuorossa ja yksi kolmen päivän offsitella, on kenties 110. Jos valitset 180 pointtia toisessa sprintissä, olet jo epäonnistunut. Valintavaihe on se, missä ylisitoutuminen tapahtuu, ja kapasiteetin on tultava sitä ennen.

Toinen aukko on hyväksymiskriteerit. Tiimit etenevät nopeasti suunnittelun läpi ja aikovat kirjoittaa kriteerit myöhemmin. Myöhemmin ei tapahdu samalla tarkkuustasolla. Se, joka olisi kirjoittanut täsmällisen kriteerin huoneessa, kirjoittaa jotain epämääräisempää muistista seuraavana päivänä, tai ei kirjoita sitä lainkaan. Kesken sprintin syntyvät erimielisyydet siitä, mitä "valmis" tarkoittaa, ovat lähes aina jäljitettävissä suunnittelussa ohitettuihin hyväksymiskriteereihin.

Näiden aukkojen kertautuva hinta — ylikuormitetut sprintit, keskeltä sprinttiä tehdyt löydöt, uudelleen käsitellyt määritelmät — näkyy selvästi, kun laskee sen yhteen: Palaverivero.

Miksi sprintin suunnittelumuistiinpanot ovat vaikeampia kuin miltä näyttävät

Sprintin suunnittelu tuottaa enemmän tietoa kuin lähes mikään muu toistuva palaveri: sprintin tavoitteen, kapasiteettiluvut, kohta kohdalta -valintaperustelut, hyväksymiskriteerit per tiketti, riippuvuuksien omistajat, riskikohdat. Hyödyllisen yhteenvedon kirjoittaminen vaatii tämän kaiken tallentamisen muodossa, joka on hyödyllinen kolme päivää myöhemmin, kun joku kysyy "miksi me leikattiin tuo kohta pois?"

Pavleur luo sprintin suunnitteluraportin automaattisesti palaverin lopussa. Se tallentaa sprintin tavoitteen, valitun backlogin perusteluineen, hyväksymiskriteerit palaverissa esitetyssä muodossa ja riippuvuuksien omistajat nimettyinä. Jos joku jakoi näytöllä backlogin tai kapasiteettitaulukon, tuo visuaali on mukana raportissa keskustelun rinnalla — kontekstia, jonka pelkät äänityökalut kuten Otter tai Fireflies ohittaisivat kokonaan. Kuka tahansa, joka liittyi myöhässä tai tarvitsee tarkistaa päätöksen kesken sprintin, saa täyden tallenteen. Vertailu siitä, miten tämä eroaa pelkistä äänityökaluista: Pavleur vs. vaihtoehdot.

Kesken sprintin tapahtuvan suunnitelmamuutoksen hoitaminen

Sprintin suunnitelma on sitoumus, ei sopimus. Kun jokin kesken sprintin aidosti mitätöi suunnitelman — tuotantohäiriö, kriittinen riippuvuus, joka estää kolme tikettiä, prioriteettimuutos johdolta — oikea reaktio on nopea uudelleensuunnittelupalaveri, ei hiljainen laajuuden pudotus. Uudelleensuunnittelupalaveri kestää 20 minuuttia ja tuottaa päivitetyn sprintin tavoitteen, joka heijastaa todellisuutta. Vaihtoehto on sprintti, joka epäonnistuu paperilla mutta jota on epävirallisesti säädetty tavoilla, joita kukaan ei kirjannut ylös, mikä tekee retrospektiivistä vaikeamman ja velositeettiluvuista merkityksettömiä.

Rakenna tapa nimenomaiseen uudelleensuunnitteluun. Käytä samaa rakennetta: päivitetty kapasiteetti, tarkistettu valinta, uudelleen esitetty tavoite. Se vie paljon vähemmän aikaa kuin se sekaannus, jonka se estää.