Shortcut (Jira/Trello/Github) Toggl Time and Task Tracking

Introduction

My number one goal as CEO of ShakaCode is that my clients are satisfied to the point they are referenceable. Since the majority of our projects are billed per hour, clear and regular communications regarding time spent on various tasks are critical to having good client relationships. Every week, I send my team and clients 3 reports that show various breakdowns that detail how time was spent. With these reports, our clients can assess the overall level of effort for various tasks and efficiency of ShakaCode development efforts. Beyond just tracking time to a task, we try to break the work up behind a task into more detailed "time entries" that can provide color to what was done.

For our clients that use an agile project management tool, like Shortcut or Jira, it's useful to know how much time was spent on various stories and epics. Why?

1. Such data can help for future estimations of story points and required resources.
2. Such data shows where time was spent and how it correlates to delivered work.
3. Such data can help with the evaluation of developer effectiveness.

ShakaCode's consulting clients appreciate the transparency of having weekly and monthly reports which show a breakdown by:

1. Project - Task -- Breaks down time spent on epics and stories.
2. User - Task -- Shows how each time each user spent on each story.
3. User - Time Entry -- Shows how much time each User spent on each part of every story, such as writing a test for a story, can show details for why a story took extra long.
4. Weekly Report Grid - Shows the day of the week across columns and the users on rows, with breakdowns by project, which provides high-level details on what a developer did for each of the past 7 days.

You can see samples of these reports further down in this document

Thanks

If you are looking for expertise in projects involving React and Ruby on Rails, possibly with server-side-rendering, ShakaCode is taking on new projects. All of our clients are technical experts that have found us mainly via our open-source efforts, especially https://github.com/shakacode/react_on_rails. We help some clients that have a CTO and don’t want to hire additional staff. In other cases, we work side-by-side with an existing team to accelerate projects without adding full-time staff or rushing hiring.

Special thanks to the team at Jilt.com. From our work with Jilt, we got to know of Shortcut and developed the techniques presented here. If you're thinking of trying Shortcut, check out some details on their referral program and consider using me as your referral with this link.

I welcome your feedback. Feel free to email me at [email protected].

Toggl Background

ShakaCode uses the Toggl time tracking system mainly for ease of use and good reporting. Toggl tracks time spent based on 3 levels:

1. Time Entry: Freeform editing field. This article describes what should be placed here, based on the task chosen.
2. Task: Tasks roughly map to a Shortcut story, Github Issue, etc. Tasks require setup in the Toggl web UI. When a task is completed, it is marked as done and then it does not show in the autocomplete for time entries.
3. Project: Each task belongs to a single Project, which is a collection of tasks. Thus, picking a task also picks the project.

Toggl provides summarizing reports that group on 2 levels, such as by Project-Task by User-Task, and by User-Time Entry. The reporting does not allow grouping by Task-Time Entry. Thus, we try to enter the freeform Time Entries so that they make sense without the task name for the summary reports.

Task Definitions Come from Stories/Cards/Issues

Different project management systems use different terminology.

• Shortcut stories: CH123
• Trello cards have an id, so we can use T123. Many chrome plugins show the ids.
• Github issues have an id: GH123
• Jira stories have an id: XYZ-123

We'll use "story" for the rest of this article, as well as using an example of Shortcut with stories and ids like CH123.

In all cases, the project management stories (cards, issues, etc.) map to:

• Toggl Tasks
• Usually, pull requests or some other work output

This allows us to map time back to the intention, which is the story, as well as the result, which is usually the PR.

Stories Map to Toggl tasks

We map stories to toggl tasks. More specifically, we create two Toggl tasks per story, a base tasks and a tasks for reviews of the story.

Why track the Toggl tasks to stories?

1. Provides a detailed placeholder for where time is spent
2. Allows us to revisit the Shortcut stories to see if the point estimation of difficulty is reflected in the task description.

Why track time spent in review separate from development?

• We want to make sure that a sufficient amount of time is spent on big, tough PRs. Not doing enough code review is bad!
• An excessive amount of time spent during reviews might indicate:
  • Problems with the initial story definition
  • Problems with the initial code quality
  • A tough task

We considered tracking time spent writing tests...

• Pro: Visibility in the effort to create the tests
• Con: If doing TDD, one is bouncing back and forth between implementation, tests, refactoring, etc.

Recommendation: Provide some visibility in the **Time Entry **(not the task title)

Time Entries to Better Explain Time Spent on Tasks

The time entry in Toggl is a freeform text entry associated with the time tracking to a task. Often, a developer will copy the task definition into the time entry, as the time entries are never shown on the same _summary _reports with the tasks. Thus, a time entry like "Debugging" should never be used as it's confusing as to what task it had mapped to.

For larger "tasks," we recommend prefixing the time entry with the story ID, like "**CH123 - **" so that the time entry might look something like this. This provides the ShakaCode client with additional details on where time was spent in completing a longer task. Such time entries for a larger task should typically be less than 3 hours, so as to provide sufficient explanation of time spent.

Epics May Map to Toggl Projects

Toggl allows us to group tasks into "projects." Larger epics in Shortcut can roughly map to projects. Since all stories map to epics, it's not necessary to have the epic name and Epic ID in the task name.

Task Setup in Toggl

Shortcut Tasks, Dev and Review

The task names are of this format, mirroring the Shortcut story:

• CH123 - Story Title
  • Development including writing tests.
• CH123 Review - Story Title
  • Time spent by the reviewers

Why have a review task?

Having a separate review task allows tracking the amount of time spent in review.

It is important to set up **both (with and without "Review") **Toggl tasks at the beginning of working on the story. It's a bit awkward to have to add the review task later.

Generic Tasks

For every project, we set up the following generic tasks that are used when the work does not correspond to a story specific task.

• Ask
  • Probably needs a task, but one is not yet created
• Bug Investigation
• Other Development Tasks
  • For time entries that don’t justify a big enough grouping to be a “Task”. This is a judgment call.
• Other Code Reviews
  • Non-categorized code review. Prefer categorized ones.
• Other Design
  • Non-categorized design. Prefer categorized ones.
• Other Meetings
  • Non-categorized meeting. Prefer categorized ones.
• Performance Investigation
  • Ideally, create a story first for the performance work
• Project management
• Onboarding
  • Includes time for setting up and running the source code, including tests, on a developer machine.

We prefer non-misc, specific tasks where possible. In other words, tracking time to an anonymous task "Misc" is an antipattern.

Reporting

The goal of the setup is to provide useful reporting.

Reporting by Project and Tasks

Reporting by User and Tasks

Reporting by User and Time Entry

When a developer starts work on a task, the developer can copy the task name into the Time Entry _and _change the information as needed to provide any additional color on how the time was used, such as debugging something difficult, writing tests, etc.

Reporting by the Days of the Week

Related Documents

1. ShakaCode Client Engagement Model
2. ShakaCode Consulting Versus Full-Time Hires and Staff Augmentation