Kanban

Epic => Feature => Story
En issue = arbeid for en person (deles ikke)
Plukk den øverste issuen som er tildelt deg eller som du har kompetanse til å gjøre.
Kun en issue av gangen i arbeid
Når man flytter en issue eller går for dagen så kommenter issuen
Når en oppgave flyttes til test skal den være testbar av kunde, helst med URL til hva som skal testes.
Hold den tekniske spesifikasjonen i oppgaven.
Ta opp med prosjektleder oppgaver som har vært på on-hold mer enn en uke
Ta opp med prosjektleder oppgaver som har vært på qa / test mer enn en uke
QA = Ønsker at kollega tar en teknisk sjekk
Test = Ønsker at kunde eller kollega sjekker
Status på en issue skal alltid være riktig.

Oppstart av issue

Forstå kunden
Hva er det i dette for kunden? Hvorfor vil kunden ha dette og hva skal det brukes til?
Snakk med prosjektleder
Snakk evt med kunden.
Har de bestilt og akseptert rolls-roys eller lada?
Hvem skal bruke den? Krav til poleringsgrad (forskjell på backend og frontend)
Forstå oppgaven før utvikling påbegynnes
Er den spesifisert godt nok? Oppstart møte?
Har den et estimat?
Kost nytte? Hva ville denne oppgaven være verdt for meg om jeg var kunden?

Planlegg Arkitektur? Søk etter ferdige moduler? Høre om kollegaer har gjort noe tilsvarende? Best practice design? Design guidelines?

Start utvikling Hold deg til oppgaven. Ikke finn på ekstra funksjonalitet som ikke er beskrevet eller avtalt.

Ulike nivåer Funksjonell beskrivelse Wireframes Swagger / API Databasemodell Tekniske beskrivelse