Time tracking in Starbrix: how it works for engineering teams
Engineering teams consistently face the same fragmentation problem. Tasks live in one tool, time capture happens in another (or a spreadsheet), approvals are chased over e-mail, and by the time a project manager tries to reconcile planned hours against actuals, the data is already a week stale. That disconnect makes capacity planning guesswork and post-project analysis nearly useless.
Starbrix is built around a different model. Rather than treating time tracking as an isolated module bolted onto task management, the platform connects every stage of the work cycle: estimate workload → plan hours from the Gantt schedule → verify real resource capacity → perform the work → report actual hours → review and approve → compare planned and actual hours → use that comparison to improve future planning. Each stage feeds the next in the same system, so engineering leads and project managers always work from a single source of truth.
This documentation covers the complete time tracking workflow in Starbrix, with engineering-specific examples throughout.
Hour planning: starting from the Gantt schedule
Before any time can be reported, hours need to be planned. In Starbrix, that planning starts directly from the project's Gantt chart in hour planning mode. Two levels of granularity are available:
- Project-level planning: enter a single total workload estimate for the entire project. This suits early-stage scoping where task breakdown is incomplete.
- Task-level planning: plan working hours separately for each individual task. This is the preferred approach for sprint-based delivery where work items are well-defined.
Availability calculations are not purely theoretical. Starbrix accounts for weekends, public holidays, each team member's daily work capacity, and hours already allocated in other active projects. That means resource conflicts are visible before scheduling is committed, not after an engineer has already been double-booked across two concurrent workstreams.
The output of hour planning feeds directly into the planned hours figures visible in project and portfolio views, which are then compared against actuals as work is reported.
How to log time: choosing the right reporting method
Starbrix supports four distinct time-reporting workflows. Each serves a different operational context, and engineering teams often use more than one approach within the same sprint cycle.
Weekly hour reporting
The weekly view automatically lists every project and task the logged-in employee is assigned to during the selected week. The employee enters worked hours and a short work description directly into that view without navigating to individual tasks. This is the lowest-friction method for routine sprint work where the task context is already known and hours accumulate predictably across the week.
An example: a backend engineer working on a sprint feature branch logs Monday through Friday hours against two tasks in the weekly view in roughly two minutes. No timer running, no context switching.
Dedicated reporting window
The reporting window gives the employee a focused form: select the project, optionally select the specific task, enter the number of hours, add a work description, and submit. The system displays a running total of hours reported for that day, which helps prevent accidental double-entry. This method is well-suited to ad hoc work that falls outside an existing sprint task, such as a technical review or an unplanned dependency meeting.
Precise start and end time tracking
For work where timestamp precision matters, Starbrix supports reporting with explicit start and end times. The system records the exact duration from those boundaries. This mode is particularly relevant for incident response, where knowing that a production fix was worked on from 14:23 to 16:47 has operational significance beyond a rounded hour count.
Mobile-compatible time entry is included, with timestamps optional. An engineer receiving an out-of-hours alert can open Starbrix on a mobile device, start a timed entry against the relevant incident task, and stop it once the fix is deployed.
Choosing between methods
The choice is not exclusive. Within a single reporting period, an engineer might use weekly reporting for sprint tasks and timestamp mode for two incident escalations that occurred mid-sprint.
Timesheets and the approval lifecycle
Once hours are submitted, Starbrix routes them through a structured review process. The table-based workflow supports four actions on any time entry: Review, Edit, Add, and Remove. This gives reviewers the ability to correct errors, add missing entries on behalf of a team member, or flag anomalies before hours are finalized.
Approval stages
The standard approval chain runs as follows:
- Employee reports hours and submits them with a single click.
- An e-mail notification is sent automatically to the assigned reviewer.
- The reviewer reviews the submitted entries in the approval table.
- The final approver approves the hours, completing the cycle.
For teams with simpler governance requirements, the workflow can be configured so that time reports proceed directly to approval, bypassing the intermediate reviewer stage.
Multi-stage approval matters for engineering teams operating on client projects or cost-center billing, where a team lead may need to verify hours before a project manager or finance contact approves them for invoicing or budget reconciliation.
Reporting outputs and export formats
Approved hours are immediately available in hour reports. Starbrix generates these in chart and list formats, making them usable both for internal review and for client-facing communication. The export options in Starbrix are:
- Print (for physical distribution or filing)
- Save as PDF (for e-mail distribution or document archives)
- Export to Excel (for further analysis, custom filtering, or payroll integration)
A practical engineering reporting workflow: at the end of each sprint, the project manager exports the weekly totals per employee to Excel, cross-references them against the planned hours in the Gantt schedule, and produces a per-task roll-up covering both sprint feature work and any maintenance or support hours logged during the same period. That roll-up feeds into the retrospective and into the next sprint's capacity estimate.
Billable vs non-billable time entries
Starbrix makes a clear distinction between time worked and time that can be billed. For every time entry, users can report the actual time spent — for example, 3 hours — and separately specify how much of that time is billable to the customer, for example, 2 hours or 0 hours.
This means a single time entry can be fully billable, partially billable, or completely non-billable. A consultant might spend 3 hours on a task but mark only 2 hours as billable, while time spent on internal work, corrections, or other non-billable activities can be reported with 0 billable hours.
The billable amount is recorded directly on the individual time entry, so teams do not need to create separate projects or tasks simply to distinguish billable from non-billable work. At the same time, every entry remains connected to its relevant project and task, providing both the work context and the financial context needed for project follow-up.
This gives project managers and finance teams a more accurate view of actual effort versus billable effort. It also supports invoicing and profitability analysis by making it possible to see not only how much time was spent on a project, but how much of that time can actually be charged to the customer.
Time can be reported either as a duration or using start and end times, while the billable hours can be specified separately for each entry.
How time connects to project control and portfolio dashboards
The integration between time data and management views is where Starbrix differentiates from platforms where time tracking is a separate add-on.
Project Indicator
At the individual project level, the Project Indicator surfaces three figures side by side: planned hours, resourced hours, and actual hours. These connect directly to schedule baseline comparison and financial performance metrics, including estimated income and costs versus actual figures, and how deviations affect expected margin. An engineering lead reviewing a project mid-delivery can see at a glance whether the team is tracking above or below the planned workload, and whether that deviation is affecting the financial outcome.
Portfolio Key Figures and the Organizational Dashboard
Starbrix's Organizational Dashboard aggregates planned vs actual hours across the entire portfolio. It also shows delivery reliability and budget performance at organizational level, giving program managers and PMO leads a cross-project view without exporting data to a separate BI tool.
For engineering departments running multiple concurrent workstreams (product development, infrastructure upgrades, client delivery, and internal improvements simultaneously), this aggregated view answers questions that individual project views cannot: which projects are systematically underestimating, which engineers are consistently over-allocated, and where the portfolio as a whole is diverging from the annual capacity plan.
Using plan vs actual deltas as a decision signal
A consistent gap between planned and actual hours in a given area points to one of three root causes: estimation drift (the team's initial estimates are structurally incorrect), scope creep (work is expanding beyond what was planned), or competence mismatch (the allocated resource does not have the expected productivity on the task type). Starbrix's planned vs actual data at task and project level gives leads the specificity to distinguish between these causes and address them with targeted actions rather than blanket schedule adjustments.
Engineering use case: time tracking across sprints and incidents
The following scenario shows how a mid-sized engineering team uses Starbrix across a two-week sprint that includes feature delivery, reactive bugfixes, and ongoing maintenance.
Setup: The squad of eight engineers has the sprint scoped as tasks in Starbrix, with hour estimates assigned at task level via the Gantt hour planning mode. The project manager has verified that no engineer is over-allocated by checking the availability calculation, which accounts for one public holiday mid-sprint and two engineers who have carry-over hours from a parallel infrastructure project.
During the sprint (routine work): Each engineer uses weekly hour reporting. On Friday afternoon, each person opens the weekly view, which automatically lists their assigned sprint tasks, and enters hours with a brief description for each day. The process takes under five minutes per person. No task navigation required.
During the sprint (incident response): On day nine, a production regression is reported. Two engineers pick up the investigation. Both open Starbrix on their phones, start timed entries against the incident task with precise timestamps, and stop the timer once the fix is merged and verified. The timestamp entries capture the exact duration (2 hours 14 minutes and 1 hour 52 minutes respectively) and are immediately visible in the project's actual hours total.
End of sprint (review and approval): All engineers submit their hours for the period with a single click. The team lead (acting as checker) receives e-mail notifications and reviews the entries in the approval table, correcting one entry where a wrong task was selected. The project manager, acting as final approver, approves the full set.
Post-sprint analysis: The project manager exports the sprint's time data to Excel and compares it against the planned hours per task. Feature development tasks tracked within 5% of plan. The two incident tasks consumed 4 hours of unplanned time, which had not been budgeted in the sprint plan. This delta is documented for the next sprint planning session, where a maintenance buffer is added to the capacity plan.
At portfolio level, the Organizational Dashboard shows the project's delivery reliability score has remained consistent, but the actual hours total is now 6% above the planned baseline. The program manager flags this in the quarterly review and adjusts the resource allocation model for the following quarter.
The operational outcome: the engineering team replaced three separate tools (a time-logging spreadsheet, an e-mail approval chain, and a manual Excel dashboard) with a single workflow inside Starbrix. Every hour recorded has task and project context. Every approval is traceable. And every sprint's data feeds directly into the capacity plan for the next one.
