- kazdy web ma nadefinovany svuj jeden projekt v jire, k nemu je prirazen projektak/projektaci - existuji dalsi projekty, ktere nejsou vazany primo na web, ale vazou s k funcnosti/pouzitelnosti, napr pro devare maintanance and operations - existuje vzdy jeden sprint, vyjimkou je, pokud dojde k zalozeni specialniho projektu, pro ktery byl dedikovan cely tym, tento tym ma pak svuj vlastni sprint, board a … - pokud projekt skonci, je potreba ho uzvarit, aby se jiz nedal pouzivat a „neprekazel“

- tasky

1. produktak prirazuje tasky do svyho projektu
2. nastavuje jim typ → bug, frontend feature, backend feature, config
3. nastavuje jim prioritu → nizka, stredni, vysoka, kriticka(nejvyssi)
4. jasne definuje zadani, doplni o odkazy pripadne screenshoty, grafiku apod., tasky bez popisku nebudou akceptovany, popisek != title

1. tasky se podle typu a priority rozdeluji do backlogu(medium/low priority bug, f/b feature, medium/low priority config) a do helpdesk kanbanu(high/crit bugy, high/crit config)

- flow tasku

1. tasky, ktere je potreba zpracovat nasledujici sprint, je potreba zadat do jiry nejpozdeji utery vecer
2. pred poradou vyvoje(streda dopoledne, utery odpoledne) dojde frontend/backend oddelenim na ohodnoceni tasku storypointy
3. pokud dojde k vytvoreni tasku ve stredu a je potreba ho zpracovat, ?mel by projit schvalenim? a nasledne je ohodnocen, to samy plati i pro tasky pridavane do aktualniho sprintu, task by mel byt vymenen 1:1 s jinym taskem/tasky(podle SP)
4. na porade vyvoje dojde

- k alokaci lidi, tz. rozdeleni na vyvoj a helpdesk, vytvareni dedikovanych tymu pro specialni projekty

	- k serazeni backlogu, muze dojit k prirazenim tasku na konkretni lidi(ale nemusi!)
- po porade vyvoje se zacne novy sprint, do sprintu se nahazi veci ze serazeneho backlogu, priradi se lidi(ale nemusi)

- meetings

1. grooming party → 2h backend/frontend zvlast
2. porada vyvoje → 1,5h produktaci + vedeni
3. sprint meeting → 1h backend/frontend dohromady