Track time like a pro

I’m going to catch heat for this one from the team, so let’s just get it out of the way. Time tracking is operational overhead. Plugging time entries into DevBooks and matching them up to Jira tickets literally takes time away from building product. I get it. Time tracking is also one of the most important, relationship-forming activities that you can do as a consultant to your client. The more granular, detailed, and accountable you are with your time entries, the more trustworthy you look. So please, please treat it with the care and attention it deserves.

The projects we work on are contracted based on “time and materials,” “T&M not-to-exceed,” and “fixed bid.” These terms account for how we are obligated to track our time and deliver results. Regardless of the contracting language, we track time and invoice to reflect the actual time spent after each sprint. This type of time tracking and invoicing builds transparency and trust with the client while also allowing us to monitor health of delivery.

Tracking time is the second most powerful tool to build trust with your client following delivery.

The time tracked falls into billable and nonbillable categories.

We use this data for the following purposes:

• To bill our clients. An invoice is generated with detailed time entries for each team member alongside their comments and associated Jira tickets.
• To measure how effectively we spend our time. Not all the time we spend is billed directly to the client. We want to understand the changes and patterns in billable and nonbillable time.
• To identify valuable nonbillable efforts. Teams invest time into education, traveling between offices, internal meetings (e.g., squad meetings and performance reviews), internal projects, internal tools, and candidate interviews.
• Spot overtime and usage spikes. People do their best work when they have a consistent, predictable schedule with time to rest and recover. Exceptions do happen, and we track overtime to make sure teams get compensated for going above and beyond (e.g., for market release or recovery from failure).

The standard Devbridge workweek is forty logged hours. In other words, logged time is time spent performing your work function—both billable and nonbillable. We don’t track breaks, lunches, and other nonwork functions. Here are some best practices:

• Plan and manage time on a daily basis. A lot of the frustration with time logging comes from trying to remember what you were doing two or three days ago.
• Log actual time. Time spent fluctuates. Some days may be nine or ten hours, others less than eight. It’s OK.
• Document time in fifteen-minute increments. Round up tasks to the nearest quarter-hour and enter them into DevBooks once complete. This helps with transparency and specificity for the work performed.
• List one task per entry. Log each task separately unless it’s minor and subordinate to another one (e.g., “fixed four bugs in fifteen minutes”).
• Include Jira ticket ID. Self-explanatory.
• Add comments. Include a breakdown of the completed work, especially for tasks that took an hour or more.

Categorizing time entries

We categorize logged time in DevBooks by design, development, HTML/CSS, product management, testing, and the like. Consider discussing the needs of your product with the leading product manager and the managing director—we have established additional categories in the past that have allowed us to gain insight into the working processes of the team, inefficiencies, and client bottlenecks.

For example, we determined that hawkish review of pull requests were consuming a significant amount of engineering time for one of our clients. Tracking communication around pull requests in a separate category allowed us to aggregate the investment being made into a bureaucratic process and request a change.

Additional information and best practices on time tracking can be discussed with your manager or found in the Devbridge Confluence page.