Jump to content
  • Very Popular

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

    Daniel Ballabas - EverIT

    • Intrigued 1

    Using a time tracker app or just the built-in Jira feature, time tracking has become popular in Jira. This feature allows precise measurement of work for outsourced projects, streamlining tasks for finance teams by making budget allocation and invoicing more transparent. It also offers a comprehensive view of team performance, revealing work patterns and areas needing improvement.

    Over time, teams have refined their use of Jira’s worklogs, for example, using worklog tags. Tags let teams categorize worklogs by task, project, or any relevant parameter while grouping collects similar worklogs for easier evaluation.

    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.

    What are container issues?

    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.


    What could go wrong with container issues?

    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

    When to use and why are they useful

    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.

    Favourite Issues illustration

    How to use container issues properly

    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.

    Sum up

    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.”


    User Feedback

    Recommended Comments

    I always strongly advise against container issues because of the abuse it places on the system.

    This is also not how Jira is designed and even with just a few thousand entries this one issue will begin to affect performance.

    If you need to log time in this way, then do it correctly:

    • Create an Epic to act as the container
    • Create Tasks for each activity and log one activity only in that.
    • Close the epic every month or ever quarter to avoid having too many linked issues.
    • Rinse and repeat.

    A far better solution is to just work with tasks as normal and then get an add-on to summarize it for you or use the API to load it into an external BI system.

    Container issues should never be used and there is a reason why we have guardrails to find and remove these things in our systems.

    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Add a comment...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...