Scrumban.

Hva Scrumban egentlig er

Scrumban beholder de delene av Kanban og Scrum som gjør nytte for seg, og dropper resten. Fra Kanban tar det den visuelle tavlen, den kolonnebaserte arbeidsflyten og grenser for pågående arbeid — tingene som gjør flyten lesbar. Fra Scrum tar det den tidsavgrensede sprinten — tingen som gjør en backlog om til en plan.

Det det hopper over: daglige standups, sprint-grooming-møter, story-point-seremonier, retrospektiver som ritual. De fungerer for ti utviklere i en veltrimmet organisasjon; de fungerer ikke for én gründer som prøver å levere på en lørdag.

Hvorfor Weft velger Scrumban

Weft finnes fordi de fleste oppgavestyrere er formet for én av to ytterpunkter: enten en ensom gjøremålsapp (uendelig liste, ingen rytme) eller en Agile-suite for femti personer (prosessoverhead for en gründer på én). Scrumban sitter nøyaktig i midten — nok struktur til å tvinge fram en ukentlig eller fjortendaglig levering, ikke så mye at du bruker leveringsdagen på å administrere den.

Hvordan Weft implementerer det

• Fire standardkolonner: Backlog, Todo, Doing, Done. Du kan legge til WIP-grenser per kolonne. Kanban Guide regner en eksplisitt policy for å begrense pågående arbeid som en del av definisjonen av en arbeidsflyt, slik at nye elementer bare trekkes inn når kapasitet frigjøres.
• Én aktiv sprint om gangen. Sprinter er valgfrie — hopp over dem hvis ren Kanban passer. Scrum Guide definerer sprinter som hendelser med fast lengde på én måned eller kortere, der en ny sprint starter umiddelbart etter at den forrige er avsluttet.
• Oppgaver har prioritet, estimat, frist og en valgfri sprint-tilknytning. Ingen epics, ingen arbeidsflyter, ingen egendefinerte felt.
• Syklustiden starter når en oppgave flyttes til en kolonne med semantic="doing" og slutter i "done". Tallene kommer fra ærlig bruk, ikke story-point-regning.

Når Scrumban ikke er riktig metode

• Du kjører flere samtidige Scrum-team. Scrum Guide setter et Scrum-team til typisk 10 personer eller færre, og sier at større produkter bør organiseres i flere Scrum-team som deler ett produktmål og én produkt-backlog. Rapportering på programnivå, delt velocity, avhengigheter på tvers av team — full Scrum i Jira gjør seg fortjent. Nexus Guide er skrevet for den situasjonen: flere Scrum-team som jobber fra én enkelt produkt-backlog, med ekstra praksiser for å synliggjøre og løse avhengigheter på tvers av team.
• Du driver ren support / kontinuerlig drift. Ingen sprintrytme nødvendig — ren Kanban eller et saksbehandlingssystem passer bedre.
• Du trenger Gantt-diagrammer og tidslinjer. Scrumban er sprintfokusert, ikke fokusert på avhengighetsgrafer.