Zgodnie ze standardami metodyk zwinnych w pierwszej fazie najistotniejszą rolę pełni Project Menager (PM), będący niejako „właścicielem” produktu/projektu oraz osobą odpowiedzialną za jego wytworzenie. Zbiera on wymagania wszystkich Interesariuszy (klientów końcowych, właścicieli, sponsorów, itp.), a następnie (wykorzystując swoją wiedzę i doświadczenie) przekłada je na poszczególne funkcje budowanego rozwiązania.
Tak powstałą listę/specyfikację dzieli na grupy powiązanych funkcji, zwane Epikami. W efekcie powstaje Product/Project Backlog (Rejestr Produktu/Projektu), czyli „zestaw” prac do wykonania, podzielonych na konkretne etapy.
Jako, że niniejszy projekt badawczy nie jest standardowym przedsięwzięciem dewelopersko-wdrożeniowym lecz projektem badawczo-rozwojowym faza ta wymagała modyfikacji. Praca Product Owner’a została w tym wypadku zastąpiona pracą warsztatową Kierownika Działu Badawczego we współpracy z pozostałymi pracownikami tego działu oraz Product Managerem.
W kolejnej fazie, Dział Badawczy Smartech IT przedstawił efekty swoich prac zespołowi programistycznemu, w celu oszacowania złożoności i czasu pracy. Zespół działu oprogramowania składa się z doświadczonych osób i ekspertów o zróżnicowanych obszarowo kompetencjach (m.in. architekci systemów informatycznych, inżynierowie ds. wirtualizacji, administratorzy systemów serwerowych, programiści i in.), tak by możliwe było dokonanie jak najdokładniejszej estymacji projektu.
W wyniku analizy zespołu, poszczególnym Epikom i User Stories (Historyjki Użytkowników, czyli funkcje) zostają nadane konkretne Estymaty. Są to z reguły liczby, które uwzględniają nie tylko czas trwania pracy, ale także jej złożoność i wszelkie dodatkowe konsekwencje (jak choćby technologie, czy udział stron trzecich).
Następną fazą jest podzielenie całego Backlogu Produktu na mniejsze oraz skończone części, do wykonania w krótkim okresie czasu. Te zakresy prac to Sprint Backlogs (Rejestry Sprintu), a okres wykonywania prac programistycznych w jednej iteracji (cyklu) to Sprint (Przebieg). Każdy Sprint zaczyna się Planowaniem (Sprint Planning), podczas którego wybierane są zadania o najwyższym priorytecie, a Zespół zobowiązuje się je wykonać w określonym czasie (w scrumie z reguły od tygodnia 12 do trzech).
Sprint kończy się tzw. Sprint Review lub Demo (Przegląd Przebiegu), podczas którego Zespół prezentuje wynik swoich prac w postaci zamkniętej funkcjonalności, a Kierownik Działu Badawczego decyduje o zgodności tego co zobaczył z postawionymi wcześniej wymogami i założeniami. W ten sposób dzielone i realizowane są poszczególne etapy projektu. Opisana faza odbywa się cyklicznie podczas trwania projektu aż do jego zakończenia.
