Roadmap Planning

Planning is possible after previous stages have been completed (or at least are in an advanced stage). During planning, we do the following:

Estimation of defined User Stories, UI, and processes
Identify main chunks of work (Epics forming)
Propose a development crew composition
Propose the order of implementation, including milestones set in time

Notes

The roadmap is the first step toward project kickoff, so it’s optimal to prepare it in project management software like Jira, which allows for easy breakdown of large (Epic stories) chunks of work into smaller User Stories and visualizing them on a Gantt chart (The Roadmap).

Project Budget Forecasting

Having completed all stages of the Specification and Design process, we provide forecasts of potential project costs in the form of a Work Breakdown Structure (WBS). This forecast is unique because it is based on:

Our crew’s compounded experience

The empirical velocity measured during other projects

The full-stack development approach

Our estimations consider the Definition of Done (DoD), which defines what it means for the work to be completed. Each project has its own individual DoD, both on the User Story level and on the Sprint level.

Our estimations also include elements of the Scrum process, which we mostly use as a development framework: sprint planning, review meetings, backlog grooming meetings, and retrospectives.

Note

Complex projects cannot be planned with 100% accuracy. Unexpected obstacles, external provider delays, human factors, and changing requirements should be assumed. The budget should allow compensation for these factors. Additionally, time and complexity estimates are unique to our crew. Other companies and teams might use different techniques for estimating.

Appendix

Specification DoD and Acceptance Criteria

The specification is a contract between the Product Owner and the development team and must be clear and readable for both parties.
One goal of the specification is to allow the team to estimate (at a high level) the amount of effort required to deliver the system.
Requirement documentation should be written in the form of User Stories (so that it’s convertible into a Product Backlog) and meet quality standards like INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
The specification contains an architecture description enabling developers to assess the work effort and time necessary to code stories.

Story Definition of Done (DoD)

Publicly available on Teonite standards - Definition of Done.

Reference Projects and Case Studies

Designing the specification for home.pl MFA application
Designing Product Management system and Offers Management system for international eCommerce holding
Creating Wireframes, User Flows, and requirements for a dietary planning solution
Designing user models (roles and responsibilities), User Flows, and UI/UX for the widestreet NPL/UTP loan portfolio trading system