Scrumban.

Hvad Scrumban egentlig er

Scrumban beholder de dele af Kanban og Scrum, der gør sig fortjent til deres plads, og dropper resten. Fra Kanban tager det den visuelle tavle, den kolonnebaserede arbejdsgang og grænser for igangværende arbejde — det, der gør flowet læseligt. Fra Scrum tager det den tidsafgrænsede sprint — det, der gør en backlog til en plan.

Det, det springer over: daglige standups, grooming-møder, story point-ceremonier, retrospektiver som ritual. De virker for ti udviklere i en indkørt organisation; de virker ikke for én stifter, der prøver at levere en lørdag.

Hvorfor Weft vælger Scrumban

Weft findes, fordi de fleste opgavestyringer er formet til en af to yderligheder: enten en enkeltstående todo-app (uendelig liste, ingen kadence) eller en Agile-pakke til halvtreds personer (procesoverhead for en stifter på én). Scrumban sidder præcis i midten — nok struktur til at tvinge en ugentlig eller fjortendagsleverance, ikke så meget, at du bruger leveringsdagen på at administrere den.

Sådan implementerer Weft det

• Fire kolonner som standard: Backlog, Todo, Doing, Done. Du kan sætte WIP-grænser pr. kolonne. Kanban Guide behandler en eksplicit politik for at begrænse igangværende arbejde som en del af definitionen af en arbejdsgang, så nye elementer kun trækkes ind, når der bliver kapacitet.
• Én aktiv sprint ad gangen. Sprints er valgfrie — spring dem over, hvis ren Kanban passer. Scrum Guide definerer sprints som begivenheder af fast længde på én måned eller mindre, hvor en ny sprint starter umiddelbart efter afslutningen af den forrige.
• Opgaver har prioritet, estimat, frist og en valgfri tilknytning til en sprint. Ingen epics, ingen workflows, ingen brugerdefinerede felter.
• Gennemløbstiden starter, når en opgave flyttes til en kolonne med semantic="doing" og slutter i "done". Tallene kommer af ærlig brug, ikke af story point-aritmetik.

Når Scrumban ikke er den rigtige metode

• I driver flere samtidige Scrum-teams. Scrum Guide sætter et Scrum-team til typisk 10 personer eller færre og siger, at større produkter bør organiseres i flere Scrum-teams, der deler ét produktmål og én produkt-backlog. Rapportering på programniveau, fælles velocity, afhængigheder på tværs af teams — fuld Scrum i Jira tjener sin plads. Nexus Guide er skrevet til den situation: flere Scrum-teams, der arbejder ud fra én enkelt produkt-backlog, med ekstra praksisser til at synliggøre og løse afhængigheder på tværs af teams.
• I laver ren support / kontinuerlig drift. Ingen sprintkadence nødvendig — ren Kanban eller et ticketsystem passer bedre.
• I har brug for Gantt-diagrammer og tidslinjer. Scrumban er sprint-fokuseret, ikke fokuseret på afhængighedsgrafer.