Scrumban.

Mitä Scrumban oikeastaan on

Scrumban säilyttää Kanbanista ja Scrumista ne osat, jotka tekevät työnsä, ja jättää loput pois. Kanbanista se ottaa visuaalisen taulun, sarakepohjaisen työnkulun ja keskeneräisen työn rajat — asiat, jotka tekevät virtauksesta luettavan. Scrumista se ottaa aikarajatun sprintin — sen, joka muuttaa backlogin suunnitelmaksi.

Mitä se jättää väliin: päivittäiset standupit, sprintin siistimispalaverit, tarinapisteseremoniat, retrospektiivit rituaalina. Ne toimivat kymmenelle insinöörille viritetyssä organisaatiossa; ne eivät toimi yhdelle perustajalle, joka yrittää julkaista lauantaina.

Miksi Weft valitsee Scrumbanin

Weft on olemassa, koska useimmat tehtävienhallintatyökalut on muotoiltu jompaankumpaan ääripäähän: joko yksinäiseksi todo-sovellukseksi (loputon lista, ei rytmiä) tai viidenkymmenen hengen Agile-ohjelmistoksi (prosessikuormaa yhden hengen perustajalle). Scrumban istuu täsmälleen keskelle — riittävästi rakennetta pakottamaan viikoittaisen tai kahden viikon julkaisun, muttei niin paljon, että käyttäisit julkaisupäivän sen hallinnointiin.

Miten Weft toteuttaa sen

• Neljä oletussaraketta: Backlog, Todo, Doing, Done. Voit lisätä WIP-rajat sarakkeittain. Kanban Guide pitää keskeneräisen työn rajaamisen eksplisiittistä käytäntöä osana työnkulun määritelmää, jotta uusia kohteita vedetään sisään vain kapasiteetin vapautuessa.
• Yksi aktiivinen sprintti kerrallaan. Sprintit ovat valinnaisia — jätä ne pois, jos puhdas Kanban sopii paremmin. Scrum Guide määrittelee sprintit kiinteän mittaisiksi, enintään kuukauden tapahtumiksi, joissa uusi sprintti alkaa heti edellisen päätyttyä.
• Tehtävillä on prioriteetti, arvio, määräpäivä ja valinnainen kiinnitys sprinttiin. Ei epiikkejä, ei työnkulkuja, ei mukautettuja kenttiä.
• Läpimenoaika alkaa, kun tehtävä siirtyy sarakkeeseen, jolla on tunniste semantic="doing", ja päättyy sarakkeessa "done". Luvut syntyvät rehellisestä käytöstä, eivät tarinapistelaskennasta.

Milloin Scrumban ei ole oikea menetelmä

• Pyörität useita rinnakkaisia Scrum-tiimejä. Scrum Guide rajaa Scrum-tiimin tyypillisesti enintään 10 henkeen ja toteaa, että suuremmat tuotteet pitäisi organisoida useiksi Scrum-tiimeiksi, jotka jakavat yhden tuotetavoitteen ja yhden tuotebacklogin. Ohjelmatason raportointi, jaettu velocity, tiimien väliset riippuvuudet — täysi Scrum Jirassa ansaitsee paikkansa. Nexus Guide on kirjoitettu juuri tähän tilanteeseen: useita Scrum-tiimejä, jotka työskentelevät yhdestä tuotebacklogista, ja lisäkäytäntöjä tiimien välisten riippuvuuksien esiin nostamiseen ja ratkaisemiseen.
• Teet puhdasta tukea tai jatkuvaa ylläpitoa. Sprinttirytmiä ei tarvita — puhdas Kanban tai tikettijärjestelmä sopii paremmin.
• Tarvitset Gantt-kaavioita ja aikajanoja. Scrumban keskittyy sprintteihin, ei riippuvuusgraafeihin.