Spis user stories i epiców w porządku od najważniejszego do najmniej ważnego, opisane przez product ownera tworzy product backlog. Stanem optymalnym wydaje się mieć user stories na około 3-4 sprinty, w tym około połowę wyestymowaną przez zespół. Mając tak przygotowany product backlog dajemy zespołowi poczucie kontroli nad tym co mamy oraz pokazujemy członkom zespołu wizję w stronę której zmierzamy.

Cykl życia product product backlogu:

• Właściciel produktu tworzy wymagania (epiki i user stories) z których chciałby aby składał się produkt.
• Następuje priorytetyzacja backlogu.
• Backlog jest przestawiany na spotkaniu planistycznym sprintu, gdzie zespół decyduje ile pracy jest  w stanie wykonać
• Elementy backlogu przyjmowane są do wykonania.
• Elementy wykonane usuwa się z backlogu produktu, w kolejnym sprincie ponowienie procesu

Spis user stories i epiców które są wybrane przez zespół i wykonywane podczas sprintu tworzą mniejszy zbiór zwany sprint baclogiem. Sprint backlog powinien pozostawać niezmienny zgodnie z założeniami scruma, wyjątkiem są sytuacje kiedy product owner chce dodać coś na szybko do wykonania przez zespół, może to dodać jedynie kosztem usunięcia starego user story o podobnym rozmiarze.