Subject: Supporting the R&D Credit with JIRA
Newsletter Date: November, 2020
IRS Circular 230 Required Notice‐‐IRS regulations require that we inform you that to the extent this communication contains any statement regarding federal taxes, that statement was not written or intended to be used, and it cannot be used, by any person (i) for the purpose of avoiding federal tax penalties that may be imposed on that person, or (ii) to promote, market or recommend to another party any transaction or matter addressed herein.
USING JIRA TO SUPPORT R&D CREDIT
JIRA is a fantastic platform for project tracking, but it can also help in supporting your R&D credit claim. Using some or all of these best practices will help you in your goal of having as minimal a role as possible for yourself or your personnel during a review of your R&D credit, as the documentation will do the supporting for you. First, let’s learn a little about what JIRA is…
JIRA is a tool developed by Australian Company Atlassian. It is used for bug tracking, issue tracking, and project management, most commonly during the software development.
Atlassian provides JIRA for free to open source projects meeting certain criteria, and to organizations that are non-academic, non-commercial, non-governmental, non-political, non-profit. For academic and commercial customers, the full source code is available under a developer source license.
The tool can be used as a hosted solution or as an internally managed, on-premise solution. When launched in 2002, JIRA was purely issue tracking software, targeted at software developers. The app was later adopted by non-IT organizations as a project management tool. The process sped up after the launch of Atlassian Marketplace in 2012, which allowed third-party developers to offer project management plugins for JIRA. “BigPicture”, “Portfolio for JIRA”, “Structure”, and “Tempo Planner” are major project management plugins for JIRA.
Software teams began adopting JIRA as they adopted the Agile development method (a development method that breaks product development work into small increments that minimize the amount of up-front planning and design. Iterations, or sprints, are short time frames (timeboxes) that typically last from one to four weeks). As a project management tool, JIRA is a robust way of tracking and assigning tasks, tracking progress and issues, as well as tracking time spent on specific tasks and sub-tasks. Whether being used for project management in the realm of software development or for non-software development related projects, JIRA can be leveraged to support your R&D credit.
Some of the fields/inputs in JIRA that can be used to help support the R&D credit activities in your company include:Who was involved (creator, reporter, and assignee fields)
- What work was performed to attempt to resolve said issue (summary and or description)
- When the work was performed (creation, update, and resolution timestamps)
- How the work was carried out (description and or comments)
- Why the work contributes to the development/implementation of new features or functionality, or how it pertains to the overall improvement of the product or service (epics or other parent entities that group together logically related issues).
Now that you know a little more about what JIRA is and where it has come from, let’s investigate how you can best use JIRA to help with reporting information related to the Research and Development Tax Credit, or, how tax departments can use these practices as a conversation guide with development groups.
Best Practice 1: Use Those Descriptor Fields!
The easiest way to communicate what the technical nature of the work was and how it was carried out is to focus on filling out the (default) project, summary, and description fields in a consistent manner as the work progresses. If you choose to organize JIRA into multiple projects, it helps tremendously during an R&D credit review, as an auditor can then filter for eligible work at the project level. Summaries and task descriptions should be filled out with enough detail such that someone outside your company can easily tell what tasks are related to qualified activities and directly in support of your R&D work according to Section 41 guidelines.
The information contained within these fields should enable an auditor to clearly distinguish between eligible and ineligible work at the task level. Beyond that, you may choose to create custom JIRA labels (e.g. ‘R&D’ or ‘experimental’) and apply them to epics/issues for ease of filtering at the end of the tax year, as well as any other fields that may help a reviewer see what small or routine tasks were necessary parts of an R&D project.
Naming/labeling conventions, terms, acronyms, and insider jargon should all be standardized across JIRA issues to enable an outsider to filter for, reference, and group logically related tasks. For example, if tasks or sub-tasks are labeled as “Bugs”, but those activities actually include qualified work such as performance testing of a newly deployed feature prior to roll-out, it may be worth the discussion to either break out those activities as sub-tasks, or give them a label all their own (i.e, “performance testing” or “testing” instead of “Bugs”.
Likewise, consistency is key. If projects go by a different name every time they get referenced, tracking the work associated with a given claim becomes a nightmare.
Best Practice 2: Use Sub-Tasks to Bolster Assignee Fields for Wage QRE
Wages make up the bulk of expenses of a typical R&D claim, meaning that evidence supporting your wage allocation is commonly the most important kind of evidence. Therefore, it’s important that your supporting documents clearly demonstrate who was working on a given task, and when that work occurred.
Trying to use JIRA to calculate the overall qualified percentage of individuals can result in lower than accurate results, due to a built-in feature of JIRA regarding past reassignment of tasks that decreases the amount of eligible work you can associate to specific individuals. The root cause stems from JIRA having only one Assignee field, and this field only retains the most recent assignee ID. As already stated, Atlassian has done this purposefully, as it means one person is responsible for each piece of work at any given time, but this it makes it much more difficult to figure out how to apportion total time logged in a particular issue amongst all past and present assignees.
So how do you make sure that your JIRA documentation matches the actual R&D work of your team? The most straightforward way is to create a large amount of individual sub-tasks (e.g. having design, production, and validation all be independent tasks), each with a single individual being responsible for them, and duplicating tasks should multiple people need to collaborate. Admittedly, this method results in a lot of clutter in terms of fields but will ensure that the “assignee” field accurately identifies who did what.
Alternatively, you might consider adding a custom user-picked field for tracking personnel who have previously worked on a task, but who became unassigned for whatever reason, for multiple assignee tracking with minimal overhead.
Best Practice 3: Time Spent is Time Tracked
Since two JIRA issues can take wildly different amounts of time (compare an issue to fix a typo with one to develop a new feature) it helps if you can account for that. Since qualified R&D issues tend to take longer than routine ones, a tracking method which treats every issue as equal weight is probably leaving money on the table.
This is where the recommendation to leverage the “time spent” fields to keep as accurate an accounting of time spent on tasks as possible. This can be done either at the epic or task level. Make sure that you don’t miss out on time spent planning work and all the other support activities as these are eligible tasks as well; many companies only track hands-on development work in JIRA, while neglecting to log the initial R&D, design, and planning work that made implementation possible.
In lieu of explicit timekeeping, it is acceptable to use story points for time tracking/project weighting purposes. While the IRS prefers some form of time tracking, in practice they commonly recognize that story points are a good proxy for time/effort spent on tasks, so long as points are consistently applied to tasks throughout the project lifecycle. Therefore, if you have a reasonable estimate for the amount of time an individual performed qualified activities throughout the year, as well as projects/tasks to which they were assigned in JIRA, then it is a reasonable approach to utilize the number of story points as an indicator of how to properly allocate time to those projects.