Documenting SR&ED in an Agile World

The Scientific Research and Experimental Development (SR&ED) tax credit program is one of the most generous in the world and many software companies take advantage of this program to help fund their research and development initiatives.

The SR&ED (pronounced “shred”) program was created over 25 years ago when software development was primarily performed by large enterprises and systems integrators with the development methodology being a highly structured, waterfall processes with a heavy focus on documentation.

Today, many software developers are adopting agile, lean, or other iterative development methodologies and keeping process documentation focused on the minimum requirements. However, the SR&ED program’s stringent focus on “contemporaneous documentation” has created a conflict for a company trying to optimize their SR&ED claim, yet developing software using an Agile methodology.

One of the questions that I am frequently asked is how companies can apply the rigorous SR&ED documentation requirements with the speed and agility required from their highly iterative development process? How can the two concepts co-exist successfully and effectively?

To answer this, let’s start with the requirements from the Canada Revenue Agency (CRA) SR&ED policy on documentation. The policy states that there is a need to have “contemporaneous documentation” of SR&ED activities as evidence of qualified work. Contemporaneous refers to documentation that is created at the time the SR&ED activity is performed, identifies who did the work and what was done. Ideally, the documentation should exemplify the technological uncertainties and the systematic investigation that was performed.

In essence, the “how” and “why” of the development process is far more important to account for than the “what.” Despite the ability to show the final results of SR&ED, failure to meet the SR&ED documentation requirements will usually result in denial of a claim, should it get reviewed.

Instead of creating an additional and onerous SR&ED process, I suggest adding to or modifying your current development processes to accommodate SR&ED. To this end, I have identified some easy to implement and often overlooked areas where you can document SR&ED within your existing agile environment.

1. Create a SR&ED champion within your company. This person should be someone who manages projects and is familiar with the standards and processes of software development in your company.

Ideally, they are a Project Manager who already produces artefacts such as sprint summaries. As “SR&ED Champion,” they are the primary resource for all SR&ED related questions and can enforce the implementation of these ideas through existing and new project management artefacts.

2. Add SR&ED commenting during source code check-ins. An example of how an existing development process can be modified to suit SR&ED purposes is by using source code repository check-ins to document SR&ED. Your developers may already add their check in notes.

By mandating the use of SR&ED “tags” with additional notes on experimentation performed leading to the code output you now have a diary of all your SR&ED results. This repository can then be searched when you need to document and compile your claim.

3. Use of sprint/scrum reports and wiki notes: Adding three SR&ED relevant fields in your sprint summaries or scrum reports – SR&ED: Yes/No; Technological Obstacles; Experimentation Performed- will ensure that you capture the SR&ED work done within the context of your existing SR&ED reporting.

You can also add the “SR&ED” tag to wiki entries that may relate to SR&ED work. This tag can be easily searched when you need to develop your SR&ED claim for related sprints or tasks.

4. Source code commenting: While source code is an accepted form of SR&ED documentation, it only shows the results of SR&ED, rather than the process of SR&ED. Identifying specific algorithms tried and the experimentation undertaken as comments in code is a good way to document the SR&ED process.

When appropriate, commenting out failed code or iterations of algorithms is a good way to tag SR&ED work. Adding shorthand to the comments, such as initials of the programmer and dates, can strengthen the reliability of this type of documentation.

5. Email is an often overlooked area of SR&ED documentation. You can create a SR&ED specific account such as and CC the email when SR&ED specific emails are sent. Emails that discuss technological obstacles, uncertainties and experimentation are worth documenting.

This method is a good way to improve your SR&ED documentation with minimal overhead. This email account can now be retrieved regularly or at the end of the fiscal year when you need to compile your SR&ED claim.

The CRA also expects that larger, more complex software development environments have more mature and formal documentation; you should expect that if your claims are large, your level of documentation corresponds accordingly. Larger claims should, in theory, have more comprehensive documentation. By implementing these simple steps in conjunction with their existing process, software companies of all sizes can adapt their agile development to improve SR&ED documentation, resulting in more effective and timely SR&ED claims.