100k worklogs on a single issue? - Dos and Don'ts of Container issues

One innovative approach that teams have developed is the concept of a “container issue.” Container issues serve as a collective “bin” for tasks that are either related or share a common attribute, which can simplify time logging considerably.

However, it’s worth noting that while container issues can make time logging easier, they can also “kill” a Jira if not used wisely. Follow us as we dive deeper into this concept and explore more ways to optimize your Jira usage in future posts.

Let’s begin with a basic definition of what a “container issue” is in the context of Jira. A container issue is created to collect and log similar activities into the same worklog. By collating related tasks or activities into a single worklog, container issues help streamline the time-tracking process and foster better organization within the team.

The beauty of container issues lies in their simplicity and functionality. These issues make similar activities easily searchable, measurable, and quick to pick when it’s time to log effort. Logging these in a container issue ensures that nothing falls through the cracks and every minute of effort is accounted for.

Using container issues is a method that we often recommend to our clients. It’s simple, efficient, and aids in maintaining a streamlined record of activities. However, it’s important to share a cautionary tale about its misuse.

During a large project spanning several years, one of our clients logged all instances of a certain activity type into a single issue… This was done consistently… for years…

Eventually, this one issue accumulated an astonishing 100,000 time logs. At this point, the sheer volume of data logged into this singular container issue caused significant problems:

• performance degradation

• slow response times

• administrative overhead/hardship

• third party app or integration troubles

Depending on the company’s or projects’ needs, there are multiple practices for creating container issues. Let’s have a list of the most common container issue types:

Administrative Tasks: These could include daily standups, team check-ins, internal meetings, paperwork, etc., which do not belong to a particular project but are necessary for smooth operation.

Examples: [General administration] [Meetings] [Standup]

Team Building Activities: Social or team-building activities are essential to maintaining a positive work environment. A general issue could be used to account for this time.

Examples: [Quarterly planning] [Retrospective]

Absence types: Times when team members are out of office or on holiday, can also be recorded in container issues. Additionally, monitoring each team member’s holiday durations provides a comprehensive view of both the time already taken and the remaining available holiday time.

Examples: [Out-of-office] [Holiday]

Did you know? Timetracker Cloud allows you to create “non-working” issues, which help administrate real-work and out-of-office times.

Training and Development: Team members often attend webinars, courses, or professional development sessions that aren’t tied to a specific project but still require time. A general issue for these events lets you quantify the time and resources dedicated to team growth.

Maintenance Work includes routine tasks like system checks, backups, or regular updates. These aren’t part of specific projects but are essential to the team’s function. A general issue allows users to find where to log these efforts quickly. Plus, it’s easy to report them weekly or monthly.

Examples: [DevOps tasks] [Maintenance, updates]

Bug Triage and Troubleshooting: Bugs can be received from multiple sources, but sometimes they don’t have an issue. A general issue can be created to log time spent on troubleshooting and diagnosing software bugs that might not be associated with a specific task but are vital for maintaining software health.

On-Call or Support Duties: Teams providing operational support often have on-call duties, which can be tracked using a general issue. This helps in quantifying the operational workload on team members.

Did you know? Timetracker Cloud lets your teammates save their favorite issues, such as container issues, into the issue picker, so they can select them quickly and easily.

Container issues can bring numerous benefits to your Jira workflow but can also spell disaster if misused.

When a large team incessantly logs activities into the same container issue over an extended period. This practice can lead to an overload of data in one single issue. If left unchecked for years, it can accumulate many logs that could significantly slow down or, in worst-case scenarios, crash your Jira instance.

Teams should regularly revise container issues to avoid overloaded issues and split them into multiple parts. Let us recommend the easiest solutions for splitting container issues:

By Timeframe: Creating new issues yearly, quarterly, or monthly can help avoid overcrowding in a single issue.

Example: [Meetings 2022][Meetings 2023]

By Work type: Splitting issues based on the type of work, such as administrative tasks, maintenance work, team meetings, brainstorming sessions, training, and development, or support duties, can help categorize time logs better.

Example: [Meetings][Administration]

By Project or Client: Creating general issues for each project or client could be beneficial if your team works on multiple projects or clients simultaneously. This way, you can track and bill the time more accurately.

Example: [Project 1 Meetings][Project 2 Meetings]

By Event or Activity: In the case of team-building activities, training sessions, workshops, or any other one-time events, creating separate issues can be a good practice.

Container issues in Jira offer streamlined time tracking for tasks like maintenance work, bug triage, and on-call duties, but if misused by large teams, they can overload the system and potentially cause crashes. To avoid this, teams should consistently split container issues into smaller segments based on timeframe, work type, project, client, or event.

As you can see, multiple ways exist to create and maintain container issues. Although there are overlaps in the given examples, you should keep the number of active container issues low to enjoy the advance of working with them — “Logging for container issues is quick and easy.”