Do you define your core activities for R&D?

Once a year, someone has to go through every product, find the R&D work that was done, and write it up for the R&D Tax Incentive claim. If the team never defined what it was trying to learn, that person has to reconstruct it from commits and pull requests months later. It is slow, and the story often does not hold together.

The most effective way to make R&D reporting easy is for each team to know its core activities at all times.

What is a core activity?

A core activity describes what the team is trying to learn, and how it will know whether it succeeded or failed.

It is not a feature or a deliverable. It is a question that cannot be answered from existing knowledge.

✅ Figure: Good example - States what is being learned and a measurable way to tell if it worked

❌ Figure: Bad example - A deliverable with no knowledge gap and no way to judge success or failure

When to define them

• Define your team's core activities at least once a year
• Revisit them every quarter or half year, so new experiments land under the right activity
• At any point, every team member should be able to answer: "What are our current R&D goals?"

Where to record them

Keep core activities somewhere the whole team can find them (for example, the team's wiki or repository), and link each experiment's PBI to its core activity. See Do you record your research under the PBI?.

A GitHub Epic works well as the core activity. Link the spike and implementation plan from the Epic, and keep every PBI as a sub-issue underneath it.

✅ Figure: Good example - A GitHub Epic is the core activity, with the spike, implementation plan and every sub-issue (PBI) linked beneath it

When the yearly R&D report is written, the writer can then start from your list instead of starting from scratch.