Rules to Better Research and Development

​​​The R&D tax grant is very beneficial to growing companies doing innovative work. If you're considering R&D for your company, it's important to keep the right documents and follow the right steps in order to comply with Australian R&D requirements.

Each of the following rules are designed to ensure that the following items can be demonstrated in a submission for R&D Tax Incentives.​

  • ​What the Core Activity was
  • What Knowledge Gap existed
  • What hypothesis was being researched
  • What experiments were performed, ie the results (including failed experiments)
  • What new knowledge was gained, and
  • What supporting activities were done to support the core research

You can find a page on R&D Tax Incentive by the ATO here​ with supporting documents here.

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  1. Do you attach emails to the PBI?

    ​​While working on a task or PBI, it is very important that you save any discussions or contextual information related to the work completed. This helps for future understanding of the what happened as well as providing relevant documents that support your research claims.

    ​​​Bad Example: An important research task that hasn't is missing records of communication
    ​Good Example: Email is copied to the description
    ​Good Example: Related emails are attached to the PBI

    When attaching an email to the PBI, consider whether or not a response to the email is required. The sender will usually expect a response when the issue is resolved. If a response is required, update the Acceptance Criteria with a note. E.g.​ 
    Send a done email in reply to the original email (attached).​

  2. Do you link your commits to a PBI?

    ​​​​​​​​​​​​​​In order to get better clarity on what work is done, it's a good idea to connect your PBI's and tasks to the commits, branches and pull requests that relate to the item. All commits, branches and pull requests should be linked to a PBI.​​

    no-linked-commit.png
    ​Bad Example: No linked commit's, branches or pull requests
    ​​
    linked-commit
    Good Example: Git branch linked to PBI in TFS

    Note: If you create your branches through Azure DevOps then you can link them during creation.​​​​​

    link-pbi-during-creation.png
    ​Good Example: Using Azure DevOps to link PBI during creation

    Here is a handy resource for linking work items:

    https://devblogs.microsoft.com/devops/linking-work-items-to-git-branches-commits-and-pull-requests/​​​​​

    Note: You can setup Branch Policies on your main branches to enforce this behaviour.

    add-branch-policy-for-linked-items.png
    ​Good Example: Branch Policy on the master branch to enforce linked work items on pull requests
  3. Do you record your failures?

    Australian R&D laws require you to show the separate attempts you make when developing a feature that counts towards R&D. For this reason, you should make sure to commit in between every attempt you make even if it does not have the desired affect to record the history of experimentation.

    The below example is for a scenario to improve load times for an MVC to Angular web app. The developer creates a new feature branch and works on their local machine.

    Once they are done the developer commits all the changes they made and push it the remote repository. Using this method, the developer loses the history of experimentation and it will be difficult to prove for R&D.
    single-commit-not-showing-experimentation-2.png
    ​​Bad Example: Only the final solution is committed. Experimentation history is not recorded​

    In this example for the same scenario the developer makes sure to commit every separate​ attempt to reduce load times for their web application. This way, everybody knows what kinds of experimentation was done to solve this problem.
    commit-failed-experiments.png
    Good Example: Each attempt has a new commit and is not lost when retrieving history​​
  4. Do you record your research under the PBI?

    ​​If you have done significant research on a topic, this should be documented.

    Create a new task under the PBI and place these resources in the description with a short summary of what you got from this link.

    research-task-under-pbi.png
    Good Example: Task for research created under the PBI

    ​​​​

    ​Each source you have used should be referenced here with the publish date and a short description of what you got from the content. If you take screen shots of the relevant sections then that is even better.


    ​​Good Example: Example research task on using caching to improve load times with SugarLearning



    ​​Good Example: If you don't find any suitable answers to your query, remember to make a short note of what you were looking for
  5. Do you save failed experiments in abandoned pull requests?

    ​​​​Assume you are creating a cool new feature. First you will create a new branch, create some commits, check it works, and submit a pull request. However, if you are not happy with the feature then don’t just delete the branch as normal. Instead, create a pull request anyway and set the status to Abandoned. Now, you can continue to delete your branch as normal.

    This makes sure that we have a historical log of work​ completed, and still keeps a clean repository.

    create-pr-for-failed-branch.png
    Good Example: Setup pull request for feature branch so that we have a history of the commits

    abandoned-pr-for-branch.png
    ​Good Example: PR is abandoned with a deleted branch​