Drakkentech Timesheet Guide
Introduction
We do development projects on a time and materials basis. As such it is crucial for our success and survival that our clients feel they can trust us and that they see us as competent and well organised project managers.
When we share high quality time sheets with our clients and do a proper job of tracking our progress against our estimates, it builds this trust. Therefore it is important to log your hours according to standards below.
Log your hours on Clockify
We pay to use Clockify to record our hours. The tool does its job well. Use it always.
8 hours per working day should be accounted for, on average
Allocate your hours correctly
Each log entry should correctly be allocated to the right project. It should have a short descriptive description on what it is about. If it relates to a ticket that was created during a sprint, a task with a name corresponding to the ticket should be created and the log entry should be allocated to that task. For activity that does not relate to a specific ticket, you should still try to allocate it to a more high level task, like ‘Sprint meeting’, ‘Client meeting’ or ‘Project tracking’.
Both the task and description should be specific to what part of the project you were working on.
Good examples:
Task: Boilerplate app
Description: Create python boilerplate app, implement flask app, logger and database connection.
Task: QA,
Description: Tested photo taking for General Queries on Android device.
Task: Internal meetings
Description: Discussed with Pieka and Shane the Security App flows and some edge cases
Bad example 1
Task: Pragma – using code from C# and trying to get the same results in python
Description: iThemba: Pragma – using code from C# and trying to get the same results in python
Problem: Task is too long and specific, Description contains unnecessary info: the client, project and task already tells you it’s Ithemba and Pragma, no need to put it in the description too.
Corrected:
Task: Pragma API
Description: Using code from C# and trying to get the same results in python
Bad example 2
Task: Alexan
Description: RiskFin: Riskfin direct chat with Alexan about the new policy structure to take into account riskfin direct
Problem: The task is a team member, rather than a part of the project. Description contains unnecessary like previous example.
Corrected:
Task: Internal meetings
Description: Discussed new policy structure and how to take into account RiskFin direct.
Bad example 3
Task: New Feature
Description: 82: Freeze header columns/rows on weekly report
Problem: Task name “New Feature” is not specific enough about what you are working on.
Corrected:
Task: Enhance weekly report
Description: Worked on implementing <new library name> to freeze columns
Allocating tasks to log entries is very helpful for when we need to track project progress.
Some of your activity will not be billable to clients and should be allocated to DrakkenTech projects:
Internal meetings: daily stand-up, team building, meetings about “how we work”
Business Development: activities relating to us finding new work
Recruitment: activities related to growing the team
Spelling, grammar and clarity
Your timesheet is shared with the customer, so make sure you spell things correctly and that your descriptions are well worded.Please start tasks and descriptions with a capital letter.
Be. Honest.
Don’t log hours you did not work. If it ever comes to light that you did this, it breaks a trust that is crucial for you to be part of the team. If there are things going on in your life that prevent you from working the hours you should be working, rather be open about it with Pieka. He will be reasonable and accommodating.
What about breaks and short disruptions?
DrakkenTech encourages that developers take short breaks because it is good for health, productivity and for thinking clearly. We do not expect that you ‘stop the clock’ during short breaks or short disruptions of your task. As a guideline, a short break or disruption should be about 15 minutes and not longer than 20 minutes.
If you are disrupted by switching between tasks for one client, it is not necessary to reflect this with perfect accuracy on your timesheet, since the client will be paying for both tasks anyway.
However, if you are switching between work for different clients or taking a break and the time away from actively working on your “logged” task is 20 minutes or more, then you should reflect this in your timesheet.
End-of-day code commits
In the past there have been questions raised about whether people really did work when they said they did. One thing that could have easily vindicated them would be if they had committed their code daily. Like that, there is some hard evidence of your efforts and time spent for the day. I would recommend that you all do this, in case there are ever doubts raised about your work by either our team or our clients.
Explain anomalies preemptively
Send an email at the end of the day of the 24th of each month (or, if that is not a working day, the last one before it) in which you explain any anomalies on your timesheet for the month. Our monthly cycle runs from the 25th to the 24th each month. Here are some things that I would expect in this mail if they are relevant:
- No hours worked on the 15th and 16th because I was off sick with the flu
- Worked only 4 hours on the 26th because I had “used some overtime” from the 22nd and 23rd from last month.
- Did not work on the 19th because I had taken leave.
- Three hour internal meeting on the 15th because we were discussing how expense claims work
- 8 hours business development on the 21st because we went to the WeThinkCode_ graduation
Tracking of your logging performance
When you do not follow the guidelines above and management needs to ask you questions at invoicing time or project tracking time, it wastes your time and that of the project managers and accounts team.
So, each month you’ll be rated for whether or not you followed these guidelines and this will be taken into consideration when considering your advancement as developer.
The perfect time log has all hours allocated correctly and sensibly, and any possible questions are pre-emptively addressed in the email as discussed in the preceding section.
