Project Management

During the execution of projects, Mobix has a major cycle of Project Management like below:


Our Project Manager (PM) needs to organize his tasks by the following:

Tasks Management

We use Jira for Project Management.

We separate the project vision in three perspectives: Roadmap, Backlog and Active Sprint.


Here is where we put the main vision of the project. Using metrics of Software Engineering and Project Design, we separate the main features in Modules. Each module has a set of features. Each feature is mapped using the Backlog section.

Checklist for Roadmap Implementation

Your roadmap should look like this:


Here we dive deep into our feature details. Each one needs to attend the following fields:

Note: Main Flow lists a sequence of steps needed which evolves all the feature objective. The Alternative Flow also do the same job, however focusing on behaviors that gravitates around the business rules. We use those two fields for Acceptance Criteria.

Active Sprint

The Active Sprint sets all features that the team planned to do in our Sprint Planning cerimony.

Our Active Sprint takes up to 10 business days.


At Mobix we use Scrum Methodology to achieve the goals. Divided by Sprints, we set up expectations with the Team and with the Client to plan and tackle possible challenges that we might need to achieve the goals. As Scrum is an Agile Methodology applied on Software Engineering process, a few events are made with the Team:

Sprint Planning

The Team receives the deliverables provided by the PM of the project. At this point, we have the UI requirements documented with the high fidelity prototypes and further recommendations of the Client regarding some prioritizations.

During the planning, we analyze each Feature and set up complexity to balance through the Team’s ability to deliver the amount of work. At this point the team creates tasks to accomplish its acceptance criteria. Those tasks will be used for managing the development cycle.

Right after we analyze the complexity of each Feature, we set up the ones that the Team will be able to achieve during the Sprint Cycle (notice that our standards takes up to a 10 business days cycle).

During the Sprint Cycle, neither the Client nor the PM is able to change requirements nor add more deliverables for the Sprint Cycle.

Thus, we can start to work and align with the Client all the expectations of the next delivery.

Kanban Board

The Kanban Board is organised as follows:

Notice that each phase of the kanban board represents a status of deployment for our Client.

The higher the phase, the most critical is the task, so in case we have Production QA Failed means that we need full support to tackle those issues.

Sprint Daily Meeting

The Team along with the PM set up a moment during the workday to align the information of the Team during the Sprint Cycle. This moment is called Daily Meeting. During a maximum of 15 minutes, the whole Team needs to update themselves with the current status of their development. Normally we follow some guidelines for Daily Meetings:

Sprint Delivery

Considering that the Sprint Cycle is finished, the team needs to prepare the deploy process and have the quality assurance process approved.

After QA Approval, the task can be set up as Done. In case the task has some bugs or some other issues, the task downgrades its level to QA Failed and the developer needs to tackle it as soon as possible.

The Sprint Cycle is approved successfully if all the US planned during the planning were Approved by QA. In either case, the Sprint Cycle will fail.

Sprint Retrospective

After the Deploy process and the Approval/Disapproval of the Sprint Cycle, the Team needs to review their work during the past cycle and share with each other to improve and align any other problems that is affecting the developers individually and as a team. Here are the guidelines for the Retrospective:

Bug Reports

Homologation/Production phase, our process needs to be as smooth as possible. Thus, we provide a Service Desk for users to reports adjustments and bug reports. Its structure adapts on the project type (Web or Mobile).

The main points for report are:

After user submit, this report is generated as an Asana task and comes for PM review and sent to the Kanban Board as QA Failed

DAKI Exercise