Zebranie wymagań to prawdopodobnie jedna z najważniejszych czynności w projekcie, jakiekolwiek błędy i nieprecyzyjne wymagania są później najkosztowniejsze finansowo jaki czasowo do poprawy. Metodyka Scrum definiuje wymagania na bazie user stories dzielących się na konkretne zadania do wykonania, epici które są dużymi zadaniami na definicje których składa się wiele mniejszych wymagań, nie zawsze finalnie zdefiniowanych oraz backlogi które są tworem na user stories i epici.

User stories

• pisane przez product ownera oraz SME’s (Subject Mater Experts)
• estymowane przez team, przypisywana liczba user stories
• opisane zostaje umieszczone w zbiorze (product backlogu) w odpowiedniej kolejności. najważniejsze na górze 
• definiowane do momentu gdy wszyscy uznają za zrozumiałe, gotowe do implementacji, przedstawiające
• pełen obraz zadania
• kiedy przeznaczone do realizacji, zespół zobowiązuje się je wykonać w ramach sprintu
• wykonywane i testowane przez zespół podczas implementacji sprintu
• finalnie akceptowane przez product ownera jako wykonane na podstawie kryteriów akceptacji, prezentowane na demo

User stories są podstawową formą zadań wykonywanych przez zespół podczas sprintów. Każde user story powinno być jedną kompletną funkcjonalnością która będzie z punktu widzenia product ownera SMART (specific, measured, agreed, responsible, time framed). Dobrze napisane user stories powinny opisywać tylko jedną interakcje systemu z użytkownikiem  użytkownik czytając takie user story powinien szybko zorientować na jaki jest temat, na jedną interakcję może się składać kilka use casów.
Przykładowa konstrukcja user story:
<kto> chce/potrzebuje <opis wykonywanej czynności>  po to by/ponieważ <powód>
Mając tak opisane user story zespół szybko wie o co chodzi w danej funkcjonalności, jest w stanie dostarczyć estymatę czasu potrzebnego na wykonanie tego user story. Oczywiście początki estymacji mogą być trudne, natomiast kiedy zespół przepracuje kilak sprintów razem będzie w stanie dawać bardzo dobre i zbliżone do rzeczywistości estymaty. W opisie nie może zabraknąć kryterium akceptacji danego user story czyli informacji co będzie czynnikiem determinującym prawidłowy odbiór prac od zespołu podczas demo. Dodatkowo przydadzą się tutaj przykłady/testy akceptacyjne które pozwolą product ownerowi odebrać user story, jeśli on sam nie jest w stanie sam odebrać produktu powinien korzystac z pomocy członków zespołu.