Photo by Loic Djim — https://unsplash.com/photos/ft0-Xu4nTvA

How we Track Time at 3CS

Time tracking isn’t exactly rocket science but at 3CS we’ve found that getting a few small details right can go a long way to keeping things running smoothly.

1. Time sheets are for clients

We record time for several reasons but the most important one is to communicate to clients what work has been done and how their money is being spent.

Everything that’s recorded in our time tracking system (Hourly) ends up visible to clients because our time sheets (after a review process) are often attached to invoices.

While not every client reads every line item on every invoice, we work on the basis that they might and we don’t want great work to be let down by a lack of transparency or poor communication at invoice time.

2. Keep time entries to one task and under 2 hours

As a general rule, we try and keep time entries (individual line items on time sheets) limited to one main task and under two hours duration.

We find this helps provide a meaningful level of detail and transparency to the client and hopefully prevents any unfair and inaccurate perceptions forming around our time recording practices (for example padding, guesstimation, laziness etc)

It all comes down to building and maintaining trust with our customers — especially relevant given that most of our work happens off site.

It also means that in the rare event that an invoice is queried, we have a credible and defensible audit trail where we can go back through our records and pinpoint exactly what was done, when it was done and how long it took.

On the days where we work on a single task for the whole day or a major part of it, just apply common sense and break things up into smaller chunks. We find recording time regularly helps (ie. when you take a break or lunch) rather than waiting till the end of the day when the memory can get a little fuzzy.

Don’t worry about time entries needing to have a one-to-one relationship with tickets or tasks from JIRA either (or other project management tools). It’s perfectly fine for multiple time entries to reference one ticket item.

There will be times where two tasks are intertwined (eg. identifying a problem, making an initial fix, testing and iterating until a full fix is in place). It is ok to combine them together, especially if the whole tasks (investigate, resolve, test) is less than 2 hours. If it is more than 2 hours, we break the tasks down by providing a high level description of the different paths of investigation for instance (eg. ‘looking into possibility of using NHibernate instead of Entity Framework for data layer to resolve issue [x]’, ‘looking into replacing default Entity Framework service layer to resolve issue [x]’).

Examples:

Here’s a not so good example where there’s only one line item for the whole day:

Who knows exactly what was done on this day…

Slightly better but still not great example where there’s only one line item for the whole day:

We can’t possible know how long each element took…

Here’s a better example where the same large task has been broken up into smaller tasks all under two hours:

Tasks broken down into better sizes so we can tell what was done and how long it took…

3. Make descriptions non technical

We don’t reference class names, method names, solution file names or anything else that the client wouldn’t reasonably know about.

It’s ok to provide technical details, but we try to describe it on a level that the customer will be familiar with — for example, a page or control if it is front end related, or the relevant functional area if it is back end related.

Examples:

Here’s a not so good example where the description is too technical:

This is unlikely to mean anything to a client…

Here’s a better example where the description is less technical:

The name of the page affected is likely to mean more to the client…

3. Give descriptions context

Finally, task descriptions should have appropriate context so that it’s possible to tell what they relate to.

While we don’t want ‘War and Peace’ length task descriptions, we need enough information to be able to work out what a task was and why it was undertaken. Remember that quite often we or the client is looking back on these tasks several days, weeks or months after the fact.

With meetings for example, we should note what sort of meeting it was, why we had it and potentially who was there.

Examples:

Here’s a not so good example where the description is over generic:

What sort of meeting was it…?

Here’s a better example where the description tells us what the meeting was for:

Ahh, that’s right. Now I remember what this meeting was about and why we had it.

A final word…

This list is by no means exhaustive and we’ll add to it over time — it’s also not fixed in stone so if you’ve got new or different ideas please let us know.